Mappings for body and html don't seem to match reality #330

joanmarie · 2021-05-11T09:27:58Z

Load the following test case in macOS, Windows, or Linux:

<html>
  <head><title>HTML Title</title></head>
  <body aria-label="ARIA label on body">
    <div>Hello world</div>
  </body>
</html>

And then load the accessible inspector of your choice for that platform to compare the tree with the mappings for body (which are documenty) and html (not mapped).

TL;DR: Everyone is essentially exposing html as the document (i.e. it's mapped). Most are exposing body as a generic child thereof -- except Firefox which is pruning it (causing the author's aria-label to be discarded).

Linux results

Chrome

[document web] name='HTML Title'
++[section] name='ARIA label on body' tag:body
++++[section] tag:div

Firefox

[document web] name='HTML Title' tag:body
++[section] name='' tag:div

Epiphany (WebKitGtk)

[document web] name='HTML Title'
++[panel] name='ARIA label on body' tag:body
++++[section] tag:div

Windows results

Chrome

ROLE_SYSTEM_DOCUMENT name='HTML Title' 
++IA2_ROLE_SECTION name='ARIA label on body'
++++IA2_ROLE_SECTION parent='ROLE_SYSTEM_GROUPING'

Firefox

ROLE_SYSTEM_DOCUMENT name='HTML Title' 
++IA2_ROLE_SECTION parent='ROLE_SYSTEM_GROUPING'

Edge

