[ROLE PARITY] "generic" role for div, span, br, etc.

[cookiecrook]

HTML Role parity should include a ~"generic" role for semantically meaningless elements like div, span, br, etc.

[mcking65]

This would need to include at least two roles, one that is for block and one for inline content.

Screen readers (or accessibility APIs, not sure which) treat span as inline content and div as block content.

You can write the word "cat" with:
<span>c</span><span>a</span><span>t</span>
while
<div>c</div><div>a</div><div>t</div>
will be read as 3 separate items.

[cookiecrook]

Original comment from October. "I'm generally only board with a 1:1 mapping to HTML elements, though many of the generic ones (div, span, b, etc.) should map to the same generic role."

[cookiecrook]

@mcking65 wrote:

You can write the word "cat" with [3 spans] while [cat with 3 divs] will be read as 3 separate items.

That's an arbitrary stylistic distinction, and likely an implementation detail. In the following sample code, I've inverted your examples to be mapped as the opposite.

<span style="display:block">c</span>
<span style="display:block">a</span>
<span style="display:block">t</span>

<div style="display:inline">c</div>
<div style="display:inline">a</div>
<div style="display:inline">t</div>

So we don't need separate role mappings for inline-vs-block generics. The rendering engines can remap the generics based on display if necessary.

[mcking65]

@cookiecrook wrote:

That's an arbitrary stylistic distinction, and likely an implementation detail. In the following sample code, I've inverted your examples to be mapped as the opposite.

<span style="display:block">c</span>
<span style="display:block">a</span>
<span style="display:block">t</span>

<div style="display:inline">c</div>
<div style="display:inline">a</div>
<div style="display:inline">t</div>

So we don't need separate role mappings for inline-vs-block generics. The rendering engines can remap the generics based on display if necessary.

I think this warrants further investigation and discussion so as to avoid breaking the accessibility of what's out there today. Current representation of the above in accessibility APIs varies from browser to browser, and styling is usually ignored. In Firefox and Chrome, the spans are always read as a single word, regardless of style.

Regardless of styling, a lot of content seems to rely on the assumption that screen readers separate divs into separate items, similar to paragraphs. The opposite assumption is made for spans.

Code that is constructed otherwise is often poorly read.

In other words, a lot of the web seems to be built on an assumption of some kind of structural semantics baked into div and span. If we tell browsers to change that based on style, I fear a lot may break ... even though that may be the "technically most correct" approach.

[cookiecrook]

@mcking65 wrote:

I think this warrants further investigation and discussion so as to avoid breaking the accessibility of what's out there today. Current representation of the above in accessibility APIs varies from browser to browser, and styling is usually ignored. In Firefox and Chrome, the spans are always read as a single word, regardless of style.

Style is not usually ignored on these elements. Spans are spoken in Chrome (not sure about Firefox) because they get a different layout element in the Render tree.

Regardless of styling, a lot of content seems to rely on the assumption that screen readers separate divs into separate items, similar to paragraphs. The opposite assumption is made for spans.

I think what you are assuming was intentional is just an implementation detail. In any case, it is in Blink (Chrome) and WebKit (Safari).

Code that is constructed otherwise is often poorly read.

😉

In other words, a lot of the web seems to be built on an assumption of some kind of structural semantics baked into div and span. If we tell browsers to change that based on style, I fear a lot may break ... even though that may be the "technically most correct" approach.

I assume that was a response to this point?

The rendering engines can remap the generics based on display if necessary.

Browsers are already changing based on these styles, so I would not expect any immediate noticeable change from the perspective of the AT user. I'm proposing we put a little more explicit structure in place, so that AT can know what is explicitly meaningful vs what might be exposed now simply due to stylistic implementation details. Some AT or browsers may wish to do additional tunings.

That said, the primary benefit for the generic mapping is the test tool and automation use case. Standardizing these differences on the browser side would allow vendors to include role accessors in WebDriver thereby making ARIA much more testable.

• Currently the WebKit Accessibility Inspector on macOS and iOS returns "No exact ARIA role" for most elements like div and span. I considered including the engine's internal role.
• I believe (@alice?) that the unreleased Chrome inspector returns the engine's internal role.
• I'm not sure about Edge's inspector.

