You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For accessibility, all interactive elements must be focusable, in a logical tab order, and not create focus traps. It's impossible to create an automated test for this because the browser, even with flags and permissions, will not send actual <kbd>Tab</kbd> commands. So we can’t test whether
the current focus target receives focusout/blur events or triggers any JS handlers,
the next focus target in tab sequence receives focus(in) events and triggers any JS handlers,
document.activeElement is updated, or
:focus, :focus-within styles get triggered.
Currently, this means testing must be manual. It's time-consuming and requires training if you want to be thorough. Also, certain things you want to do during this test—like test the contrast ratio of the focus styles—is tricky or impossible, even with training because once DevTools get focus, you've ruined your tab order test and document.activeElement style.
If we had this, we could create automated keyboard tests that run fast and produce accurate results. This would increase the awareness of common accessibility problems. Hopefully, over time this would help keyboard users and screen reader users.
This discussion was converted from issue #187 on December 04, 2020 22:39.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
For accessibility, all interactive elements must be focusable, in a logical tab order, and not create focus traps. It's impossible to create an automated test for this because the browser, even with flags and permissions, will not send actual <kbd>Tab</kbd> commands. So we can’t test whether
document.activeElement
is updated, or:focus
,:focus-within
styles get triggered.Currently, this means testing must be manual. It's time-consuming and requires training if you want to be thorough. Also, certain things you want to do during this test—like test the contrast ratio of the focus styles—is tricky or impossible, even with training because once DevTools get focus, you've ruined your tab order test and
document.activeElement
style.If we had this, we could create automated keyboard tests that run fast and produce accurate results. This would increase the awareness of common accessibility problems. Hopefully, over time this would help keyboard users and screen reader users.
https://webwewant.fyi/wants/2/
Beta Was this translation helpful? Give feedback.
All reactions