1788253 - [meta] Feature Callout surface should be accessible

Status: NEW

(Firefox :: Messaging System, enhancement)

Description

[Meg Viar [:mviar]]

Scope of this bug is to implement and track accessibility review of the Feature Callout messaging surface (currently used for product tours and continuous onboarding messaging in about:firefoxview).

Comment 1

[Meg Viar [:mviar]]

The Feature Callout surface is used for product tours or reminders where the message is associated with a single element on the parent page. For example, pointing to a Colorways element and offering the user a quick synopsis of the feature.

A callout Feature Tour will be turned on by defauilt for about:firefoxview soon. In the meantime (or if you've already completed or dismissed the tour) you can:

• Go to about:config and set browser.firefox-view.feature-tour to {"message":"FIREFOX_VIEW_FEATURE_TOUR","screen":"FEATURE_CALLOUT_1","complete":false}
• Visit about:firefoxview

You should be:

• alerted of the modals presences after advancing in the tour (the modal moves to a new element on advance)
• able to interact with all page content while the modal is present (all content via keyboard and visible content using mouse)
• made aware of which element the modal is describing
• made aware of the text that describes the modal

Comment 2

[Anna Yeddi [:ayeddi]]

Hi team,
the following accessibility issues are observed:

1. When the about:firefoxview is opened, the screen reader focus jumps to the onboarding callout, which is expected (I assume), but when the screen reader completes reading its content, it proceeds to read the main page content from the middle - from the Colorways section and then to the Recently closed one. This will cause users missing the top of the page, incl. the synced tabs.
2. Programmatic rading order of the first callout is not following the visual reading order - the Next button is announced before the stepper which is placed on the left (for English and other LTR, stepper needs to be announced first)
3. Stepper is marked up as a meter while that widget is not expected to be used in this case. Instead, the progress bar is expected (either preferred HTML <progress> or ARIA-powered role="progressbar")
4. Stepper announces that it's on the step 0 of 4, while 1 of 4 would be expected to be more human-friendly :) Plus, the aria-valuemin is set to 1
5. Stepper is announcing that it is a vertical level indicator on macOS - it should be horizontal (which is implied for either progress bar pattern, see #3 above)
6. The dialog does not follow the HCM styling for controls on hover: Close and Next/Got it! should have their colors reversed on hover, but the Close icon disappears on Win and is almost invisible on mac.
7. Next does not follow Windows HCM colors for buttons: expected to use ButtonText and ButtonFace, but the outline is using text color (white on WinOS 11 Night Sky HCM, as an example, while yellow is expected)
8. on MacOS the dialog title is not announced by VoiceOver - the code looks good, so this is likely more general bug?
9. The stepper indications are hard to see: without HCM/Increase contrast on dark mode the color contrast for the future steps is only 2.2:1 while minimum per WCAG is 3:1 and higher is better. Users may find it difficult to predict how many steps are left or are passed as the inactive dots are hard to see. With HCM on, the contrast is still low. Maybe, using WindowText for inactive dots and SelectedItemtext for the current step dot be appropriate?
10. When Close button is activated, the programmatic focus lands inconsistently somewhere on the page to any item that was under the Close button. It is expected that the focus would return to the top of the page, if the user did not navigate the page prior to getting on the onboarding popup. But if the user wandered around, the best place to return the focus would be the last focusable element before the onboarding popup was injected in the DOM or on the topmost element right after it, i.e. when the last popup is dismissed, the focus could be placed on the aside section for Colorways, for instance with the tabindex="-1" on the Independent Voices heading, so the user does not miss any piece of the content after the dismissal
11. Escape should dismiss the popup whenever the focus is placed at the moment - this allows users to avoid covering up the content and is an expected keyboard behavior pattern

I hope it helps, let me know if any further information is needed

Comment 3

[Jason Prickett]

Noting here that in Bug 1786347 we're changing the parent element of the callout container to document.body, rather than the parent of the element that it is calling attention to, and using aria-owns as an accessibility band-aid.

The reason for this is because the positioning of the callout container can break depending on the callout container parent's position, and we can't guarantee that the position of the parent element will always be non-relative.

Comment 4

[Meg Viar [:mviar]]

Thank you for this helpful feedback, :ayeddi!

Per 11 - Product explicitly requested that escape not close the Feature Callout (CCing :vtay). Does this pose enough of an accessibility issue that we should rethink this approach?

Comment 5

[Anna Yeddi [:ayeddi]]

Attachment: 2022-09-12 Onboarding tooltip covers a focused control.png

(In reply to Meg Viar from comment #4)

Thank you for this helpful feedback, :ayeddi!

Per 11 - Product explicitly requested that escape not close the Feature Callout (CCing :vtay). Does this pose enough of an accessibility issue that we should rethink this approach?

While it is not a direct WCAG violation, using Escape to dismiss a dialog or a tooltip is one of best practices, because it is a well-known and widely used keyboard shortcut.

In this case, the tooltips are covering not only the content but also controls (as shown on the screenshot for the Recently closed expand/collapse control example), so this would require an additional step to be performed for users with limited dexterity, those who use a voice control or a switch device/software - they will need to navigate back to the tooltip's Close button to dismiss the dialog. Also, with overlays, it is not clear in which direction should they move the focus to get back to the dialog once the focus has left it. Unfortunately, often on other webpages returning to similar tooltips is not possible and this is what they're likely to expect too.

Using Esc to dismiss the dialog would be an accessibility improvement, but it is not a blocker in any way, because after all the Close button is accessible (is labeled, focusable, functional). I am curios to know what the concern with using the Esc is, maybe we can find a workaround too

Comment 6

[Vtay]

Yes, we should allow for "esc" to dismiss the dialog. This is an oversight on my end.

Comment 7

[Meg Viar [:mviar]]

We'll need to add new dismiss telemetry to catch this (similar to how we handle it with spotlight) and update the QA plan. Is it acceptable if this doesn't make it into 106 @vtay?

Comment 8

[Vtay]

Yes. Ideally it should land in 106, if not, 107 works.

Comment 9

[Vtay]

Thank you for the feedback.
These are my thoughts on how we should prioritize these items
Let me know if there are any concerns.

1. This sounds like a bug and that is should read from the top of the page (P1)
2. Yes. The stepper should be announced before the Next button (P2)
3. This is fair, but i think it’s a nice to have (P3)
4. This is fair, but i think it’s a nice to have (P3)
5. This is fair, but i think it’s a nice to have (P3)
6. This looks like something we should fix especially if icons disappear/are invisible. (P1)
7. This looks like something we should fix but it is not a top priority (P2)
8. This sounds like something that we should investigate and fix (P2)
9. This is something we should fix especially if it is hard to see; but a little less concerning given its stepper indication (P1/P2)
10. This looks like something we should fix if we can (P1)
11. We should fix this per a11y’s request (P2 - ok to leave until 107 )