1892336 - [about:welcome] Import wizard Accessibility Review

Status: NEW

(Firefox :: Messaging System, task, P1)

Description

[Negin Sauermann]

We had an initial accessibility review of 1839431 but there have been changes to the embedded migration wizard since the initial review 9 months ago and the review may be outdated as a result. There's an interest from the accessibility team to perform a re-review and scope out any accessibility work.

Description:

Scope of this review will cover the new embedded import wizard screen which has been added to the about:welcome flow embedded import wizard flow. This will be the default experience for Mac, Windows, and Linux builds. The technical plan document covers the designs and intended experience as well as all the patches that were involved.

How do we test this?

Test plan can be found in the QA steps in the technical plan document

When will this ship?

This shipped as default experience in Fx117.
Tracking bug/issue: Meta Bug / FXE Jira bug
Design documents (e.g. Product Requirements Document, UI spec):
Engineering lead: Negin Sauermann ([e-mail])
Product manager: Najla Bulous ([e-mail])

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:
As most of the work has been repurposed from the work with the new migration wizard, nothing in regards to this has changed since the last review.

Describe any areas of concern to which you want the accessibility team to give special attention:

I don't believe there's any special attention required to anything in particular.

Comment 1

[Negin Sauermann]

These were the findings from the previous audit, I'll take a look to see if any of these were addressed and update this comment as needed.

The Import Browser Data Dialog

1. The button menu does not get an aria-expanded value until the user has expanded it for the first time. So, NVDA doesn't tell users that the button is collapsed on first interaction.
2. After selecting a browser (open button menu, choose an option, press enter), NVDA reads the previously-selected option, even though a new option has been selected. It'll say, "Chrome profile 1 button expanded sub menu" after you press enter on a different option, if Chrome was the previously-selected option.
3. This button: <button data-l10n-id="migration-import-button-label" disabled="">Import</button> reads as "button unavailable Import" and is present after the "Import" button. I don't think it should be there since it's not visible and does nothing. Weirdly, sometimes it isn't there, and I'm not sure why. Either way, it's offscreen and I think it can be removed from the markup.
4. The browser data selection checkboxes should be grouped one way or another so that assistive technologies see them as a group and can announce something like "clickable Favorites checkbox checked 1 of 4," where "1 of 4" is the thing of interest. I think that giving the inputs the same "name" attribute can group them. This page has examples. You might also want to use <legend> with the <fieldset> or use aria-labelledby, referring to #resource-selection-summary. However you do it, it'd be nice to have the checkboxes in a group so users know how many to expect.

Data Import Complete page

5. After importing, NVDA reads: "dialog dialog button import continue button." I think a screen reader user would want to know whether the import succeeded. It's unclear without some searching around the dialog, and the user gets landed on the Continue button. Perhaps role="status" on the heading is appropriate here? Or we could land focus on the completion status heading?
6. The yellow caution sign icon is labeled "completed" which is the same label as the green check mark icon. Visually it looks like something went wrong, but as a screen reader user I can't tell the difference.
7. The "Import Browser Data" content from the last page is still available even when it's not visible on screen. If you keep arrowing down with NVDA you'll hit it. It's not in the tab order, luckily, but it's still in the accessibility tree, so assistive technology clients still see it. This is pretty confusing since it comes immediately after the "continue" button, which makes you think you've done something incorrectly. Can we remove this content (or hide it from assistive technologies) once it's no longer on screen?
8. There's a "skip this step" button even after you've successfully imported things from another browser. But you already did this step, I think.

High Contrast Mode

9. Checkboxes don't conform to our HCM standards. Please see this page for guidance on how to color checkboxes.
10. The outlines of checkboxes (i.e., from tab focus) on the first page are partially covered in the top and left sides.
11. The "send a download link" link on the "hop from laptop to phone and back again" screen should use the link color. In Windows 11 Night Sky, it should be purple-ish, not yellow. See this guidance (not fully fleshed out yet).
12. The HCM-ified graphics are okay but not necessary. We're concerned about a few things with these:
    a. The yellow background colors (on Windows 11 Night Sky) appear to be the same as the yellow for form controls. That yellow has semantic meaning, so using it in large swaths in the image can be confusing.
    b. The brightness of the yellow may be a bit overwhelming for people with photosensitivity, particularly against the black background.
    c. Consider replacing the yellow (button text) with black (canvas color) and black with white (canvas text).
13. The secondary buttons (Sign in, Skip this step) don't use the button background color, but should. On Windows 11 Night Sky, they're black but should be more gray.
14. The import browser data button menu doesn't conform to our HCM standards. See this page (in the menu button section).
15. The "Import all available data" expansion/collapse (+, -) button is a button and should be styled that way in HCM.
16. The focus outline on button menu items should be white only, not white and blue.

General Notes and Other

18. The text is cut off and a horizontal scrollbar pops up with 400% browser zoom on 1280px width, see WCAG 2.1 Success Criterion 1.4.10 Reflow. We don't want to have a horizontal scrollbar at that zoom level.
19. The "send a download link" link is <a role="button">. If you can, I think it should be a link that uses <a href="">. The span that contains it also has role="button" and is clickable, which is a bit confusing. When tabbing through the page, you hit the span, then the link, and both are buttons, which is strange.

Comment 2

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

Refer to the comment #1