menu children not displaying in screen readers -- accessibility issue

Thanks for flagging this issue. I don't think I'd seen the text only window for Webaim's Wave tool.

I ran your site through a bit of testing on http://fae.cita.uiuc.edu & http://www.tawdis.net & found some issues, but not tied to Nice Menus. All of these automated tools really are only a partial indication of problems to address however.

Because I was looking at this issue for a client I checked to see that it could be navigated by keyboard only & through VoiceOver. The keyboard navigation seemed to be fine, but the tab order was wrong. I think this mostly has to do with the location of this element in the DOM. VoiceOver seemed to go through the visibility: hidden css without difficulty. Having an invisible Heading before the navigation list would be useful for screen readers to understand what that list is that they are navigating through.

This isn't an exhaustive survey of Nice Menus' accessibility. I'm not sure if it will work in Jaws or if it will work well for blind people who use screen readers more intensively than I do.

If anyone has suggestions or solutions, feel free to work on them. There are several accessibility features in the NM queue now: http://drupal.org/project/issues/search/nice_menus?issue_tags=accessibility

This relates to a problem I am facing:

I need to change the size of a menu created in a view and attached to my horizontal drop down main page menu.

I write the CSS as such:

ul.nice-menu-down li ul li.menu-path-2012-teams ul

where the class 'menu-path-2012-teams ' uniquely identifies this particular menu.

Problem is that the ul above it is showing inline code:

style="visibility: hidden; display: none;

The problem stems from the fact that 'display:none' makes that UL invisible in the dom and on page load the line of CSS is not parsed into the DOM. So it can never execute. (Suspect this is why screen readers can't find the text to read.)

I need to hack the module to only write in 'visibility none' so that the DOM can recognize the element and apply my custom width to this drop-down menu.

Any help?

Forgot to change the status.

We're run into the same inline style issue (for a different problem), and resolved it by using the !important override in the CSS to override the inline attribute

I assume this is still an issue in D7.

I may be missing other important threads on this topic. If so, I would be glad for someone to point me to them. If not, then I'd like to contribute my experience. A quick review by an accessibility consultant confirmed that our site menu was not initially accessible.

I am using the D7 version, and found it necessary to override several of the CSS styles in the base ("logic") CSS file, nice_menus.css. I did so in my copy of nice_menus_default.css, which I pointed to in nice menus' configuration page. As theresel suggested, I used the !important CSS override to prevent the submenus from having their display style set to none. (I didn't try to deconstruct the javascript logic in Superfish, but I suspect the jQuery .hide() method is in use, which sets the display style to none inline.)

This was critical because in our site the items of the top-level menu are set with <nolink>; only the submenus contain links. Without links, the top-level menu items could not be activated using the keyboard (tabbing from link to link) to open the submenus. Therefore the menu was not accessible to a non-mouse-user, even using screen-reader software such as JAWS.

(With that kind of software, you can use keyboard shortcuts to navigate directly to different document elements (for example, lists and list items), but that kind of navigation doesn't move the system caret (focus) or system cursor, so it doesn't activate the submenus.)

In the end, I opted to alter the CSS to force submenus to have visibility:visible and display:block all the time, to hide them from sighted users with clip:rect(1px,1px,1px,1px) and overflow:hidden, and to show them with clip:auto and overflow:visible. Now I can tab directly to submenu links because the submenus are 'visible' even when their parents have not been activated to open them. It is also helpful to have all the submenus expanded for screen-reading software in the event that the screen-reading software is reading in "skim" mode. In this mode it just reads from start to finish, without moving the system caret.