Richtext features bold and italic render as b and i should render as strong and em

Bold tag, <b>, and the italic tag, <i>, are listed as a WCAG Level A error because most screen readers will NOT announce these changes to the screen reader user.

Ref: https://support.siteimprove.com/hc/en-gb/articles/115002726312-Accessibility-Bold-vs-Strong-and-Italic-vs-Emphasis Ref: https://www.w3.org/TR/WCAG20-TECHS/H49.html

Here is a workaround for anyone bumping into the same issue: https://stackoverflow.com/questions/49902931/wagtail-how-to-override-html-tag-output-from-database-use-strong-or-em-ins#answer-51136618

I think Wagtail should drop b and i and use strong and em as default.

[thibaudcolas]

I will close this now that this is documented via #6090 / #6272: https://docs.wagtail.io/en/latest/advanced_topics/accessibility_considerations.html

Copying the most relevant info here for future reference:

• For screen reader users it likely makes no difference whether content uses b or strong (tested with the default configuration of NVDA + Firefox, VoiceOver macOS Safari, VoiceOver iOS Safari). See https://github.com/wagtail/wagtail/issues/4665#issuecomment-636050162.
• If anyone wants to use more semantic “strong” and “b” formats for their sites as opposed to Wagtail’s “Bold”, they can customize this with rich text format converters as documented, similar to the workaround from @allcaps https://github.com/wagtail/wagtail/issues/4665#issue-337531629.
• Some day we’ll hopefully have better options to do this without altering how content is stored (#4223)

We can re-open if someone wants to make the case Wagtail’s default should be changed, but please provide evidence as to why this is a worthwhile change both semantically and pragmatically.

[thibaudcolas]

Revisiting this again – I think #4223 will make it possible for people to fix this on their own websites without any change to Wagtail itself, however that still leaves us with the question of what would be the most appropriate default for Wagtail. I did more research.

HTML Specification

For the i element,

Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term.

For the b element,

[…] should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.

---

WCAG

@allcaps already shared the relevant link at the top, https://www.w3.org/TR/WCAG20-TECHS/H49.html. The TL;DR; is “use semantic markup, strong and em”.

Accessibility best practices

Here is the most authoritative information I could find: https://accessibility.psu.edu/boldfacehtml/. It’s really good so I’ll copy the relevant info here. Emphasis mine.

Many accessibility experts recommend using STRONG instead of B for bold face text, and EM instead of I for italic text. The reasons for this recommendation are:

STRONG and EM are semantic tags, meaning that they indicate that the author wishes to provide emphasis, which is rendered as bold/italic on a visual browser or in different speaking styles on a screen reader. In theory, screen readers could pronounce STRONG and EM in a different voice or style. However this rarely happens in practice (the same is true for B and I tags).

Why it’s not critical

On the other hand, real-world considerations make this distinction not as critical as other issues. Mainstream screen readers currently treat B/I tags identically to STRONG/EM tags. That is, they are ignored unless a user specifies that they be indicated. Some users report that announcing changes can be distracting. Many authors specify bold or italics purely for visual reasons in any case (in which case B/I might be preferred) or are not sure why they are adding the formatting, thus removing the utility of STRONG/EM. NOTE: No accessibility specifications require eliminating the use of the B and I tags, just that they be appropriately used.

---

I did my own testing as well and confirmed that screen readers do not announce strong/em/i/b any differently than normal runs of text. Tested with macOS VoiceOver, iOS VoiceOver, ChromeVox, and NVDA. I’d have ideally tested with JAWS as well but didn’t have it available.

Here is my test page if anyone wants to do their own testing: https://condescending-nobel-4e4e3c.netlify.app/

---

Based on all of this – I would recommend to keep Wagtail’s implementation as-is, and simply document the current state and how to configure this per-site in Wagtail’s rich text documentation once #4223 is merged. While in theory it feels to me like strong and em would be more appropriate, that’s only true if editors do use it in a semantic way (I’m happy to make that assumption) – and regardless, changing this doesn’t actually make a difference to screen reader users. So, there are more important things to worry about.