Preview of new role sections:

• block
• inline
• Document Structure Roles list

New preview of single generic role:

• generic role
• Document Structure Roles list

Preview of new aria-textseparation attribute:

• generic role
• aria-textseparation property and its values (inherit (default), line, none, paragraph, space)

I left a comment on #699, but none of it needs to be merge-blocking for this first pass.

@carmacleod any chance we can split text separation into a separate PR?

Done. Also refreshed branch.

This PR now only contains generic role.
PR #996 contains the aria-textseparation markup.

Note that I added "Name from: prohibited" to the generic Characteristics table, but need to wait until #985 is merged before uncommenting "Prohibited States and Properties: aria-label, aria-labelledby".

Discussion points:

@scottaohara @a11ydoer
Regarding possibly using the word "autonomous" instead of "generic" in this sentence:

With the exception of providing generic HTML Custom Elements, authors should not use this role in content.

I see that to create an autonomous custom element, you extend HTMLElement:
"Autonomous custom elements" = class MyElement extends HTMLElement { ...

... and to create a customized built-in element (and automatically get all of the semantic and behavioral goodness that comes with a pre-existing element), you extend that element (e.g., button):
"Customized built-in elements" = class MyButton extends HTMLButtonElement { ...

Here's the list of elements that will (probably) be mapped to generic:

• div, form (without accessible name), footer (not scoped to body element), header (not scoped to body element), section (without accessible name), span, thead, tfoot
• abbr, address, b, i, kbd, mark, pre, q, s, samp, small, u, var
• and possibly: a (no href), bdi, bdo, dfn (currently mapped to term)

So I'm thinking that maybe (?) someone might extend any one of those, in which case it would be a "customized built-in element" with no semantics (is that correct?). Anyhow, what do you think about modifying the above sentence to something like:

With the exception of providing generic (usually autonomous) HTML Custom Elements, authors should not use this role in content.

@mcking65
Regarding differentiating between role="generic and role="presentation", we already have this sentence:

A generic can provide a limited number of accessible states and properties for its descendants, such as aria-hidden and aria-live.

How about adding an extra sentence, something like:

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

Should we mention tabindex? It would be allowed on generic but not on presentation (i.e. if used on presentation, it causes the element to revert to its implicit role).

regarding an autonomous custom element, e.g. <my-whatever>, the custom element should be mapped to/considered generic, or as a role=presentation. Unless provided an explicit role, e.g. button. So by default, the role wouldn't need to be set?

If extending an existing HTML element e.g. class MySmall extends HTMLSmallElement, then it should inherit role=generic from existing small element. So shouldn't need it there either?

Unless I'm absolutely missing something here, I honestly don't know why an author would ever use role=generic when creating custom elements.

Per our meeting last week, I do see the benefit of having the role in general, to allow mappings for elements that would otherwise have no mapping, but need to expose something to the accessibility API. But as far as authors actually using it, I'd be happier with just a direct "you shouldn't need this."

re:

dfn (currently mapped to term)

per your "currently" comment, any reason as to why this would change?

Per discussion with @scottaohara, the "Note" can be simplified to:

generic role is intended for implementors of User Agents. Authors should not use this role in content.

• changed "generic is a role used for the ontology" to "generic role is intended for implementors of User Agents".
• removed mention of custom elements because custom elements that do not have a more specific role will map to generic.

Discussion points:

1. Are there any valid use cases for allowing authors to set role="generic"?
   i.e. "Authors SHOULD NOT use in content..." or "MUST NOT"?
2. What happens if an author gives a generic a tabindex or adds event handling?
   i.e. Allowed? Author error?
3. Would it be helpful to mention that "generics can be used as the target of a relation such as aria-labelledby or aria-describedby"?

dfn (currently mapped to term)

per your "currently" comment, any reason as to why this would change?

@joanmarie, do you know why dfn is listed under "Triage needed" in the Generic Role section of the Role Parity wiki page? (i.e. will dfn stay mapped to term, now that dt is associationlistitemkey?)

@carmacleod Because I hadn't updated the wiki.

Conclusion re point 1: Move out of the note and SHOULD NOT.

Conclusion re point 2: Not an author error.

Conclusion re point 3: Authoring guidance.

To be landed Tuesday afternoon assuming no more objections!

@carmacleod @jnurthen @mcking65 @joanmarie

Was the name for element ever considered as the role name for generic?
It seems to be much more descriptive or familiar than generic, but it may have been considered earlier in the process and rejected for some reason.

@jongund asked:

Was the name for element ever considered as the role name for generic?
It seems to be much more descriptive or familiar than generic, but it may have been considered earlier in the process and rejected for some reason.

Yes, for the reason that it is a word frequently used throughout the spec and defined in the glossary. We know from the experience of naming a role "application," that using words like that is riddled with problems.

@jongund @mcking65
Also, just to follow up with one last point, I think element has more of an "abstract superclass" feel, whereas the generic role (by any name) needs to be concrete.