Remaining elements to revise mapping

[scottaohara]

Closing #229, #183 and #346 in favor of this new issue to simplify.

The following elements should map to generic, but we will either need a call out here, or in CORE AAM how AT should treat an 'inline' vs a 'block'/other display type generic (if not doing something with w3c/aria#996).

• area no href
• b
• i
• data
• samp
• kbd
• pre
• q
• s
• small
• u
• var (or maybe this is also role=code? )

the following need to be changed to 'no corresponding role' until their mappings can be finalized - covered in #376

• dd
• dt

questions on the following

• bdi / bdo (change to generic or leave as a 'no corresponding role'?)
• cite (change to generic or leave as a 'no corresponding role'?)
• abbr (change to generic or leave as a 'no corresponding role'?)
• address (change to generic or map to group?)
• figcaption still map to caption even though it won't provide the figure a name anymore? (i think it might be ok, but want others opinions)
• label, this stay as no corresponding role? We aren't moving forward with a label role, are we? Could this actually be another instance of caption? is this a generic if not?
• legend same as above?

[jnurthen]

Proposed Deep Dive for June 30

[scottaohara]

From today's deep dive:

area no href - generic
b - generic
i - generic
kbd - new role (not mapped presently) - create new issue
pre - generic
q - generic
s - map to del? - create issue.
small - generic
u - generic
var - probably code? but create new issue.

bdi/bdo - generic
cite - new issue to discuss if this needs a new role.
address - group

create a new issue to merge caption, legend, and label as they all do the same thing at a high level - identify content that names another element

while <b>, and <i> were resolved to map to generic today, there was discussion about how end users will perceive no different visual representation to those element compared to <strong> and <em> - which are not generic.
'semantically' these are different from an HTML markup / "semantics" point of view. from an end user point of view, they're interchangeable. At some point I should create an issue concerning these elements to see if the HTML editors would have any concerns with us also mapping b and i to strong and emphasis.

[scottaohara]

Other no corresponding role elements, such as iframe, audio, video, etc. likely need some sort of role for implementors, but not for authors, if not one for both. but those would also need their own issues (which may already exist in ARIA). This is specifically for accName purposes to help determine what elements can be named.

To help, HTML AAM could also indicate on a per-element basis which elements are namable vs not in the mapping tables. This goes along with other updates that need to be done to the accName section to simplify/clarify that section of the spec.