[meta] Ensure all interactive elements are labeled
Categories
(Firefox :: Disability Access, task, P3)
Tracking
()
People
(Reporter: ayeddi, Unassigned)
References
(Depends on 3 open bugs)
Details
(Keywords: access, meta)
We should not have any interactive elements that lack an accessible name. This would cause a blind user, a user with low vision, a user with cognitive or learning difficulties, a user with dyslexia who rely on an assistive technology such as a screen reader to not to be aware of this control's purpose, and a user with limited mobility who relies on an alternative input technology like a speech-to-text software would not be able to activate this control by calling its name.
The bug 1692110 activates accessibility checks for all mochitests that fire click events to ensure all clickable controls are also accessible (incl. that they have a valid labels/accessible names). This metabug is to be blocked by bugs filed for individual inaccessible components in our code base.
Note: per Accessibility Triage guidance, missing labels for screen reader users on icon buttons/links and other active UIs is expected to receive the Accessibility severity S2 flag, because the inability to know the purpose of this UI is blocking access to this control for a user.
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Updated•2 years ago
|
Comment 1•1 year ago
|
||
All depending bugs have been fixed.
| Reporter | ||
Comment 2•1 year ago
|
||
(In reply to Takanori MATSUURA from comment #1)
All depending bugs have been fixed.
This is true, but there are more tests that are under the investigation under the per-component meta bugs referenced in See Also.
I have about 40 more to investigate and some of them are reporting missing label, so whichever test failure would confirm that the label is really missing, I’d file here. If not, I’ll close the bug, when all the a11y-checks failures are investigated.
Thank you for checking it, Takanori! It reminds me to also revisit the See Also bugs and probably move some that are not yet fixed into the blocking side
| Reporter | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 3•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Disability Access' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Description
•