1563598 - HTML output element should be mapped to ARIA role=status

Status: VERIFIED FIXED

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

Description

[scottaohara]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Go to the following test page:
https://scottaohara.github.io/tests/html-output/reduced-test.html

With a screen reader on (NVDA/JAWS/TalkBack) press the button in each of the test cases (mouse click, touch, space/enter keys). Content will be injected into each test's output element.

Listen for announcement of injected content.

Actual results:

Injected content (nor accName of output elements for applicable tests) is not announced.

Inspecting the API mappings, MSAA reports a accRole="output", and IA2 role="section". These do not match the HTML AAM expected mapping of ARIA's status role: https://w3c.github.io/html-aam/#el-output

Expected results:

For test 1, the injected content should have been announced as a "status" / aria-live polite announcement

For test 2, the accessible name of the output (provided by the label element) and the injected content should have been announced as a "status" / aria-live polite announcement.

For test 3, the accessible name of the output (provided by the output's aria-label) and the injected content should have been announced as a "status" / aria-live polite announcement.

For comparison, inspecting the API mappings for Chrome, MSAA and IA2 report as "status bar", which is expected.

Note: this is an issue with both desktop and Android Firefox (tested 68.0 preview release).

Comment 1

[Marcos Caceres [:marcosc]]

Jamie, if there are examples of how to fix these kinds of bugs, I'd be happy to help on the DOM side. I'm tracking the HTML-AAM spec so can add roles to HTML elements or whatever needs to be done... Let me know! Otherwise, I'm happy to leave for your team to pick up as folks become available.

Comment 2

[James Teh [:Jamie]]

(In reply to Marcos Caceres [:marcosc] from comment #1)

Jamie, if there are examples of how to fix these kinds of bugs, I'd be happy to help on the DOM side. I'm tracking the HTML-AAM spec so can add roles to HTML elements or whatever needs to be done...

Thanks so much for the offer of help. It's really appreciated.

For most cases, how an HTML element is mapped is determined here:
https://searchfox.org/mozilla-central/source/accessible/base/MarkupMap.h
We add tests here:
https://searchfox.org/mozilla-central/source/accessible/tests/mochitest/elm/test_HTMLSpec.html
For simpler cases, everything is expressed in the map; e.g. article, blockquote, del/ins, p. For more complex elements that need code beyond what we can express in our maps, we have additional code and testing elsewhere.

We actually already have a mapping for <output>:
https://searchfox.org/mozilla-central/rev/1097f59d0bc17f6f8f805325c2f607e60cf0d26b/accessible/base/MarkupMap.h#394
That mapping needs to be corrected so it has the status bar role, which should be trivial. However, that won't fix the behaviour as a live region. That will need to be handled by the a11y team; see below.

In bug 1140500, the Attr(live, polite) bit was added, which is supposed to make this a live region. Unfortunately, while that does cause the live:polite attribute to be added, it doesn't expose container-live:polite on the output and its descendants, so a11y clients won't see this as a live region.

The reason this isn't exposed is that nsAccUtils::SetLiveContainerAttributes deals with DOM attributes and attributes from ARIAMap, but not attributes from MarkupMap. Fixing that is probably going to be a bit tricky.

Comment 3

[James Teh [:Jamie]]

Implementation note: we'll need to add code to nsAccUtils::SetLiveContainerAttributes, probably near where we deal with the ARIA map stuff:
https://searchfox.org/mozilla-central/rev/1097f59d0bc17f6f8f805325c2f607e60cf0d26b/accessible/base/nsAccUtils.cpp#140
It'll need to process attributes in the markup map using code similar to nsAccessibilityService::MarkupAttributes:
https://searchfox.org/mozilla-central/rev/1097f59d0bc17f6f8f805325c2f607e60cf0d26b/accessible/base/nsAccessibilityService.cpp#1450
mHTMLMarkupMap is private to nsAccessibilityService, so some of this code will need to go in there. Perhaps we could add nsAccessibilityService::MarkupAttribute, similar to the existing nsAccessibilityService::MarkupRole.

Comment 4

[James Teh [:Jamie]]

STR:

1. Open this test case:
   data:text/html,<output><div id="inner">Test</div></output>
2. Right click the document and select Inspect Accessibility Properties.
3. In the accessibility tree, examine the node beneath the document node.
   • Expected: It should have a role of status bar.
   • Actual: It has a role of section.
4. In the accessibility tree, select the node beneath the document.
5. In the accessibility properties for this node, examine the attributes.
   • Expected: There should be a container-live attribute.
   • Actual: There isn't.
6. In the accessibility tree, select the "section" beneath the node you selected in step 4.
7. In the accessibility properties for this node, examine the attributes.
   • Expected: There should be a container-live attribute.
   • Actual: There isn't.

This work should be split into two patches.

One patch should deal with mapping the output element to role STATUSBAR (fixing step 3 above). See comment 2.

The other should deal with container-live (fixing steps 5 and 7 above). See comment 3. Add tests for that in accessible/tests/mochitest/attribute/test_obj.html.

Comment 5

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1563598: Change output elements to have statusbar role instead of section role.

Comment 6

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1563598: Display 'container-live' attribute on descendents of implicitly-live elements. r=jamie

Depends on D45402

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d647bd5b0b29
Change output elements to have statusbar role instead of section role. r=Jamie
https://hg.mozilla.org/integration/autoland/rev/968ef845dc64
Display 'container-live' attribute on descendents of implicitly-live elements. r=Jamie

Comment 8

[Dorel Luca [:dluca]]

Backed out 2 changesets (bug 1563598) for Mochitest failures on accessible/tests/mochitest/tree/test_formctrl.html. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=266406782&repo=autoland&lineNumber=3700

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=968ef845dc64264118c667f00a5e1b8c43b5d7f1

Backout:
https://hg.mozilla.org/integration/autoland/rev/eff20680fd653d5a771ad82c7fc95476e40bd35b

Comment 9

[Morgan Reschenberg [:morgan]]

;=; oh no
I'll fix this sorry!

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ab38f605155c
Change output elements to have statusbar role instead of section role. r=Jamie
https://hg.mozilla.org/integration/autoland/rev/bafede36df6d
Display 'container-live' attribute on descendents of implicitly-live elements. r=Jamie

Comment 11

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/ab38f605155c
https://hg.mozilla.org/mozilla-central/rev/bafede36df6d

Comment 12

[Daniel Bodea [:danibodea]]

Attachment: partial fix question mark.png

According to comment 4 it seems like only the first 3 steps of the STR can actually be verified. I think this is a partial fix in both latest Nightly and Beta.
Can you have a look? thanks!

Comment 13

[James Teh [:Jamie]]

(In reply to Bodea Daniel [:danibodea] from comment #12)

According to comment 4 it seems like only the first 3 steps of the STR can actually be verified.

I'm blind, so I can't see the screenshot you attached, but:

1. I do see the container-live: "polite" attribute show up as expected when I test here.
2. I ran OCR on the screenshot and I do see container-live show up there. I can't be certain what node it's referring to, though.

Can you clarify what you're not seeing? Thanks!

Comment 14

[Daniel Bodea [:danibodea]]

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

STR:

1. Open this test case:
   data:text/html,<output><div id="inner">Test</div></output>
2. Right click the document and select Inspect Accessibility Properties.
3. In the accessibility tree, examine the node beneath the document node.
   • Expected: It should have a role of status bar.
   • Actual: It has a role of section.
4. In the accessibility tree, select the node beneath the document.
5. In the accessibility properties for this node, examine the attributes.
   • Expected: There should be a container-live attribute.
   • Actual: There isn't.
6. In the accessibility tree, select the "section" beneath the node you selected in step 4.
7. In the accessibility properties for this node, examine the attributes.
   • Expected: There should be a container-live attribute.
   • Actual: There isn't.

This work should be split into two patches.

One patch should deal with mapping the output element to role STATUSBAR (fixing step 3 above). See comment 2.

The other should deal with container-live (fixing steps 5 and 7 above). See comment 3. Add tests for that in accessible/tests/mochitest/attribute/test_obj.html.

The node beneath the document node is named "statusbar" in Nightly v72.0a1, compared to the same node in Release v70.0.1 where it is named "section". This verified the Expected result after step 3.
Furthermore, I misunderstood that we are should be looking at the node of the deeper node (under the "statusbar" node), when I should be looking at the attributes of the "statusbar" node. There i cand see that a "container-live" attribute with value "polite" is present in Fx72, compared to Fx70. This expectancy after step 5 is also verified.
Even further, in the last part of the steps to verify, I should be verifying that a "container-live" attribute is present for the "section" node (3rd node deep) under the "statusbar" node. This part is also verified.

Sorry for the hurried verification. I deem this bug verified in Nightly v72.0a1 and Release Candidate v71.0. Thank you!