Open
Bug 1836304
Opened 1 years ago
Updated 6 months ago
Make Translations section in about:preferences a richlistbox
Categories
(Firefox :: Translations, defect, P3)
Firefox
Translations
Tracking
()
NEW
Accessibility Severity | s3 |
People
(Reporter: ayeddi, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: access)
Attachments
(1 file)
826.37 KB,
image/png
|
Details |
STR:
- Ensure a screen reader is running
- Navigate to the Translations Section in about:preferences
- Use
Tab
to move focus to theDownload Ukranian
language option
Actual:
- Keyboard-only users would need to tediously navigate past multiple
Download
andDelete
(when applicable) buttons to access one of languages closer to the end of the list or to even pass this section in the Preferences. This would make keyboard navigation within the page very cumbersome and it would be getting worse with the Translations adding more languages to the list. This would create a high impact on a large diverse set of users, while the issues below are lower severity, but still are not delightful - Screen reader users would have multiple repetitive
Download
andDelete
(when applicable) buttons present and even if they'll utilize a list of controls/buttons provided by their screen reader, it would still be nearly impossible to discern which button should be activated to download/delete specific language. It would make the usage especially confusing for users with cognitive difficulties (who rely on screen readers often too) - Scrollable area in Translations section in about:preferences lacks accessible name, thus a screen reader user will have to memorize the heading of the section and the text above the list of languages to know what is the purpose of this list of downloads, affecting users with lower cognition abilities as well
- For users with low vision, those who uses magnification software, physical magnifiers or just move next to their screen, discerning which row the button is applicable to may be harder, because the buttons are far removed to the right side from their corresponding labels and the focus outline only is provided to the button itself
- Voice control users would not be able to activate a button by calling the language's name and would have to add an extra step by calling the on-screen label
Download
> then call a number that the voice control software would associate with their desired language.
Expected/Recommended:
- Use
RichListbox
component that other sections likeApplications
are using in the about pages - it should be customizable afaik and would provide all the keyboard accessibility and other accessibility-related roles, states, and attributes for free and resolve or simplify all the above barriers for users. If more info is wanted, refer to the listbox ARIA-powered design pattern that RichListbox is building on
Comment 1•1 years ago
|
||
Note that the correct keyboard behaviour for richlistitem child buttons was implemented in bug 1329643, so you shouldn't need to do anything special to get this working as expected (as you would have in the past).
See Also: → 1329643
Updated•1 years ago
|
Accessibility Severity: --- → s3
Whiteboard: [access-s3]
Updated•1 years ago
|
Severity: -- → S3
Priority: -- → P3
Updated•1 year ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•