-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
bug(cdkTrapFocus): Sets aria-hidden to true #19502
Comments
This is working as intended. Focus trapping is a special case where this is necessary and a11y linters often report it as a false positive. |
These anchors at the book ends of a FocusTrap'ed element have focus listeners that redirect focus back to the element. However, some screen readers may access these focus traps without moving programmatic focus, leaving the SR user wondering why an empty control lives on the page. Android TalkBack currently treats this as a stop with no announcement (because it has no content). Adding the aria-hidden should prevent these from being accessed in SR contexts while preserving the core functionality of redirecting focus when it's moved linearly (e.g., with tab).
Thanks @jelbourn ! I'm hoping to report this as an issue with axe-puppeteer in that case. Do you know what criteria/marker an a11y linter could use to identify this as a special exception (since, in general, the no-focusable elements rule for |
@jelbourn could you also help clarify why focus trapped elements would need to be |
@jelbourn I think axe is technically correct. To correctly implement focus trapping we need to implement or use the inert attribute polyfill, which would essentially make focusable elements that are hidden not focusable temporarily. Otherwise, by putting aria-hidden on focusable elements you are building a UI that is confusing for screen reader users. |
We have the practical equivalent to the inert polyfill tracked in #9035. The current approach definitely isn't perfect, but has plugged along as "good enough" for the most part. IMO linters like axe are great for capturing oversights and mistakes, but in this case we did deliberately use this pattern and tested with screen-readers we support. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Expected Behavior
cdkTrapFocus
should not setaria-hidden
totrue
because hidden area elements are not supposed to have focusable content https://dequeuniversity.com/rules/axe/3.2/aria-hidden-focus?application=AxeChrome but the point of having a focus trap is so that you can use it with focusable content.Actual Behavior
cdkTrapFocus sets
aria-hidden
totrue
See comments on this commit f66302d
Environment
The text was updated successfully, but these errors were encountered: