Maybe remove Example 3 of F2

[besenwagen]

While trying to fill in all the blanks I have in the understanding docs, I was a bit surprised to find example 3 of F2 "Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text" (both in WCAG 2.1 and 2.2). This is exactly the kind of accessibility dogoodery I wasted a lot of time on, 20 years ago. 😑

A few objections that come to mind:

1. I couldn't name AT that supports this type of text-level semantics, either at all, or with default configuration.
2. NVDA can be configured to announce text attributes; that works fine for the failure example as well.
3. Unlike the previous two examples, no remediation guidance is offered. Is the <b>-element sufficient?
4. 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?
5. Rhetorical complaint: Doesn't the failure example contain an inline quote that isn't conveyed to AT, either? 🤪

This just seems to reinforce what would I would call typical beginner mistakes. But I am also surprised. Am I missing something?

[JAWS-test]

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.

[besenwagen]

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.

[mbgower]

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.

[besenwagen]

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.

[stevefaulkner]

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