Update F2.html

[mbgower]

• rephrased the introduction to include mention of assistive technology
• removed example 3
• updated outcome logic of checks 1 and 2
• added a third condition to check 2

Resolves #4109

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	c6bb6d0
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2/deploys/6737775fb31ac6000830aff0
😎 Deploy Preview	https://deploy-preview-4128--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[bruce-usab]

Discussed on backlog call 11-1. Concern on call with only having heading examples, since CSS can semantically be used to convey emphasis.

[mbgower]

Created a new issue to track unincorporated changes #4132

[mbgower]

Once the other non-structural changes have been added in the other Issue, the wording of the first check can be adjusted to something like the a prior commit

[detlevhfischer]

Test: The sentence

If condition 2 is true, the failure condition does not apply

seems superfluous and therefore a bit odd (it seems implied in the first part).

But I have more general concerns about this Failure Technique. People will use it to fail content that use things like b and i instead of strong and em so they will let content fail for stuff that is usually not semantically available to screen reader users (unless you explicitly check for styling / emphasis). And there are cases where the author might rightfully claim that b or i were used for stylistic reasons that do not map onto the HTML semantics. Should there be a not limiting of the Failure to cases like headings where the practical issue is clear (or a warning that often inline semantic markup is not honored by AT)?

[mbgower]

Test: The sentence

If condition 2 is true, the failure condition does not apply

seems superfluous and therefore a bit odd (it seems implied in the first part).

The existing language does not actually say what results produce a failure. I agree that the second sentence (which declares what does not fail) is restating the other side of a logic loop. If people feel its removal is unlikely to result in erroneous interpretation, I'm fine to remove. But I don't see it causes a problem being there.

But I have more general concerns about this Failure Technique. People will use it to fail content that use things like b and i instead of strong and em so they will let content fail for stuff that is usually not semantically available to screen reader users (unless you explicitly check for styling / emphasis). And there are cases where the author might rightfully claim that b or i were used for stylistic reasons that do not map onto the HTML semantics. Should there be a not limiting of the Failure to cases like headings where the practical issue is clear (or a warning that often inline semantic markup is not honored by AT)?

As you may see from the discussion, there is general concern with the scope of this failure technique. We are removing with this change example 3 as a first attempt to reduce the problems. There is also another issue open to further this work.
That said, can you provide an example of a situation where bold and italic are used that are not meant to convey meaning that could not be conveyed semantically?

[detlevhfischer]

That said, can you provide an example of a situation where bold and italic are used that are not meant to convey meaning that could not be conveyed semantically?

I think it could be cases where you don't want to put emphasis on a bit of text but differentiate: technical terms, taxanomic terms, etc. Or a title that is not put into quotation marks:

In Edgar Allan Poe's short story A Descent into the Maelström a man recounts how he survived a shipwreck and a whirlpool.

See also https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i

I admit there is a blurry line between i and em...

[bruce-usab]

1. Discussed on TF call 11/22. MG will work out with Detlev.