ARIA WG decision on b/strong and i/em semantics conflicts with intention of HTML spec

[cookiecrook]

@scottaohara Can you explain the reasoning for collapsing the semantics of b/strong and i/em as they are defined in HTML as representing different things

Originally posted by @stevefaulkner in #475 (comment)

Re-opening this cold case, because I still think b/i should map to generic. –jc

[cookiecrook]

And in Scott’s defense, I don’t recall him arguing for this mapping. (Don’t blame the editor.)

[scottaohara]

i think we may have crossed some wires here, because in the original issue @cookiecrook mentioned that s and b were mapped to deletion and strong, respectively and noted that i was generic.

There was a conversation we had in the ARIA wg about how bold content and italicized content would be visually indistinguishable if someone were to use b, strong or font-weight:bold (and similar for the italicized content), and that any such content should likely all be treated similarly.

But, looking back through HTML AAM, I had thought that I had made the change for b to map to strong per that conversation, but it seems I never actually did that, and maybe James's original mention of b was supposed to be referring the strong element instead? So it seems i was premature with my comment that i made a mistake, as now it seems a mistake has been made because now there is a discrepancy with how b and i are spec'd. :: giant everlasting sigh ::

In which case, let's just get this all clarified and make the necessary updates, whether that be to give these elements the roles that were created for them, or to treat them as generics and then figure out what to do about the ARIA emphasis and strong roles that would seem sorta without a practical purpose with a course change like this.

Re: the s element mapping though, here's the PR for that - #442

[joanmarie]

In #475 , @cookiecrook stated:

I (and maybe Scott) argued for b and i to map to generic, but the ARIA WG went a different way. @michael-n-cooper
@joanmarie or @jnurthen may be able to find the specific decision.

They’d be interested to know that ARIA WG decision conflicts with the primary standard.

My memory is weak these days. 😇

My understanding/recollection back when I was still actively involved in the WG is:

• b, u, and i, s would be mapped to the generic role
• strong, em, and del would be mapped to strong, emphasis, and deletion respectively

The rationale included having mappings which made it possible for assistive technologies to easily identify semantically relevant styling from purely visual styling. Then users could choose to hear:

• No formatting information automatically spoken
• Only semantically relevant information automatically spoken (potentially the default setting)
• All formatting information automatically spoken

Note that the generic role can be pruned from the accessibility tree (last time I checked). And at least some user agents did/do prune b, u, i, s from the accessibility tree. Mapping to generic means user agents don't have to change that behavior. Mapping to something other than generic means those elements need to be included in the accessibility tree (right?). That requires implementation work.

If the visual styling elements get mapped to not-generic, and are included in the accessibility tree as a result, assistive technologies will need to check the element's tag (or role in the case of ARIA) in order to determine if the thing is semantically relevant or not. That's not the end of the world....

On the flip side, if the semantically-relevant-formatting elements get mapped to generic and get pruned from the accessibility tree, assistive technologies will not be able to distinguish the semantically-relevant information from the purely visual styling. They'll just be able to get the font, format, etc. from the unignored parent. They won't know why it has that formatting.

So I think the most important bit is to ensure that semantically-relevant formatting elements/roles don't get pruned from the accessibility tree.

Hope this makes sense and is of some use.

[cookiecrook]

But, looking back through HTML AAM, I had thought that I had made the change for b to map to strong per that conversation, but it seems I never actually did that, and maybe James's original mention of b was supposed to be referring the strong element instead?

Wait, what? I feel like I did when someone told me Berenstein was spelled Berenstain

[cookiecrook]

So I checked in the wrong expectations in WPT, and then made a mess of things.

<b data-testname="el-b" data-expectedrole="strong" class="ex">x</b>

[scottaohara]

eh, it's kinda forcing the issue though. so, it'll all work out :)

[cookiecrook]

Seems like there wasn't an issue to force, other than in my head.

Unless someone thinks more deliberation is needed, I can close this issue, and roll back those portions of the WPT HTML-AAM tests. I think you'll need to roll back the <i> patch (heh, eye patch) in HTML-AAM too.

[cookiecrook]

@joanmarie wrote:

b, u, and i, s would be mapped to the generic role

Perhaps <s> was the sticking point since strikethrough on generic was more meaningful than the other styles. @jnurthen do you remember?

[jnurthen]

I don't recall the specific conversations. My personal opinion is that <s> is very unlikely to have a non-semantic usage but I don't think that was a group decision.

[cookiecrook]

HTML-AAM does list <s> as deletion so leaving that one. I think I agree with @jnurthen. Calling strikethrough generic hides a meaningful distinction.