1834384 - [meta] Accessibility Engineering Review for Full-Page Translations MVP

Erik Nordin [:nordzilla]

Reporter

Description

•

1 years ago

•

Edited

Description:

This request is for accessibility review of the Translations user interfaces. We plan to enable translations for the upcoming early-beta cycle for Firefox 115. Our target release version is Firefox 117 and we would like a11y feedback.

This includes:

The Translations Panel

The default translations menu
The translations settings menu
The translations-active menu

The Translations Section in about:preferences

The main translations section
The download languages menu
The settings panel

(At this time, we are still landing some final UI changes after receiving direction from UI/UX designers. I will attach screenshots with descriptions once this finalized design work has landed).

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

browser.translations.enable

but we plan to enable the feature by default for two rounds of QA.

Round 1
Firefox Early Beta 115

Round 2
Firefox Beta 116
Firefox Nightly 117

When will this ship?
The plan is to ship in Firefox 117.

Tracking bug/issue:
Translations Meta Bug
https://bugzilla.mozilla.org/show_bug.cgi?id=971044

Translations Desktop MVP
https://bugzilla.mozilla.org/show_bug.cgi?id=1820214

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

Shared Google Drive
https://drive.google.com/drive/u/0/folders/0AAn-gmG2-CJoUk9PVA

Figma Page
https://www.figma.com/file/GT6oZLFw32LiCwKl5GOMWD/Translation?type=design&node-id=0-1&t=OHhjnTb2bs3aMEfZ-0

Engineering lead:
Greg Tatum

Product manager:
Asa Dotzler

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.

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 am not sure on this. We do use role in the translations panel.

Are custom widgets operable with the keyboard?
I have used the keyboard to navigate within the panel and settings, though I am not sure if it is optimal/correct.
Feedback here would be much appreciated.

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. Though perhaps something related to the translations icon SVG displayed on the translations button may be relevant here.

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.

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 don't believe this is applicable to this feature.

Anna Yeddi [:ayeddi] ⛔ Out of office until November 12 ⛔

Assignee