Concerning the "generic" role

[WilcoFiers]

I have a few reservations with distinguishing the role "generic" from role "presentation". ARIA 1.1 isn't explicit about this, but example 8 (under presentation) indicates that span elements implicitly have no role:

For example, according to an accessibility API, the following markup elements would appear to have identical role semantics (no role) and identical content.

<!-- 1. [role="presentation"] negates the implicit 'heading' role semantics but does not affect the contents. -->
<h1 role="presentation"> Sample Content </h1>

<!-- 2. There is no implicit role for span, so only the contents are exposed. -->
<span> Sample Content </span>
...

It is not at all unreasonable to assume the same is true for div, which is how most browsers have interpreted this. In all Chromium / Webkit browsers (as best I can tell), a div is treated as having no role, the same way putting role="presentation" on other elements. The only major browser that seems to differ from this is Firefox, which treats div elements as containers.

Where this matters is in things like set size counts. The following code snippet is counted in Chrome as having 3 items, but in Firefox it is counted as having 2:

<span role="menu">
  <a href="" role="menuitem">Home</a>
  <span>
    <a href="" role="menuitem">About</a>
    <a href="" role="menuitem">Contact us</a>
  </span>
</span>

I think Chromium / Webkit do the right thing here in excluding these span elements from the accessibility tree. That is definitely consistent with what ARIA 1.1 says about span elements in example 8.

This type of pattern is very common. You can see it a lot in component architecture. It produces "div soup". Parent-child relationships quickly get disrupted by wrapping components in deeper abstraction layers. This isn't a big issue in Chromium because it just won't put the div in the accessibility tree, and that menuitem will still be counted as a child of menu.

Introducing the role generic seems like it will make some fairly common patterns more difficult to make accessible. I am not all too sure why anyone would want an element with a generic role in their page at all. When using div, you'd either want it ignored, or for it to have some type of role, like group. The only explanation there is in ARIA 1.2 is this:

A generic can provide a limited number of accessible states and properties for its descendants, such as aria-live attributes. This differentiates it from the presentation role.

But the problem with this is that the generic role has the exact same allowed attributes as presentation does. You can use aria-live on an element with presentation. I'm not sure it works, but if not, that's something browsers need to fix.

In short, can the generic role be removed?

[JAWS-test]

Related: #699 and #525

[carmacleod]

@WilcoFiers

can the generic role be removed?

I think the best argument for keeping generic separate from presentation was summarized in #699 (comment):

@cookiecrook commented:

Generic containers like <span> are exposed to the API so that assistive technologies can gather certain properties such as layout and bounds. This allows VoiceOver to enlarge the cursor for low vision users, Switch Control to simulate mouse or drag events, etc. These elements are conveyed to the APIs… the distinction is that the role is irrelevant, or generic.

@mcking65 replied:

Thank you for the assistive tech dev use cases. Those, combined with the case of the generic being focusable, are sound reason for having the role rather than mapping to none.

[cookiecrook]

Wilco does bring up a good point that the prose for "generic" role may need to be changed.

[cookiecrook]

@WilcoFiers, are you proposing HTML-AAM role mapping for div and span be the none role? What about the other style-related inlines, like b, I, etc?

[cookiecrook]

If so, the HTML-AAM for this might get a little complicated. It might be doable, but I hadn't considered it before and want to call out some potential fallout.

IIRC, WebKit and some others map none/presentation by not exposing the current node, and instead promoting its child nodes one level higher in the tree.

For plain <div></div> with no attrs, none might be fine... but sometimes non-ARIA attrs can cause the element to be exposed to the accessibility tree. For example, @tabindex obvs, but also @name, @id, and a few others. HTML-AAM might need to make very explicit rules about when it was okay to map to none.

Mapping to none would also leave the computed role ambiguous in cases like <div tabindex="0"> which then negates the TTWF testability benefit through WebDriver. I realize it's not ideal for an author to add @tabindex without defining a role, but when they do (and they do), we should all agree on how the UA and AT handle that error case. A generic role (separate from none) is how I proposed it, but I'm open to other options if these concerns can be alleviated.

[WilcoFiers]

@cookiecrook Hey James! And, thanks for the background info @carmacleod.

I know that Webkit decides between none and generic (I think it's called container?) based on attributes. It works quite well, but it seems to me that part of the reason for doing this is that it isn't possible to make presentation/none fulfil this function. In an ideal world, VO would be able to outline focused divs with role="none", not just ones with the generic role.

If I understand correct, the motivation for generic is to get around the fact that AT today can't derive properties from presentation, because they aren't in the accessibility tree. That seems reasonable to me, but then that just turns this on its head and the question becomes; Can we deprecate all the props from presentation and none, since there's clearly no expectation from this group that UA/AT ever actually use those.

[cookiecrook]

Can we deprecate all the props from presentation and none, since there's clearly no expectation from this group that UA/AT ever actually use those.

A lot of ATs on Mac/iOS devices use those containers to derive layout information like position and bounds. I think the implementations could change, but I'm not sure the amount of effort required. I expect it would require updates to WebKit at a minimum, likely also to VoiceOver, and perhaps to other AT like Switch Control, Voice Control, Hover Text, etc.

[cookiecrook]

Layout info is used for display (like the scaled VO cursor), triggering events (like drag/drop or custom gestures in SC), coordination between AT (like Zoom following KB Focus or VO nav), and more. There's a big stack that relies on these.

[carmacleod]

The ARIA Working Group just discussed Concerning the "generic" role.

The full IRC log of that discussion

<carmacleod> github: https://github.com//issues/1182
<jamesn> "A generic can provide a limited number of accessible states and properties for its descendants, such as aria-live attributes. In addition, generic containers are exposed to the API so that assistive technologies can gather certain properties such as layout and bounds. This differentiates it from the presentation role. "
<carmacleod> jamesn: nit, should be "accessibility API", not just "API".
<carmacleod> mck: do we want to put the statement that we're differentiating from presentation role in front of the new sentence?
<carmacleod> carmacleod: yes, that works
<carmacleod> mck: I will add that to the pr