1791072 - Decide on whether to change Firefox View Callout from role=alert to role=alertdialog

Status: RESOLVED FIXED

(Firefox :: Messaging System, enhancement, P2)

Description

[Dan Mosedale (:dmosedale, :dmose)]

+++ This bug was initially created as a clone of Bug #1790651 +++

Dan wrote:

Meg pointed me to the Slack thread where the alert choice came from.

The TL;DR bits from that conversation are that @jteh suggested it about a month ago, with the caveat:

Sure! I want to flag that this is a very difficult UI to make accessible; there isn't an established pattern for making it accessible. I can't tell you for certain that what I'm proposing will work for users; I think we're going to need to play with it and see.

We made need to iterate a little once the initial work has landed.

Emily wrote:

We might want to look at changing the role from alert to alertdialog (which indicates that the alert can/should be interacted with). It shouldn’t change the behaviour except to read “alert: dialog” instead of “alert”. However - the expectation is that the alertdialog will move focus to the expected control (from MDN):

The alert dialog must have at least one focusable control — such as Confirm, Close, and Cancel — and focus must be moved to that control when the alert dialog appears. Alertdialogs can have additional interactive controls such as text fields and checkboxes.

Right now, the “close” button gets focus, so we’d want to change that (likely to the “Next” button) which I think is too big for this patch so late in Nightly. I think we should go ahead and land this now as MVP, and then we can followup with a P2 to switch to alertdialog (maybe once the a11y team has had a chance to QA).

To which Anna responded:

And I agree, that maybe alertdialog would be preferable, but how it is now it is also a good solution. As Jamie said in the Slack discussion mentioned above, there is no set pattern for an onboarding callouts.

Comment 1

[Anna Yeddi [:ayeddi]]

For the future references, this is the WAI ARIA Design Pattern for the role="alertdialog"

Comment 2

[Russell Chan]

Attachment: Bug 1791072 - Add focus to primary button in feature callout r=#omc-reviewers

Comment 3

[Punam Dahiya [:pdahiya]]

My understanding from https://phabricator.services.mozilla.com/D157398#5169024 , assigning alertdialog is preferable but not a blocker for accessibility.

https://phabricator.services.mozilla.com/D172725#5685407

NI @emcminn to help clarify the scope and priority of work in the bug thanks!

Comment 4

[Emily McMinn :emcminn]

So MultistageProtonScreen already gets a role=alertdialog which means the callout does as well:
https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/browser/components/newtab/content-src/aboutwelcome/components/MultiStageProtonScreen.jsx#376

Originally when we filed this, we'd hoped that changing the role would fix a variety of different a11y issues that were coming up. It did fix a few, but the surface is difficult to work with! Fixing the button focus as in Russell's attached patch will take care of one thing mentioned by Jamie in bug 1817020 - I have another tentative patch to fix the other point with the document role on the upgrade dialog. With those two small fixes I think we'll be good here!

Comment 5

[James Teh [:Jamie]]

If I recall correctly, I suggested this should be an alert in the original discussion based on my understanding that this callout would be associated with a specific control, would be placed near that control and wouldn't get focus. Making it a focused alertdialog effectively restricts a screen reader user's view to that dialog until it is dismissed. (Strictly speaking, they can move out of it, but novice users most likely wouldn't understand how to do this.) In contrast, making it an alert means they can explore the surrounding content. This is different to the upgrade dialog, for example, where the user's attention should indeed be restricted to that content until it is dismissed.

That said, having tried the Firefox View Feature Tour as requested in bug 1817020 comment 3, it seems this is not actually how this works. The tour is not positioned near the control it's calling out, neither in the DOM nor with aria-owns. I'm not sure about visual positioning. That means the role="alert" idea isn't particularly useful, since the user will not see the callout in the context of its target control anyway.

The callout messaging provides enough information that seeing the callout in the context of its control probably isn't necessary. If the callout does shift its visual position, this does mean the experience isn't equivalent, but it's probably good enough for an MVP.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4f17b679d601
Add focus to primary button in feature callout r=omc-reviewers,emcminn,Jamie

Comment 7

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/4f17b679d601