1870354 - [meta] Accessibility Engineering Review for Select Translations MVP

Status: RESOLVED FIXED

(Firefox :: Translations, task, P3)

Description

[Erik Nordin [:nordzilla]]

Description

This meta bug tracks the implementation of accessibility-related buts for the Select Translations Feature.

Comment 1

[Erik Nordin [:nordzilla]]

Description:

This request is for accessibility review of the Select Translations Panel User Interface. We plan to enable Translations for Nightly and Early Beta in Firefox 127. Our target release version is Firefox 127 if there are no major issues, but may release in 128 if QA and A11y review find a considerable amount of work items to fix.

(At the time of writing (2024-04-19) I am still landing the final UI changes with the goal to get everything in by the QA Nightly-build deadline of 2024-04-26).

How do we test this?
At present, Translations is available in Firefox Nightly behind a pref:

browser.translations.select.enable

This pref will be enabled by default in Nightly and Early beta starting next week.

When will this ship?
Firefox 127 if no major issues are found.
Firefox 128 if QA/A11y review require substantial changes.

Tracking bug/issue:
Select Translations MVP:
https://bugzilla.mozilla.org/show_bug.cgi?id=1855907

Design documents (e.g. Product Requirements Document, UI spec):

Figma Page
https://www.figma.com/file/L1uWog572k0MvVjkgsgqY8/Select-Translaiton?type=design&node-id=621-3042&mode=design

Engineering lead:
Erik Nordin

Product manager:
Marie-Lilas Onanga Ozavino

---

The accessibility team has developed the Mozilla Accessibility Release Guidelines which outline what is needed to make user interfaces accessible:
https://wiki.mozilla.org/Accessibility/Guidelines
Please describe the accessibility guidelines you considered and what steps you've taken to address them:

Markup languages (HTML, XUL)

Is the markup semantic, wherever possible?
I believe so.

Are buttons, checkboxes, links, list boxes, etc. used from the native host language?
Yes, all UI strings utilize Fluent for localization, but we still need to move the strings out of preview. I will do this before the string-freeze deadline.

Are proper headings, lists, tables, etc. used semantically where appropriate?
I believe so.

If controls or content are visually hidden, are they also semantically hidden using the hidden attribute, CSS display: none, CSS visibility: hidden or aria-hidden?
I believe so.

Are custom widgets (containers like toolbars, dialogs, labelled groups, etc.), augmented with the proper WAI-ARIA roles, states and properties?
I believe so.

Are custom widgets operable with the keyboard?
I have put a considerable amount of design work into the keyboard navigation, given that selecting an item from the menulist dropdown triggers an action in this panel without having to click a button afterward. I would appreciate a thorough review of keyboard navigation.

Is the focus visible, even when a mouse is not used?
I believe so.

When a new screen, notification, or pop-up appears or is dismissed is the focus set appropriately? For example, when a pop-up appears, is focus moved to a control inside the pop-up? When a pop-up is dismissed, does focus return to the element which was focused before the pop-up appeared?
I believe so.

Is meaningful alternative text provided for images (or marked as decorative with an empty alt=””)?
I don't believe this is applicable because we do not have images in this feature.

Are form controls associated with a label for screen reader accessibility and bigger click targets for people who cannot accurately move the mouse or finger?
I believe so.

Text

Does the text (color) have enough contrast to the background so it conforms to WCAG 2.1 standards? For example, normal text must have a contrast ratio of 4.5:1 with its background to be valid.
I believe so. I have tried to use well-defined and preexisting CSS variables throughout the Firefox ecosystem that I hope are compatible with our themes.

Is the text zoomable and/or flow in the interface as expected?
I don't think the text is zoomable, but I do believe it flows in the interface as expected.

Does text respect Bold text or Large Text, and other text-related accessibility settings?
I believe so.

Do errors or other information indicators get communicated with more than color? For example, instead of saying “Correct all fields marked in red”, provide contextual error messages everybody can relate to, including color-blind people (roughly 8% of the population).
I believe so.

Comment 2

[Anna Yeddi [:ayeddi]]

Since there’s only one bug remains to be opened and it is likely to be caused by the chrome-wide HCM changes (bug 1894224), we could close the review task bug. Thank you for your work, Erik!