-
Notifications
You must be signed in to change notification settings - Fork 91
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
Remove unneeded tab
, tablist
and aria-selected
roles from navigation
#5075
Conversation
8e9362c
to
e924548
Compare
tests/unit/components/NcAppSettingsDialog/NcAppSettingsDialog.spec.ts
Outdated
Show resolved
Hide resolved
e924548
to
f6c5dfe
Compare
f6c5dfe
to
f2b3df2
Compare
For example, on this video, after click the screen reader focus is successfully moved on the header. However, it made many steps and went through other elements, like 5th user's action menu button (yellow square). focus-bug.mp4I tried to disable the focus trap, remove debounce unfocus, play with the link and nothing helped. If you don't have any ideas here, I'd propose to disable default link behavior for now with |
Following behavior will take place: link will be semantic link but will work as a button. That means focus will stay on links and strange focus behavior will be prohibited. Let's do that! -> Right/perfect focus isn't so important as odd screen reader behavior |
Maybe because it is handled like navigation -> reset to tabstop 0 and then move to ID? |
I tried similar navigation on MDN and it worked fine... https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-haspopup |
…ation Signed-off-by: julia.kirschenheuter <julia.kirschenheuter@nextcloud.com>
b178c78
to
edd8192
Compare
☑️ Resolves
🖼️ Screenshots
🏚️ Before | 🏡 After
No visual changes. Result: no errors through automatically a11y tests.
🏁 Checklist