Failure F2 Example 3 should be removed

[dd8]

Example 3 fails on visual emphasis using font-weight: bold specified via CSS rather than using a semantic element
https://www.w3.org/WAI/WCAG22/Techniques/failures/F2#example-3-using-css-to-visually-emphasize-a-phrase-or-word-without-conveying-that-emphasis-semantically

H49 suggests using the strong element for this:
https://www.w3.org/WAI/WCAG22/Techniques/html/H49

@stevefaulkner did some testing on this in January 2023 https://www.tpgi.com/screen-readers-support-for-text-level-html-semantics/

tl;dr

• Modern screen readers do not voice strong or em differently to other text
• NVDA 2015.4 did voice these differently but removed this feature in NVDA 2016 because it was extremely unpopular with users (Semantic support (not just style support) for del and ins on web pages nvaccess/nvda#4920 (comment))
• font-weight: bold (and other font styles) are optionally announced by screen readers

To quote Steve's post:

the strong and em are not accessibility supported and therefore should not be a factor in accessing conformance with SC 1.3.1:Info and Relationships. Visually identifying emphasised and important text via CSS styles is an accessibility supported method and will be conveyed to SR users when they have the required settings enabled.

On that basis Example 3 shouldn't be a failure.

[JAWS-test]

Just because some screen readers don't output things correctly doesn't mean that the failure F2 Example 3 needs to be removed, because

• firstly, there is more assistive technology than the screen readers tested and
• secondly, the screen readers may work correctly someday (see strong and emphasis are not output by JAWS 2023 FreedomScientific/standards-support#750)

There is a semantic difference between strong and CSS bold.

[patrickhlauke]

font-weight: bold (and other font styles) are optionally announced by screen readers

The fact that some SRs (as a form of error-correction/last ditch effort to help to their users) can be made to announce purely stylistic changes doesn't absolve authors from not relying purely on visual style changes to convey meaning. (the same way that the last ditch behaviour of some SRs to announce text before/after a form input without an accessible name - from memory, JAWS used to do that - as a potential label for a field doesn't absolve authors from 4.1.2 requirements)

It may however be an idea to add a note to https://www.w3.org/WAI/WCAG22/Techniques/html/H49 to clarify that current SRs don't necessarily announce text-level semantics

[dd8]

The problem I've got with this particular example is that it's a line of dialogue, so modifying the speech output can make it less meaningful, rather than more more meaningful:

"I said, <span class="yell">no</span>, not before dinner!",

Speech output for this is currently "I said, no, not before dinner!" in a screen reader.

Let's change this to use the <strong> element and walk through different possible AT implementation of role=strong

"I said, <strong>no</strong>, not before dinner!",

Depending on how AT maps role=strong to voice output, this can make it closer to the visual representation (e.g. saying 'no' louder) or worse (e.g. switching male to female voice sounds like two different people speaking the dialogue)

Mapping	Voice output
Read role	"I said, strong no, not before dinner!"
Change voice	<male>I said</male><female>no</female><male>not before dinner!</male>
Change volume	"I said<louder>NO</louder> not before dinner!"
Slower speed	"I said<slower>noooo</slower> not before dinner!"
Faster speed	"I said<helium>ni</helium> not before dinner!"

There's also the matter of degree: if everything is important, nothing is important. So this makes sense:

<strong>Caution: Do not exceed the stated dose.</strong>

but lots of strong/em voice switches would be really annoying. For example, in formatted code examples like this:

<strong>&lt;</strong>p class='test'<strong>&gt;</strong>Paragraph text<strong>&lt;</strong>/p<strong>&gt;</strong>

[patrickhlauke]

modifying the speech output can make it less meaningful, rather than more more meaningful

lots of strong/em voice switches would be really annoying

while interesting, this seems to be orthogonal to the problem. the issue the example tries to show is: authors should not rely purely on CSS/visual changes to convey something. the argument over whether or not it's then annoying or not is, as with anything, subjective.

[bruce-usab]

Discussed on backlog call 10/27/2023, @scottaohara shared how might be addressed in ARIA call.

[dd8]

I think this has been resolved by PR #4128

[giacomo-petri]

Solved with #4128

Closing as completed