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.
