1572512 - Many implicit and explicit ARIA roles are not recognized

Status: RESOLVED FIXED

(DevTools :: Accessibility Tools, defect)

Description

[rwl]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

It seems the ARIA roles "banner", "main", "navigation", and "contentinfo" are not honored -- either through the implicit roles of the <header>, <main>, <nav>, and <footer> elements or by explicit inclusion of the role attribute.

• Created test documents containing:

<header>This is '<header>' and should have role 'banner'</header>
<header role="banner">This is '<header role="banner">' and should have role 'banner'</header>
<div role="banner">This is '<div role="banner">' and should have role 'banner'</div>

<main>
<nav>This is '<nav>' and should have role 'navigation'</nav>
<nav role="navigation">This is '<nav role="navigation">' and should have role 'navigation'</nav>
<div role="navigation">This is '<div role="navigation">' and should have role 'navigation'</div>
</main>

<footer>This is '<footer>' and should have role 'contentinfo'</footer>
<footer role="contentinfo">This is '<footer role="contentinfo">' and should have role 'contentinfo'</footer>
<div role="contentinfo">This is '<div role="contentinfo">' and should have role 'contentinfo'</div>

• Created variants to check the handling of <main>, <main role="main"> and <div role="main">.

Actual results:

Elements <header>, <main>, <nav> and <footer> (with or without an explicit role attribute) display as role "landmark".

<div role="banner|main|navigation|contentinfo"> display as role "section".

(This is true whether the elements were inside or outside of a <main> element.)

Expected results:

<header> and <div role="banner"> should display as role "banner".
<main> and <div role="main"> should display as role "main".
<nav> and <div role="navigation"> should display as role "navigation".
<footer> and <div role="contentinfo"> should display as role "contentinfo".

Comment 1

[Marco Zehe (:MarcoZ)]

Here's the thing about landmark roles. They are what the ARIA spec calls weak roles, in that they don't change the role that is exposed through accessibility APIs for an element. So, a div with a landmark role remains a div, and an AccessibleAttribute, a collection of all kinds of information that doesn't fit elsewhere, called xml-roles, is added. So screen readers look at the attribute array for each accessible, and if they find the xml-role to be one they know as a landmark role, they expose the landmark information.

These landmark roles were conceived before the HTML5 elements header, footer, main etc. So when these were invented, and it was clear that these bear a close resemblance to the landmark concept, they also receive the xml-role attribute, like "banner" for a header. But here's the catch: This mapping only happens under certain circumstances, not unconditionally, like ARIA roles. So a header only get mapped to banner if it is a direct descendant of body, and not inside a section, for example. Moreover, header, footer etc. get their own exposure in accessibility APIs, since these are also used in epub and other contexts. To also expose them with an xml-role that corresponds to the landmark specification, just makes it easier for screen readers to detect whether the element was intended as a landmark or not. These simply started to work as soon as browsers like Firefox started exposing them, screen readers didn't need to implement anything extra.

So, the roles you see in accessibility inspector are essentially correct, in that weak landmark roles don't influence the outcome in accessibility APIs, whereas a role "button" or "combobox" would change the semantics of the host language element, like a div.

What we could do, in theory, is indicate in the role display that this is a landmark, saving the developer the extra steps of having to look in the attributes sub tree for the xml-role value. Yura, Jamie, what do you think?

Comment 2

[James Teh [:Jamie]]

As far as I know, the ARIA spec doesn't have a concept of "weak" roles. That's something Gecko invented because there wasn't a good platform mapping for landmark roles. Both IA2 and ATK now have a role for landmark, and UIA and Mac have defined mappings for landmark roles, so this concept of weak roles should no longer be necessary. See also bug 945907, bug 1501182. (We should probably close one or two of these as duplicate.)

Even once we do that, I think Gecko will internally map these to a single "landmark" role, rather than having separate roles for each type of landmark. I think it probably makes sense for Dev Tools to include xml-roles info in the role it displays if the Gecko role is landmark.

Comment 3

[Yura Zenevich [:yzen] (please use "needinfo")]

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

As far as I know, the ARIA spec doesn't have a concept of "weak" roles. That's something Gecko invented because there wasn't a good platform mapping for landmark roles. Both IA2 and ATK now have a role for landmark, and UIA and Mac have defined mappings for landmark roles, so this concept of weak roles should no longer be necessary. See also bug 945907, bug 1501182. (We should probably close one or two of these as duplicate.)

Even once we do that, I think Gecko will internally map these to a single "landmark" role, rather than having separate roles for each type of landmark. I think it probably makes sense for Dev Tools to include xml-roles info in the role it displays if the Gecko role is landmark.

Agreed and I like the idea. Someone else was asking about a landmark role not showing up as role in the inspector so I had to point out to attributes and the xml role. I think we should add a feature where we also indicate a xml role in the tree view.

Comment 4

[rwl]

I wasn't suggesting that labeling those with the "landmark" is incorrect -- simply that it's not helpful (if the intent of the Accessibility Inspector is to give insight into the structure of your document for the sake of screen-reader UX).

I'll grant you that the role of <header>, <footer>, etc is conditional, and that fact might make them hard to deal with. But that doesn't explain why explicit role attributes on those elements are ignored.

Comment 5

[James Teh [:Jamie]]

I've cleaned up the landmark role bugs. Bug 1501182 is now the (single) bug to get the Gecko landmark role sorted out. Once that's done, the work here is to make the Inspector expose xml-roles as part of the role display if the Gecko role is landmark.

Comment 9

[James Teh [:Jamie]]

Attachment: Bug 1572512: Use ComputedARIARole for Dev Tools.

Dev Tools is primarily targeted at web developers.
Web developers are most comfortable with ARIA roles, rather than Gecko internal role strings.
This is especially true for landmarks, which map to a single landmark role in Gecko, but most Dev Tools users expect separate ARIA roles: main, navigation, etc.
We fall back to a Gecko role string for roles which can't be mapped to ARIA; e.g. iframe.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7f6bee1959fb
Use ComputedARIARole for Dev Tools. r=eeejay,devtools-reviewers,nchevobbe

Comment 11

[Serban Stanca [:SerbanS]]

Backed out for causing multiple failures.

• Backout link

---

• Pushes with failures - wpt
• Failure Log
• Failure line: TEST-UNEXPECTED-PASS | /html-aam/roles.html | el-address - expected FAIL

---

• Pushes with failures - mochitests
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | accessible/tests/browser/role/browser_computedARIARole.js | computedARIARole for htmlTbody is correct - Got "group", expected "rowgroup"

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4f5df9644784
Use ComputedARIARole for Dev Tools. r=eeejay,devtools-reviewers,nchevobbe

Comment 13

[Norisz Fay [:noriszfay]]

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

Comment 14

[Brian Thomas Smith [bsmth]]

Rolling this into Fx114 release notes under the following tracking issue on GitHub: https://github.com/mdn/content/issues/26689