document 'HTML Title`
++ group `ARIA label on body'

Mac results

Safari and Chrome

HTML Title (HTML content)
++ ARIA label on body (group)
++++ <empty description> (group)

The text was updated successfully, but these errors were encountered:

joanmarie · 2021-05-11T10:57:48Z

Related aside: In my opening report, I said "essentially exposing html as the document." To be more clear: Functionally (as an AT developer) it sure seems that way. But technically, that might not be the case in the user agent implementations. Haven't had time to look yet; going on vague memories that under the hood something else was taking place.

scottaohara · 2021-05-12T13:43:09Z

thanks @joanmarie

looking over this today and performing my own testing, I think what you're saying here makes sense.

Right now, while body doesn't directly state it should map to role=document seems that html should be updated to do so. And then body can map to generic - as this seems reasonable / better matches reality.

If we are in agreement, I can make these changes today, and also address the html-aria issue you raised.

joanmarie · 2021-05-12T15:08:42Z

@scottaohara For the most part I agree with you.

But look at my test case in the OR. Specifically: <body aria-label="ARIA label on body"> If body maps to generic, aria-label becomes prohibited and poof goes the name! 🤣 🤣

(Yes, I came across this issue when my local implementation of name-prohibited broke aria-label on body in a Chromium test because internally in Chromium that's what body winds up being mapped to: its own kGenericContainer accessibility role. That is only an implementation detail UNTIL body becomes ARIA generic.)

So.... Maybe the element-to-ARIA-role thing needs WG discussion at least in the case of body??

scottaohara · 2021-05-12T15:29:46Z

True, but authors naming the body should be prohibited, imo :)

Testing a body with aria label, only VoiceOver (webkit and chromium) on macOS and Narrator (tested with Edge on Windows) will announce it.

iOS VO, Android TalkBack (firefox/chromium), macOS (VO+firefox), JAWS/NVDA with chromium/firefox - they all ignore the aria-label on the body, so this really isn't something that anyone should be banking on working presently - nor do i see the point of it for the future.

joanmarie · 2021-05-12T15:34:31Z

There are many things which people shouldn't bank on. But given how much fun and surprises and lack of agreement name-prohibition has unexpected led to.... Should we triple check that we all (WG members, user agent vendors, etc.) agree that aria-label on body should not be allowed?

joanmarie · 2021-05-12T21:30:15Z

Testing a body with aria label, only VoiceOver (webkit and chromium) on macOS and Narrator (tested with Edge on Windows) will announce it.

I wonder if it has anything to do with the mappings from the user agents. In the above cases, the body with the aria-label is:

Exposed
Has a grouping-containery role

iOS VO, Android TalkBack (firefox/chromium), macOS (VO+firefox), JAWS/NVDA with chromium/firefox - they all ignore the aria-label on the body, so this really isn't something that anyone should be banking on working presently - nor do i see the point of it for the future.

On Firefox, on the other hand, the body with the aria-label is getting completely pruned from the accessibility tree by Firefox. VO, JAWS, and NVDA aren't ignoring the aria-label on the body; they presumably have no idea it even exists. Maybe if Firefox didn't prune it, some screen readers would present it. (But see next point)

In Chromium on Windows (and also Linux), the body with aria-label is exposed as ROLE_SECTION. That's just like a div with an aria-label. And we all know that a (non-interactive) div shouldn't be named. 😁 Maybe if instead a body with an aria-label was exposed as ROLE_SYSTEM_GROUPING (similar to an ARIA group role), JAWS and NVDA would present it?

Mind you, I'm not saying that this means that aria-label on a body isn't a bad idea. I'm just saying that to conclude it is a bad idea based on what screen readers currently do (AKA the best they can given the accessibility tree they get) would be premature. IF the WG concludes aria-label on a body can be useful, THEN I think that mappings (and tree inclusion) which lead to that result are probably implementable.

scottaohara · 2021-05-12T22:12:57Z

Yup that all makes sense. I personally don’t see the point in allowing body to be named. But interested in if anyone can think of a use case ... well aside from the dreaded <body contenteditable>

cookiecrook · 2021-05-14T06:59:00Z

As mentioned in the call, I don't mind if there is an author MUST NOT, but I don't think there is a strong enough reason to add a "User Agents MUST NOT expose it" when it's provided.

What about the following?

<body> not mapped
<body aria-label> still an author error, but mapped to (any container role, such as group or another)

mcking65 · 2021-06-10T06:01:18Z

I think this was answered in our discussion during a call, but I don't remember the answer: Does ARIA place a requirement on browsers to not expose names of elements that prohibit naming?

If not, then is exposing the name optional? When naming is prohibited for authors, it would seem quite inconsistent to require the browser to calculate a name.

If browsers MUST not expose a name, then the spec should be consistent, i.e., body should map to generic regardless of presence of aria-label.

If browser name calculation is optional for elements where naming is prohibited, then the mapping should reflect that and say something like generic except if named. If named, generic or optionally group.

scottaohara · 2021-06-10T17:30:42Z

Per ARIA WG call today, we are going to go with body mapped to generic. authors should receive an error if they name the body with aria-label...but UAs can error correct to expose a name here, if they so choose.

`html` should have mapped to `document` - this is now corrected and the table now indicates to refer to the WAI-ARIA mapping for the document role. `body` no longer maps to `document` - which matches reality. `body` now maps to `role=generic`. further updates may be needed here for instances where authors incorrectly name a generic / provide the body with elements important to accessibility - e.g., `contenteditable`. closes #330

* blockquote update map to core aam blockquote role * fix mapping for body/html `html` should have mapped to `document` - this is now corrected and the table now indicates to refer to the WAI-ARIA mapping for the document role. `body` no longer maps to `document` - which matches reality. `body` now maps to `role=generic`. further updates may be needed here for instances where authors incorrectly name a generic / provide the body with elements important to accessibility - e.g., `contenteditable`. closes #330 * update section 3.4 introduction list * remove bullet about “?” cells. these have all been removed. * update list item about `aria-roledescription` and mention that UAs must not expose the attribute if used on an implicit `generic` element. * update aria 1.1 to 1.2 links * update json data for specs * update hgroup mapping to match reality closes #331 * point to aria 1.2 roles this PR updates the following elements to point to their implicit ARIA roles defined in core aam * caption * code * del * em * ins * meter * paragraph * strong * sub * sup * time * start marking generics starts on issue #346, indicate some of the elements that will map to, or under certain conditions map to `generic` * autonomous custom elements * div * form without accessible name * form associated custom elements * section without accessible name * typo fixed * Update index.html Co-authored-by: Steve Faulkner <[email protected]>

joanmarie mentioned this issue May 11, 2021

Is body's implicit role really document? w3c/html-aria#320

Closed

jnurthen added the Agenda label May 12, 2021

scottaohara removed the Agenda label Jun 14, 2021

scottaohara added the ARIA_1.2_roles label Aug 26, 2021

scottaohara mentioned this issue Sep 29, 2021

Updating HTML elements to map to their Aria 1.2 roles #348

Merged

scottaohara closed this as completed in #348 Nov 7, 2021

scottaohara mentioned this issue Dec 13, 2024

html-aam uses incorrect mapping for html element #571

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mappings for body and html don't seem to match reality #330

Mappings for body and html don't seem to match reality #330

joanmarie commented May 11, 2021 •

edited

Loading

joanmarie commented May 11, 2021

scottaohara commented May 12, 2021

joanmarie commented May 12, 2021

scottaohara commented May 12, 2021

joanmarie commented May 12, 2021

joanmarie commented May 12, 2021

scottaohara commented May 12, 2021 •

edited

Loading

cookiecrook commented May 14, 2021 •

edited

Loading

mcking65 commented Jun 10, 2021

scottaohara commented Jun 10, 2021

Mappings for body and html don't seem to match reality #330

Mappings for body and html don't seem to match reality #330

Comments

joanmarie commented May 11, 2021 • edited Loading

Linux results

Chrome

Firefox

Epiphany (WebKitGtk)

Windows results

Chrome

Firefox

Edge

Mac results

Safari and Chrome

joanmarie commented May 11, 2021

scottaohara commented May 12, 2021

joanmarie commented May 12, 2021

scottaohara commented May 12, 2021

joanmarie commented May 12, 2021

joanmarie commented May 12, 2021

scottaohara commented May 12, 2021 • edited Loading

cookiecrook commented May 14, 2021 • edited Loading

mcking65 commented Jun 10, 2021

scottaohara commented Jun 10, 2021

joanmarie commented May 11, 2021 •

edited

Loading

scottaohara commented May 12, 2021 •

edited

Loading

cookiecrook commented May 14, 2021 •

edited

Loading