How can we reproduce this bug?
What did you expect to happen?
Menu is accessible via screen reader
What happened instead?
VoiceOver on iOS only reads "menu item" for each element, and not the text of the link within the list item. The link is not accessible or clickable.
By using Foundation.Nest, role="menuitem" is added to all of the li elements within the accordion menu. menuitem requires that it is contained within an element with role group, menu, or menubar (reference) but AccordionMenu applies tablist.
@Owlbertz is this something you can look at?
Yup
From my understanding the issue is that this is an accordion, but also a menu (yes - really!). I feel like in this case it is more important to reflect the functionality of an accordion in the markup, because it is crucial to know what items are expanded.
That means I would remove the role="menuitem". And because the actual trigger for the tabs are the as rather than the lis, I guess the whole aria-controls and so on should be moved to the a?
@gapple what do you think?
Maybe @sethkane can also give his opinion?
@Owlbertz @gapple There is a whole lot of ARIA going on in that component that might not be right. I will look into it deeper but I think we might want to rework it more more like this: https://www.w3.org/TR/wai-aria-practices/#accordion
If the intent of the clickable object is only to open and not go anywhere it shouldn't be an AHREF
I would be happy to take a crack and make it more accessible across all platforms and screen readers.
@sethjgore @Owlbertz @gapple This appears to have cleared up since I'm not seeing the roles of menuitem and such. Things look to have transitioned to more of a tabbed pattern with solid aria support which is good.
Perhaps this issue is related to an old version? 6.0 accordion looking good :)
@sethkane can you confirm? (I think @joe-watkins tagged the wrong Seth here)
This is the issue that I was looking for, glad I'm not the only one. We run a government website and it is imperative that we have accessible menus.
Another accessibility issue on accordion menu that needs fixed:
http://foundation.zurb.com/sites/docs/accordion-menu.html Click on one of the demo menus and then tab to it. You can only tab between the menu items and it won't let you tab out of it
Hi @Geczy, I just made a pull request that should fix the issue with the trapped focus.
Can you give some feedback to the comment above (https://github.com/zurb/foundation-sites/issues/8680#issuecomment-228552485)?
@Owlbertz Yes that fixes the trapped focus, thank you. I applied a similar fix last week.
But the bigger issue is with accessibility software not reading out-loud the menu items.
In my instance, we have accordion menu's + child accordion menu's, and NVDA is reading the parent level links, but is completely silent for any children of the parents.
Sorry I was out of the country and now I am back in front of my computer. Is there something that you all want me to review? I am happy too.
NVDA compatibility, please.
@Geczy Ok give me a few days and I will check this out in NVDA, JAWS and VoiceOver.
Thanks @sethkane
@Geczy @Owlbertz and the rest of the crew in here. The good news is that new code works pretty good for keyboard accessibility. All of extra events (esc, arrows, etc...) make it pretty easy to use.
The bad news is that when I have a screen reader on. VoiceOver (Mac), NVDA (PC), JAWS (PC) or VoiceOver (iPhone) the accordion menu is as close to not usable as it can get.
Without listing out a large list of issues and trying to solve them one at a time I would honestly recommend refactoring the HTML and removing all the extra keyboard bindings that don't follow the standards.
This is a good example of what the HTML, ARIA and JS should look like:
http://www.oaa-accessibility.org/examplep/accordian1/
With that all being said the updated code is better than what was there before but it still doesn't solve the original issue stated by @gapple
I really want to help with this it is just a matter of time so if @Geczy doesn't want to take a crack at it I will make the time to help refactor the HTML and the JS to work with the ARIA and accessibility standards. I don't think it would take much work but it will require some extensive testing.
Keep me posted on the efforts and I will do the the same. I am traveling on business next week so I can easily start working on this while on my 4 hour plane rides.
Hope this helps and I am sorry we aren't as close to being resolved as we want.
After more review the accordion menu should follow this example: http://oaa-accessibility.org/example/41/ which I am going to start working on this week.
I am almost done with this but I am going to be forced to change Foundation.util.nest.js and I want to make sure that I update this with care. I currently have a working version with a copy of that file called Foundation.util.tree.js and it can be found here if you want to take a peak at it: https://github.com/sethkane/foundation-sites/tree/feature/issue-8680
Just submitted a PR https://github.com/zurb/foundation-sites/pull/9024
Most helpful comment
@Owlbertz @gapple There is a whole lot of ARIA going on in that component that might not be right. I will look into it deeper but I think we might want to rework it more more like this: https://www.w3.org/TR/wai-aria-practices/#accordion
If the intent of the clickable object is only to open and not go anywhere it shouldn't be an AHREF
I would be happy to take a crack and make it more accessible across all platforms and screen readers.