[joanmarie]

The exact nature of the role(s) will be influenced by the input we receive from stakeholders responding to the HTML element/role-parity triage. Thus adding the "blocked" label for now.

[joanmarie]

Straw poll 1: What do you think about turning the section role into a non-abstract role and using it for generic text block elements?

Straw poll 2: What do you think about creating a text role for generic inline elements?

[jongund]

Is’t that the “region” role? Jon Gunderson Sent from my iPhone On May 1, 2018, at 6:18 AM, joanmarie <[email protected]<mailto:[email protected]>> wrote: Straw poll: What do you think about turning the section role into a non-abstract role and using it for generic text block elements? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#525 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABcE7DwuEONV_4pKJUqa5lifDvtFHURNks5tuERtgaJpZM4MA7Bt>.

[carmacleod]

Straw poll 1: What do you think about turning the section role into a non-abstract role and using it for generic text block elements?

It's already confusing enough that html section is (sometimes) region without adding that html div would be section...

[joanmarie]

It's already confusing enough that html section is (sometimes) region without adding that html div would be section...

The mappings in HTML-AAM for section without a name and div are already the same for all platform accessibility APIs.

[devarshipant]

Straw poll 1: What do you think about turning the section role into a non-abstract role and using it for generic text block elements?
Straw poll 2: What do you think about creating a text role for generic inline elements?

Is it possible for both block and inline elements to map to a non-abstract version of role = structure?

[joanmarie]

Is’t that the “region” role?

It's the region role if the section has an accessible name. If it doesn't have an accessible name, it's mapped on the various platforms as a generic text block element.

[carmacleod]

Straw poll 2: What do you think about creating a text role for generic inline elements?

role="text" is kind of a zombie role, in that it keeps coming back to life. ;)
Just saying that it would need to be approached carefully, because "it's complicated".

• some background
• some related notes
• more discussion
• initial discussion
• @cookiecrook found 421 pages containing role="text" (code)
• similar to (same as?) role="static" which was written but not merged

It made sense to me for removing the image role from img and svg elements and turning their labels into plain text. I don't know the final reason(s) that it was removed from ARIA 1.1.

[joanmarie]

@cookiecrook found 421 pages containing role="text"

Sure, but that's not a role that exists in the ARIA spec. If authors are using it, I personally don't think that's a reason to not consider this role.

[carmacleod]

The mappings in HTML-AAM for section without a name and div are already the same for all platform accessibility APIs.

So section without an accessible name would be section? (even if it had a heading child)

[asurkov]

Curious, if we can go with a single role for both cases, for example, "text" role.

Having said that, I find "text" role confusing, since it's actually a text container, not text itself, if I understand it correct. So "text-container" might be a good fit.

[joanmarie]

So section without an accessible name would be section? (even if it had a heading child)

Yes. That is what we concluded in the face-to-face meeting we're having now.

[carmacleod]

Sure, but that's not a role that exists in the ARIA spec. If authors are using it, I personally don't think that's a reason to not consider this role.

True, but it was once in the draft spec, and it was removed. The most interesting question is why was it removed, because we don't want to encounter the same problem.

[joanmarie]

Alternative straw polls:

1. "div" and "span" roles (yes, HTMLy, but authors would know what they are for)
2. "block" and "inline"

[joanmarie]

True, but it was once in the draft spec, and it was removed. The most interesting question is why was it removed, because we don't want to encounter the same problem.

Working group members had quite a few concerns (some about the role, regardless of what it was called, and some about the name itself).

[asurkov]

If authors really need to say this element is a semantically block or inline, overriding computed CSS display property, then I think might be worth to consider to aria-inline/aria-block or even aria-display option (similar aria-orientation). It is flexible since

• it can be applied to any role
• can be used to create generic accessible containers

[carmacleod]

Working group members had quite a few concerns (some about the role, regardless of what it was called, and some about the name itself).

Also, I found some comments about screen reader users wanting to know that the information came from a graphic, and that we want to avoid creating a separate experience for blind users. I can understand that.

[joanmarie]

Closing this one. The generic roles are described in issue #699. All other HTML elements are included in one of the other role-parity-tagged issues.