search

kingsdigitallab / django-kdl-wagtail

A collection of Wagtail components used across several KDL projects
MIT License
4 stars 0 forks source link

Draftail outputs <b> and <i> #16

Open ginestra opened 5 years ago

ginestra commented 5 years ago

Description

At the moment Draftail outpus <b> and <i> as bold and italics, failing single A WCAG (https://www.w3.org/TR/WCAG21/#info-and-relationships). Anything we can do to output <strong> and <em> instead?

See: https://github.com/wagtail/wagtail/issues/4665

MDN web docs seem to think they are both valid for slightly different uses: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/strong

From my point of view, <strong> and <em> should be the default as they are the semantic tags, whilst <b> and <i> are more on the decorative end, as far as I understand.

geoffroy-noel-ddh commented 4 years ago

Have you tried reporting that to Wagtail or Draftail directly?

ginestra commented 4 years ago

Only Wagtail via GitHub as mentioned above. https://github.com/wagtail/wagtail/issues/4665

geoffroy-noel-ddh commented 4 years ago

I couldn't find existing tickets about that issue on Draftail repo. But the author Thibaud Colas writes articles about accessibility so I'm assuming he' should be receptive to the suggestion.

geoffroy-noel-ddh commented 4 years ago

I've known for a long time that em and strong are better practices because their meaning are more accurateand name detached from presentation (previous places I've worked we would never use i or b) but actually while reading current WHATWG specification again now and looking at other wysiwyg editors the situation looks like a mess!

TinyMCE (one of the most popular editor as you know) by default has b (tooltip = "bold") & i ("italic") icons on the toolbar. But they map to strong and em elements! This popular mapping is very confusing as b and i are still valid html5 elements but with their own distinct semantics (despite not being semantic element originally and still being abused now). You can try here: https://www.tiny.cloud/ . This Github markdown editor does the same by the way (it has a B icon for the strong element and calls it "bold").

CKEditor (another popular editor, I think we used it on GPP), is also very confusing, it maps the 'B' button (tooltip = "bold") to strong (and "I" ("italics") to i).

Google Doc doesn't even produce semantic html for b & i buttons (even when you export to html).

It would be hard battle to win with draftail and wagtail dev teams given the poor default settings of mainstream editors and habits of users. So I think you're absolutely right and the best approach would be for us to configure draftail in kdl_wagtail so it has strong and em buttons (and definitely not label them b or i please!).

As far as I understand, to be compliant with the html 5 semantic we should actually offer four buttons in Draftail: em, strong, b and i. If we only offer em or strong, then partners will abuse strong for things that would be better marked up as bold (e.g. keywords, product names as described by Mozilla). But frankly it would be hard to train people to use the correct markup element without training (perhaps a sample sheet could help, but still, it's likely to be too complicated for them or even for some of us).