search

wagtail / wagtail

A Django content management system focused on flexibility and user experience
https://wagtail.org
BSD 3-Clause "New" or "Revised" License
18.29k stars 3.86k forks source link

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

Closed allcaps closed 4 years ago

allcaps commented 6 years ago

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 commented 6 years ago

This is defined over here for Hallo: https://github.com/wagtail/wagtail/blob/b4a2e13cb02c8c11368b3639b887066d8a3d306f/wagtail/admin/wagtail_hooks.py#L285-L299

and there for Draftail:

https://github.com/wagtail/wagtail/blob/b4a2e13cb02c8c11368b3639b887066d8a3d306f/wagtail/admin/wagtail_hooks.py#L463-L494

I believe the reason why it's b and i is simply that this is what Hallo produces, so existing rich text content contains those tags. As you can see above, both Hallo and Draftail also handle strong and em as if they were bold and italic. I imagine the reason might be that Hallo doesn't automatically convert pasted content to use b and i, so there would be some mixing of the two. For Draftail, again it's just because of what got stored by Hallo.

On a new project, there is no reason that I can think of not to use strong and em for storage.

For a workaround – unless you want to offer both b and strong at the same time for different semantics, I believe it would be better to override the definition of the bold and italic features instead of introducing new ones called strong and em – this way there's less of a chance that you'll have an editor with all four activated, or that there'll be conflicts in how strong and em tags are handled.

gasman commented 6 years ago

I may be overthinking this, but there are potential uses for bold / italics (as listed at https://html.spec.whatwg.org/#the-i-element) where strong / em are not semantically correct - e.g. definitions of technical terms. In fact, I seem to recall a version of the HTML spec explicitly saying that authoring tools should favour b / i unless they know for sure that the author intends to use them for emphasis. (I couldn't find this again last time I looked, though...)

allcaps commented 6 years ago

I think I opened a can of worms.

Correct em:

 What she <em>really</em> meant to say was, 
&quot;This is not ok, it is <strong>excellent</strong>&quot;!...

Correct i. On taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought.

<p>The <i>Felis silvestris catus</i> is cute.</p>
<p>The term <i>prose content</i> is defined above.</p>
<p>There is a certain <i lang="fr">je ne sais quoi</i> in the air.</p>

For now I think both em and i are correct if used right. What this means for Wagtail, I don't know. Maybe current defaults are fine.

thibaudcolas commented 6 years ago

I think either can be correct, as in practice "Bold" and "Italic" as rich text formats overlap with the semantics of both options. I don't think the semantics defined in the spec matter that much here, in my opinion it's more of a question of what authors expect when they use those formats in their content.

Here's what other authoring tools do:

So – overall there is no consensus, but for rich text editors in particular strong is by far more common.

thibaudcolas commented 4 years ago

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.

thibaudcolas commented 4 years ago

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:

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.