1707185 - [Ubuntu] Screen reader only announces "alert" when Proton infobars are triggered

Status: VERIFIED FIXED

(Firefox :: Messaging System, defect, P2)

Description

[Peter Magyari (Desktop QA)]

With Proton set to on the screen reader on Ubuntu 20.04 only announces "alert" when an infobar is triggered, it doesn't read the notification itself, with Proton set to off it does read the main string when it pops up but not the buttons available on the infobar.

The role="alert" was introduced by Bug 1703172

The behaviours are different on other OS'es see Comment 4 in Bug 1703172

Comment 1

[James Teh [:Jamie]]

(In reply to Peter_M from comment #0)

with Proton set to off it does read the main string when it pops up but not the buttons available on the infobar.

Note that the buttons not being read is expected behaviour for Orca (NVDA is different). See bug 1699059 comment 6.

The notification text not being read is a nasty bug, though. This seems similar to bug 1699059, but I don't understand why it's happening in either case.

Investigation note: See bug 1699059 comment 4 for details on how Orca responds to alerts.

Comment 2

[Eitan Isaacson [:eeejay]]

Looks like the alert changed in proton to be exposed as a text interface where previously it was not.

Given Joanie's description of Orca's alert rules:

1. Building up the string from the accessible text (implemented on the alert), expanding any embedded child text objects. If that fails,
2. Descending the accessibility tree for static text objects (role static and role label) that do NOT have a labelledby relation pointing to anything. If that fails,
3. It uses the description.

The pre-proton infobar was spoken using method #2 - the alert had a direct label child.
The proton infobar should work with method #1 since it is a div[role=alert] and it exposes a hypertext hierarchy.

For some reason #1 fails, possibly because hypertext is pretty broken in our top-level chrome which is why i hypothesize the old infobar used option #2. I would try to clean up the proton infobar's tree a bit with role=presentation for the intermediate span (.notification-content) and role=label for .notification-message. This might make the tree look something like the pre-proton infobar and Orca may have better luck with it.

Not sure the ramifications for other platforms..

Comment 3

[James Teh [:Jamie]]

(In reply to Eitan Isaacson [:eeejay] from comment #2)

Looks like the alert changed in proton to be exposed as a text interface where previously it was not.

Ah. Of course. The previous info bars used XULAlertAccessible, which does not implement HyperTextAccessible. The new info bars use role="alert" on an HTML element, which does implement HyperTextAccessible.

I would try to clean up the proton infobar's tree a bit with role=presentation for the intermediate span (.notification-content) and role=label for .notification-message.

No role for "label", unfortunately.

Not sure the ramifications for other platforms..

I don't anticipate any problems on Windows at least for the changes you're suggesting.

Comment 4

[Eitan Isaacson [:eeejay]]

Updated investigation:
Orca does not use hypertext hierarchies outside of web content (ie. only its web script does that). To work with Orca there needs to be a nested LABEL or TEXT accessible. TEXT accessibles are very hard to create reliably (they are a hypertext object with no ARIA role that is display:inline).

So I will have the innermost span be a label instead. Not a great use of HTML, but it does the trick.

Comment 5

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1707185 - Make infobar messages labels for better Orca screen reader compatibility. r?mstriemer

To work with Orca there needs to be a nested LABEL or TEXT accessible. Changed the innermost span be a label instead. Not a great use of HTML, but it does the trick.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6d2e1b191856
Make infobar messages labels for better Orca screen reader compatibility. r=mstriemer

Comment 7

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/6d2e1b191856

Comment 8

[Peter Magyari (Desktop QA)]

Verified fixed on Nightly 90.0a1 (20210504214950)
The notification alert is now read as expected.

Comment 9

[Romain Testard [:RT]]

Confirming here that we (UX and PM) want this uplifted for MR1 to Beta.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:eeejay, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 11

[Mark Striemer [:mstriemer]]

Comment on attachment 9219352 [details]
Bug 1707185 - Make infobar messages labels for better Orca screen reader compatibility. r?mstriemer

Beta/Release Uplift Approval Request

• User impact if declined: Linux screen reader support for infobars, supports MR1
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): One line markup change for orca screen reader
• String changes made/needed: None

Comment 12

[Pascal Chevrel:pascalc (PTO until Sept 2)]

Comment on attachment 9219352 [details]
Bug 1707185 - Make infobar messages labels for better Orca screen reader compatibility. r?mstriemer

A11y regression fix needed for MR1, approved for 89 beta 10, thanks.

Comment 13

[Pascal Chevrel:pascalc (PTO until Sept 2)]

https://hg.mozilla.org/releases/mozilla-beta/rev/6c859cb9699c

Comment 14

[Peter Magyari (Desktop QA)]

Verified the fix on Beta 89.0b10 (20210509185840)