This is more directly related to w3c/html-aam#373 and w3c/aria#996

need to solve #996 first

as mentioned on the ARIA WG call today, in lieu of completing the work on w3c/aria#996, a stop gap could be to add a note to core aam that indicates that the generic role mappings would be based on either div or span mappings per the element/css rendering of the element.

This morning, @scottaohara and I discussed creating a new section in Core-AAM that outlines the use and complications of mapping generic. HTML-AAM and other AAM docs (SVG, MathML) could link across to this section with any relevant caveats.

Mapping to generic assumes the text style properties come with the mapping. For example, <b> and <span style="font-weight: bold;"> would be mapped as generic with identical font styles, but distinct from <i> and <span style="font-style: italic;">... Positioning and various CSS display would also be exposed even on generic elements. AT can already convey a lot of these text-style, display-style, and position/bounds to the user, regardless of the platform role.

This is how the macOS AX API exposes style-based elements separately, and as I understand it, similar behavior is common on other platforms and with other AT. (Please comment if you know of major patterns where my understanding is wholly wrong for a particular API, and not just a caveat like the ones mentioned below.)

Another example of this is that <span> and <div> can be remapped interchangeably as long as the author redefines the default display styles accordingly. In this way, the generic role is not as much about the original tag name as it is about the current rendering of the element.

Of course there will be a lot of exceptions or caveats that will need mentioning in the mapping tables... and some as examples in the new section. For example:

• bdi/bdo could be ~"generic*, with respective mapping for html:dir"
• <span> with a click handler (an author error) could still be generic, as long as the "click-ability" is also exposed as defined for the platform. [Update: click-ability should probably be mentioned in the main section, rather than as a caveat, but leaving here because it illustrates how generic as a role can still work with all these leftover elements and examples that have different characteristics.]

I'll try to draft a first pass of that new Core-AAM section, then request comments from various implementors before finishing it and fleshing out the rest.

Okay, this is pretty rough, but I want to get feedback on the approach/direction before spending anymore time getting it into a usable PR. Draft PR coming imminently.