Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rationale behind aria-hidden="true" on the navdrawer element by default? #209

Open
BusterNeece opened this issue Jan 1, 2019 · 1 comment

Comments

@BusterNeece
Copy link

I ran into an issue earlier today where users of my application using NVDA and Apple's VoiceOver were unable to see my application's navdrawer. After investigating, it appears this is due to the aria-hidden="true" attribute set by default on the entire navdrawer.

Looking through the JS that controls the navdrawer, I'm not finding anything that unsets this value when the navdrawer is visible. To many screen readers, this appears to make the entire navdrawer literally invisible and inaccessible.

I'm curious what the rationale behind this decision was, and if it's supposed to be fixed somewhere that I'm not seeing. If there's no purpose for it to exist there, maybe it can be removed from the main documentation?

@sesemaya
Copy link
Contributor

sesemaya commented Apr 4, 2019

Hi @SlvrEagle23,

The aria-hidden does get updated when the navdrawer is toggled.

In the doc site, the navdrawer has aria-hidden="true" to start with because the framework is developed mobile first, so navdrawer will be skipped if it's closed and pronounced if it's open.

However, I do see that there is a problem for desktop users with permanent navdrawers (e.g. doc site). When the site is loaded on desktop, the permanent navdrawer is visible but aria-hidden attribute is still applied.

A simple solution is to remove aria-hidden for permanent navdrawers from HTML markup.

A proper solution for now is to add some JavaScript that listens on window resize event and then add or remove aria-hidden attribute accordingly. I'll incorporate this fix in a future version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants