Open Bug 1772614 (mr-onboarding) Opened 6 months ago Updated 9 hours ago

[Meta] MR Fx106 Onboarding

Categories

(Firefox :: Messaging System, task, P1)

task

Tracking

()

a11y-review requested

People

(Reporter: pdahiya, Unassigned, NeedInfo)

References

(Depends on 15 open bugs, Blocks 1 open bug, )

Details

(Keywords: meta)

Attachments

(1 file)

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

Alias: mr-onboarding
Blocks: bugzy-epic
Keywords: meta
Priority: -- → P1
Depends on: 1772613
Depends on: 1772615
Depends on: 1774061
Depends on: 1774063
Depends on: 1774066
Depends on: 1774067
Depends on: 1774069
Depends on: 1774070
Depends on: 1774071
Depends on: 1775306
Depends on: 1776707
Depends on: 1776691
Depends on: 1776689
Depends on: 1776686
Depends on: 1776744
Depends on: 1776863
Depends on: 1735457
Depends on: 1777507
Depends on: 1778364
Depends on: 1778419
Depends on: 1778420
Depends on: 1778601
Depends on: 1778792
Depends on: 1778796
Depends on: 1778334

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

a11y-review: --- → requested

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.

Depends on: 1779318

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.

Flags: needinfo?(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.

Flags: needinfo?(asa)

Thank you!

a11y-review: requested → ---
Depends on: 1779625
Depends on: 1779514
No longer depends on: 1774070
Depends on: 1781091
Depends on: 1781101
Depends on: 1781343
Depends on: 1781361
Depends on: 1781378
Depends on: 1781528
Depends on: 1782130
Depends on: 1782307
Depends on: 1782812
Depends on: 1783049
Depends on: 1783750
Depends on: 1783751
Depends on: 1783780
Depends on: 1784100
Depends on: 1783973
Depends on: 1784901
Depends on: 1785097
Depends on: 1784571
Depends on: 1785926
Depends on: 1786336
Depends on: 1786341
Depends on: 1786347

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.

Flags: needinfo?(jteh)
Flags: needinfo?(asa)
Depends on: 1786409

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?

Flags: needinfo?(jteh)
Depends on: 1786356
No longer depends on: 1786341
No longer depends on: 1786347
No longer depends on: 1786336
No longer depends on: 1786356
Depends on: 1786648
Depends on: 1786892
Depends on: 1786900
Depends on: 1786902
Depends on: 1786905
Depends on: 1786907
Depends on: 1786148
Depends on: 1787277
Depends on: 1786632
Depends on: 1787809
Depends on: 1788286

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).
a11y-review: --- → requested
Depends on: 1788521
Depends on: 1788885
Depends on: 1788966
Depends on: 1789192

(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.

Depends on: 1790072
Depends on: 1790125
Depends on: 1790122
Depends on: 1790126, 1790134
Depends on: 1790127, 1790129
Depends on: 1790462
Depends on: 1790474
Depends on: 1790487
Depends on: 1790490
Depends on: 1790655
Depends on: 1790660
Depends on: 1790895
Depends on: 1791135
Depends on: 1791412
Depends on: 1791426
Depends on: 1791647
Depends on: 1791677
Depends on: 1791861
Depends on: 1792263
Depends on: 1792823
Depends on: 1794485
Depends on: 1794489
Depends on: 1794637
Depends on: 1794661
Depends on: 1794702
Depends on: 1796238
Depends on: 1796699
Depends on: 1797366
Depends on: 1798561
Depends on: 1803184
You need to log in before you can comment on or make changes to this bug.