1772614 - (mr-onboarding) [Meta] MR Fx106 Onboarding

Status: NEW

(Firefox :: Messaging System, task, P1)

Description

[Punam Dahiya [:pdahiya]]

Meta bug tracking work needed for MR new, existing user onboarding

Comment 1

[Ania]

Description:
Please provide an explanation of the feature or change. Include a description of the user scenario in which it would be used and how the user would complete the task(s).
Screenshots and visual UI specs are welcome, but please include sufficient accompanying explanation so that blind members of the accessibility team are able to understand the feature/change.

The feature represents a group of screens presented to new and existing users upon installing Firefox 106 or upgrading to it from an existing install.
Onboarding can have varied number of steps depending on various pre-conditions (please see the full flow here).

How do we test this?
This is a pre-implementation review of the UX, however you can see the new template in the Nightly build.
Please see the pref to access the feature in Nightly in the QA ticket.

When will this ship?
Firefox 105 (behind the pref, functional, but not polished, Firefox 106 - main release

Tracking bug/issue: FIDE-700
Design documents (e.g. Product Requirements Document, UI spec):
Final Designs and Copy

Process Flows

Spec

Engineering lead: @pdahiya and @mardak
Product manager: @asafko

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
The feature inherits a lot of existing about:welcome behavior (e.g. keyboard navigability), so we mostly focused on respecting contrast requirements.

We have also ran a number of usertesting.com sessions to see how users react to various placements of buttons and a handful of screen variations, picking the best-performing ones.
Please see a full report here.

Describe any areas of concern to which you want the accessibility team to give special attention:
General flow clarity and any additional considerations we might have missed

Comment 2

[Asa Dotzler [:asa]]

I've looked over the figma designs and, as noted there, the secondary button background color does not contrast sufficiently with its adjacent color. The button will either need to be darker or some kind of border added.

Comment 3

[Ania]

Asa, just wanted to confirm that there are no other problems and if we can consider the design a11y review passed with a warning :)?

Quick update on Figma conversations here - secondary button contrast is a shared problem across the whole Design System, which the team would like to address holistically, but it's outside of the 106 release scope.

Comment 4

[Asa Dotzler [:asa]]

(In reply to Ania from comment #3)

Asa, just wanted to confirm that there are no other problems and if we can consider the design a11y review passed with a warning :)?

Quick update on Figma conversations here - secondary button contrast is a shared problem across the whole Design System, which the team would like to address holistically, but it's outside of the 106 release scope.

Yes. Good to go.

Comment 5

[Ania]

Thank you!

Comment 6

[Punam Dahiya [:pdahiya]]

Attachment: Technical Plan for Fx106 MR Onboarding

Comment 7

[Ania]

Hi Asa and James!
I wanted to give a heads up that Onboarding in Nightly 106 will be in a good shape by Monday next week (08/29) and I will be following up with the A11Y review request.
There have been no functional changes since we last reviewed the feature, but we will be landing new illustrations and backgrounds on the left hand side of the onboarding card (none of them are functional or interactive, purely visual, figma link), and wanted to make sure nothing raises alarm after the very final assets are in the build.

We also were unable to fit the success state indication that we discussed with you and James, unfortunately.

Comment 8

[James Teh [:Jamie]]

Thanks for the heads up. I'm blind, so I can't see the Figma designs, though I'm sure Asa will take a look. That said, even though you note these are not interactive and purely visual, I wonder whether we might still need to consider alt text for them. Are they truly purely aesthetic or do they somehow reinforce concepts, even if non-interactively?

Comment 9

[Ania]

James, I'm very sorry I missed your earlier message.

That said, even though you note these are not interactive and purely visual, I wonder whether we might still need to consider alt text for them. Are they truly purely aesthetic or do they somehow reinforce concepts, even if non-interactively?

The images do reinforce the concepts, but use metaphors. For instance:

