Related: https://www.w3.org/WAI/WCAG22/Techniques/html/H49 (using of em and strong)

Unfortunately, I don't really understand your objections to F2, example 3. The point here is that highlighting should be marked with strong or em. As a warning, a note could be added that screen readers currently make no distinction between <strong>, <b>, and CSS bold.

Sure it's good practice for authors to use the available elements with specified semantics, and does no harm. My objection is only about featuring it as a failure technique for auditors, as long as there is no practical benefit for users. All the same it might still be learned, used, reviewed, rejected, discussed, and unlearned.

Reversely, I also wouldn't fail using emphasis for typographic conventions like titles, species or ships, even though that's an error that would only affect AT users, if it were exposed. Naturally, the control I just used in the GitHub editor fails SC 2.4.6, because somebody made the result more accessible.

Thank you for raising this issue.

1.3.1 ensures there is a programmatic or text 'equivalent' to anything conveyed through presentation.

It sounds like your primary concern is that current assistive technology (AT) implementations either don't support some programmatic indicators (your point 1) or that AT have the ability to surface some presentation attributes to users (your point 2), even if they are not present in the accessibility tree. In other words, there is a problem that the state of "accessibility supported" does not align with the focus of the SC wording.

WCAG has conformance requirements for accessibility supported; however, any combination of AT, user agent, OS, and technology can lead to performance differences (including minor differences in versioning). The standard provides some wording to this effect.

The Accessibility Guidelines Working Group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".)

In short, the authoring guidelines set baseline requirements for authors. Meeting the requirements should not be considered the same as making an experience accessible for any specific user.

That said, this example does seem fairly weak and arbitrary when considered in 2024.

Well actually 🤭 I would fail usage of <strong> or <em> for a task that for any reason depends on conveying emphasis to AT for not being accessibility supported. Am I wrong?

You should not fail that against 1.3.1. Just because ATs elect not to provide a default variation in speech output for strong or emphasis doesn't mean the author has failed to provide the programmatic indication for that. You are at liberty to decide that use of either of these elements is not accessibility supported and insist that your product use another means to convey that information.

Rhetorical complaint: Doesn't the failure example contain an inline quote that isn't conveyed to AT, either?

The existence of quotation marks in the example forms a text indicator that there is a quote. It is not necessary to use a <q> to do this in order to meet 1.3.1, although most would consider that a better implementation.

Or perhaps you are saying that it should really be written with a set of nested quotes? For example:

"I said, 'No, not before dinner!'" was the exasperated...

I would agree that linguistically the nested quotes are more correct. I can create a PR to address, if desired, but I think that this editorial issue is orthogonal to use of the span which is the intended focus of this example.

Unlike the previous two examples, no remediation guidance is offered. Is the <b>-element sufficient?

The "yell" style class puts the text in bold and all caps. As you note, whether one uses CSS to transform it or enters the text in caps as "NO", it amounts to the same thing for most AT users: a Say All command will not produce any voice variation, but reading by character will allow one to hear the capital letters in both circumstances. And you are correct that whether or not one styles this bold or sets this as strong, the outcome for most screen reader users is the same.

I will generate a PR that removes this example. I anticipate that others may advocate for an example where a clear benefit to a user is identified, rather than simply removing it.

Thanks for your long reaction. I'll try to keep my response focussed.

Well actually 🤭 I would fail usage of \<strong\> or \<em\> for a task that for any reason depends on conveying emphasis to AT for not being accessibility supported. Am I wrong?

You should not fail that against 1.3.1. Just because ATs elect not to provide a default variation in speech output for strong or emphasis doesn't mean the author has failed to provide the programmatic indication for that. You are at liberty to decide that use of either of these elements is not accessibility supported and insist that your product use another means to convey that information.

By "depend", I really meant a task that cannot be completed – I will go with the ubiquitous quiz/test example – without perceiving which words are emphasized. Which other criterion should that be failed against?

Rhetorical complaint: Doesn't the failure example contain an inline quote that isn't conveyed to AT, either?

The existence of quotation marks in the example forms a text indicator that there is a quote. It is not necessary to use a <q> to do this in order to meet 1.3.1, although most would consider that a better implementation.

That is actually what I thought of. Interesting. Coming from a development background, I literally do not know anybody who would consider that a viable option at all, because of historically terrible browser support. Not in terms of accessibilibty, just generally speaking, for everybody, especially considering i18n.

I will generate a PR that removes this example. I anticipate that others may advocate for an example where a clear benefit to a user is identified, rather than simply removing it.

Both sound good. Thanks.

maybe helpful data from 2023 Screen Readers support for text level HTML semantics

maybe helpful data from 2023 Screen Readers support for text level HTML semantics

Thanks for that list. Nothing jumped out at me as a better example to use as a failure example in F2; did you have something in mind?

I did wonder, reviewing this failure if we should alter the focus of the failure from simply using presentation to a third check to see if ATs identified the presentation. Currently the second check reads:

2.For styled text that conveys information:

1. Check if there is any styled text that conveys structural information.
2. Check that in addition to styling, the proper semantic structure is used with the text to convey the information.

If check 2.1 is true, then 2.2 is true.

How about if it were:

For styled text that conveys information:

1. Check if there is any styled text that conveys structural information.
2. Check that in addition to styling, the proper semantic structure is used with the text to convey the information.
3. Check that supported assistive technologies surface the text styling.

If check 2.1 is true, then 2.2 or 2.3 is true.

BTW, is it just me, or is this check backwards!?
If you look at F3 Test, the outcome is such that it confirms a failure. In F2, the outcome is such that it has NOT failed.

I believe it should actually read as follows (assuming you support my approach of adding a third check).

2.For styled text that conveys information:

1. Check if styled text conveys structural information.
2. Check that in addition to styling, the proper semantic structure is used with the text to convey the information.
3. Check that supported assistive technologies surface the text styling.

If check 2.1 is true, then if both 2.2 and 2.3 are false, this failure condition applies and the content fails this success criterion. If either 2.2 or 2.3 is true, the failure condition does not apply.

While I'm at it, I also wonder about the specification of structural information in the preamble to the test. The title of the failure makes no mention of this, and while it is an interesting concept to only check for structural information failing to be surface through text presentation, that is not the stated objective, at least from the heading...

@besenwagen I have created a PR that attempts to address each of your points. Please review.
#4128

UPDATE: Based on discussion in the TF, we have made this PR more contained, and opened a new issue to tackle some of the points you made about CSS support by ATs.

@mbgower Thanks, looks good to me. I also agree with most points raised in the PR discussion, and that it is better to split this up. As a suggestion for a failure example beyond headings, table data cells that are just differently styled to look like header cells seem like a problem with actual consequences for users. AT support is pretty solid for simple cases there (no spanning of cols and rows etc).

Personally I neither like nor know what to think about font property support in AT, I mainly brought it up as a counter example. But on second thought, more clarity about it would be good.