1810596 - Screen reader does not announce aria-live-region with role="status"

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[Christian Sadilek [:csadilek]]

From github: https://github.com/mozilla-mobile/fenix/issues/27223.

Steps to reproduce

1. Have a tab open
2. Open https://codepen.io/simondl/pen/rNvdBQR
3. Activate the TalkBack screen reader
4. Click on button Announce A
5. Listen for the screen reader announcement
6. Click on button Announce B
7. Listen for the screen reader announcement
8. Click on button Announce C
9. Listen for the screen reader announcement

Expected behaviour

In steps 5, 7 and 9, the screen reader should read out the content of the now filled aria-live region.

Actual behaviour

In step 5, the screen reader announces the content correctly.
In steps 7 and 9, no announcement of the content is made whatsoever.

Device name

Fairphone 4

Android version

Android 11

Firefox release type

Firefox

Firefox version

105.1.0 build #2015904299

Device logs

No response

Additional information

I've tested the same behaviour also in other environments:

• Android; chrome (version 105.0.5195.136); TalkBack screen reader
  All three live regions get announced as expected.

• Desktop Windows; chrome (verison 103.0.5060.134); NVDA screen reader
  All three live regions get announced as expected.

• Desktop Windows; Firefox (version 103.0); NVDA screen reader
  All three live regions get announced as expected.

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

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

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Anna Yeddi [:ayeddi]]

This issue would cause an information loss or delay for users of screen readers. This role is being used on multiple websites and is often used to communicate the status of data submission, i.e. a purchase was successful or there were issues with the payment that have to be resolved - lack of the timely announcement of this change may cause the users to miss opportunities, i.e. during the live bidding or while following the stock price and such.

Comment 3

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

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:jonalmeida, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 4

[Ksenia Berezina [:ksenia]]

There are no reports affecting real sites at the moment, so unsetting the Webcompat priority flag for the time being.

Comment 5

[josephcsoftware]

(In reply to Ksenia Berezina [:ksenia] from comment #4)

There are no reports affecting real sites at the moment, so unsetting the Webcompat priority flag for the time being.

There's a real site affected by this bug here.

Parchment is an incredibly-major resource for playing text-based parser games in a web browser, and the interactive fiction community sees a lot of screen reader users in the player base.

Comment 6

[James Teh [:Jamie] (away returning 12 Jan)]

1. To get the text of a live region on Android, we use AccessibleWrap::GetTextEquiv.
2. That function checks if the role has eNameFromSubtreeIfReqRule. If so, it calculates the text from the subtree. If not, it uses Accessible::Name.
3. role="status" gets a Gecko role of STATUSBAR. STATUSBAR has eNoNameRule. That means we use Accessible::Name.
4. But the element also has no name! So we end up with an empty string.

Eitan, is there a reason we check for eNameFromSubtreeIfReqRule and don't allow subtree calculation for eNoNameRule? There's nothing about live regions that requires them to have a name.

Comment 7

[Eitan Isaacson [:eeejay]]

(In reply to James Teh [:Jamie] from comment #6)

1. To get the text of a live region on Android, we use AccessibleWrap::GetTextEquiv.
2. That function checks if the role has eNameFromSubtreeIfReqRule. If so, it calculates the text from the subtree. If not, it uses Accessible::Name.
3. role="status" gets a Gecko role of STATUSBAR. STATUSBAR has eNoNameRule. That means we use Accessible::Name.
4. But the element also has no name! So we end up with an empty string.

Eitan, is there a reason we check for eNameFromSubtreeIfReqRule and don't allow subtree calculation for eNoNameRule? There's nothing about live regions that requires them to have a name.

No this is very old code that was ported from our js implementation. Worth revisiting.

Comment 8

[Dennis Schubert [:denschub][OOO, back Jan 12]]

Dropping the webcompat-priority flag for now. We'll leave this to the accessibility team to triage appropriately.

Comment 9

[James Teh [:Jamie] (away returning 12 Jan)]

Attachment: Bug 1810596: When computing the text for a live region on Android, always include the text from the subtree.

Previously, we only included the subtree for roles which are allowed to be traversed during recursive name computation.
This meant that no text would be produced for live regions with roles such as status, where name computation traversal is not allowed.
Now, we first get the name to handle cases where the name is explicitly specified; e.g. images with alt text.
We then add the subtree text if the name wasn't already computed from it.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a05806b1bf18
When computing the text for a live region on Android, always include the text from the subtree. r=eeejay,geckoview-reviewers,ohall

Comment 11

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/a05806b1bf18