I don't know a lot about screen reader issues, however there is no
reason not to be able to build a mega menu inside UL/LI structure and
this has been done in superfish. You can put divs inside an li, with columns , images, H tags, whatever you want and is all valid. Do whatever css you want inside those containers. Florent V. wrote: Hello, This is a message for Joel Birch, author of the Superfish plugin, to developers who may assist him (if any). It may be interesting to people working on similar plugins, dropdown navigation, etc.Superfish is a great plugin (thank you Joel for sharing it). It takes care of a lot of details, like some hard-to-squash IE7 bug, nice accessibility and usability enhancements, etc. While working on a project recently i encountered two issues with this plugin. Those issues are: 1. Superfish expects submenus to be UL elements and 2. the method of hiding submenus may not be accessible to some users (specifically users of text-to-speech technology). #1 SUPERFISH EXPECTS SUBMENUS TO BE UL ELEMENTS In the non-minified source of Superfish 1.4.8, this is on lines 104-105 and 112-113: var $ul = $(['li.',o.hoverClass].join(''),this).add(this).not (not).removeClass(o.hoverClass) .find('>ul').hide().css('visibility','hidden'); $ul = this.addClass(o.hoverClass) .find('>ul:hidden').css('visibility','visible'); I had trouble understanding all (if not most) of the Superfish code. But it looks like Superfish is looking of UL elements that are direct children of a given element [find('>ul') and find('>ul:hidden')]. If you happen to use a different element, say a DIV, the plugin works to some extent but the hiding/revealing of submenus is not managed by Superfish anymore, and the animation effects are not applied. Because Superfish won't find the UL it expects and thus won't be able to apply styles to it. I think it might be interesting, say in a future Superfish 1.5, to allow DIV elements as well, or maybe an arbitrary selector. The '>ul' selector could be a default parameter, and could be overridden with '>div', '.someclass', etc. I'm not sure if the requirement for the child selector is absolute, or is just a safety thing to avoid selecting nested elements in three+-level menus. Why would one want to use something other (whatever it is) than a UL? Well, it might be very useful to build mega-dropdowns (see http://www.useit.com/alertbox/mega-dropdown-menus.html), which is what i had to do (though my own "mega" dropdown was quite simple: a DIV with one paragraph and a short list of links). It might be useful too when you need an additional DIV around a UL because you need more markup to do some CSS embelishment (borders, shadows as images, decorated boxes, etc.). #2 HIDING SUBMENUS WITH DISPLAY AND VISIBILITY It's a well-known fact that a consequence of using display:none or (to some extent) visibility:hidden to hide an element is that this element won't be rendered by most screen readers (JAWS, Window-Eyes, etc.). Looking at the Superfish default CSS code, it looks like this was considered: .sf-menu ul { position: absolute; top: -999em; } .sf-menu li:hover ul, .sf-menu li.sfHover ul { left: 0; } (This is a simplified code extract.) The submenus are hidden by displaying them far on the left of the viewport (note that with most browsers, trying to do the same on the RIGHT of the viewport will create an horizontal scrollbar on the viewport, that enables the user to scroll all the way to where the submenus are positioned). Then when the parent LI is hovered, or gets the default sfHover class, this left offset is removed. This is a nice technique, but the JS code completely breaks it. Once the JS code is executed, the submenus will get this inline styles: <element style="display:none; visibility:hidden;"> And when the parent LI is hovered or tabbed to, you get: <element style="display:block; visibility:visible;"> I'm quite doubtful of the actual results of using a Superfish menu in a screen reader. Remember: screen readers act between the user and the application, meaning that a screen reader user is still using a normal web browser (mostly Internet Explorer, some use Firefox), and most screen reader users don't disable _javascript_ (either because they don't know how, or because the websites they use require _javascript_ in some ways). Now, please note that i don't know what the best option is. Reproducing the accessible CSS hiding trick in the JS would work. But: 1. The display:none might be necessary for some jQuery methods to work (i suspect animated fade-in effects to require an hidden element to work). Is this the case? Are there workarounds? 2. The current behavior MIGHT be ok in some or even most use cases. I suspect that linear navigation with a screen reader would work well, while other use cases (using the kind of page navigation shortcuts screen readers provide) might fail to reveal the relevant hidden submenus. I guess i should test this once i have some time to re-learn the basics of JAWS testing. (I'm not really fluent with assistive technology.) Finally, i would like to add that if the current JS behavior IS a problem for screen reader users, then the default CSS code might be counter-productive because it suggests to plugin users (especially advanced users who have some notions on accessibility) that screen reader users will be able to get to the submenus, when most of them may not. A good practice, IMO, is to make sure that the top-level items in your menu are links that go to a category index, or that go to the first page of your category (provided category pages have a visible secondary menu!). If plugin users think the submenus are accessible to everyone when they are not, they might overlook this kind of good practice and rely only on the submenu links for navigation. Thank you for reading. |
- [jQuery] Superfish plugin: some limitations that could be addre... Florent V.
- [jQuery] Re: Superfish plugin: some limitations that could... Charlie
- [jQuery] Re: Superfish plugin: some limitations that c... Florent V.
- [jQuery] Re: Superfish plugin: some limitations th... Charlie
- [jQuery] Re: Superfish plugin: some limitation... Florent V.
- [jQuery] Re: Superfish plugin: some limit... Charlie
- [jQuery] Re: Superfish plugin: some l... Florent V.
- [jQuery] Re: Superfish plugin: so... Charlie
- [jQuery] Re: Superfish plugin: so... Florent V.
- Re: [jQuery] Re: Superfish plugin... Charlie
- [jQuery] Re: Superfish plugin: so... Florent V.