• on the set to default screen, the illustration depicts a man hugging a Firefox logo.
• on the screen that prompts users to import their data from another browser, the illustration depicts a girl riding a skateboard with a box of cogs (meant to depict settings) and books (meant to depict bookmarks).

I'm not sure if the use of metaphors firmly places these images into a "decorative" category, or would it still be helpful to come up with succinct alt text for each one?

Description
Onboarding flow (about:welcome) that new users see upon installing Firefox and spotlight modal that upgrading users will see upon upgrade from 105 to 106 is live.

How do we test this?
New user onboarding instructions (about:welcome)

1. Update to the latest Nightly
2. Flip browser.aboutwelcome.templateMR to true in about:config
3. Navigate to about:welcome

Onboarding on upgrade (spotlight modal) instructions

1. Update to the latest Nightly and make sure devtools.chrome.enabled is set to true in about:config
2. Cmd + Shift + J to open Browser Console (Tools > Browser Tools > Browser console)
3. Run in the Browser console:
   Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog();

When will this ship?
Tracking bug/issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1772614
Design documents (e.g. Product Requirements Document, UI spec):
Engineering lead: Punam Dahiya, Ed Lee
Product manager: Ania Safko

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:

• onboarding screens can be navigated without a mouse,
• there is a sufficient contrast ratio between text and background,
• text and interactive elements remain functional, and have proper focus and hover states in high contrast mode (link to a known issue).

Comment 10

[Anna Yeddi [:ayeddi]]

(In reply to Ania from comment #9)

James, I'm very sorry I missed your earlier message.

That said, even though you note these are not interactive and purely visual, I wonder whether we might still need to consider alt text for them. Are they truly purely aesthetic or do they somehow reinforce concepts, even if non-interactively?

The images do reinforce the concepts, but use metaphors. For instance:

• on the set to default screen, the illustration depicts a man hugging a Firefox logo.
• on the screen that prompts users to import their data from another browser, the illustration depicts a girl riding a skateboard with a box of cogs (meant to depict settings) and books (meant to depict bookmarks).

I'm not sure if the use of metaphors firmly places these images into a "decorative" category, or would it still be helpful to come up with succinct alt text for each one?

I think, exposing those metaphors would be a huge step up in an emotional experience for users of assistive technology, for users with low vision or without vision, as well as for users with cognitive difficulties, dyslexia who rely on a screen reader to better understand the content. For example an alt="A man hugging a Firefox logo" could create very warm feeling. So would the alt="A girl riding a skateboard with a box of cogs and books".

Besides the secondary button's hover state on HCM, these are my recommendations:

1. Think the brand-logo is meaningful and an alt="Firefox Nightly Logo" is needed
2. Progress bar on the first page with the heading Open up an amazing internet is set up to be Progress: step 0 of 4 which is inconsistent with the visual presentation that has some progress on it - it’s approximately 1/4, thus Progress: step 1 of 4 would be more informative. The same applies to the next steps, i.e. a half-filled indication is announced as Step 1 of 4, the full one is only Step 3 of 4
3. Progress bar on HCM has color set to var(--grey-subtitle-1) while the progress indication uses var(--checkbox-checked-bgcolor) (aka SelectedItem) which depending on the color scheme may create low color contrast. I.e. on macOS with default blue accent color the contrast ratio is only 1.6:1 and this is the same for few other presets. The minimum is 3:1, especially because there is no textual equivalent provided to the progress indication. Using var(--checkbox-checked-color) (aka SelectedItemText) color for the progress bar background in the combination with the current progress indication color would ensure the color combination works as the user expects it to be (Selected Item background and foreground combo). This would apply for the component across platforms.
4. Colorways colors are not announced from the patch, thus the prevalent color is not communicated to the user, only its theme’s title, i.e. green color is announced as Visionary alone. Maybe, it could be Visionary (green) to provide equal information visually and in text?

Tested with macOS. I hope this helps.