Feature Request: High Contrast Highlighting

[duracell80]

Add "high contrast" as a marker (white text on black bg)

https://www.boia.org/blog/the-most-common-web-accessibility-issues-to-avoid

Colors should not be used to convey meaning. If developers wish to use colors to communicate something meaningful, alternative options should also be provided to communicate the meaning. This applies to features such as highlighted text.

[Reinmar]

The highlight feature uses <mark> elements which carry more information than just the color. Assistive technologies should handle them in a distinctive manner (cc @Comandeer).

The only problem I see here is that each mark type (each color) may have different meaning for a person who applies them. E.g. someone may use the yellow to mark invalid pieces of text (text to correct). For a color blind person, understanding whether the reviewer used yellow or blue may be impossible.

So, the problem is whether we can add more information to these marks? I've been thinking about some ARIA attributes, but their values would need to be provided by a developer who's integrating CKEditor 5 with some system. That person would need to decide which mark will be used for which purpose. E.g. red is for issues, green for additions, etc. I think we could do that, but I'm not sure whether this wouldn't become a different feature then. And, of course, we'd also need to think how to present that information in the UI. I guess the semantic titles could be displayed in the highlight button tooltips:

And perhaps also after hovering a mark in the content.

---

Add "high contrast" as a marker (white text on black bg)

With what would adding one high contrast marker help? Still, the rest of them would be a problem. If anything, we need to think how to make all of them distinguishable. Work on their contrast or additional attributes.

---

cc @fredck @oleq @dkonopka

[jodator]

That sound interesting. Actually Right now you can name those highlighters as you wish. So if we could go with some ARIA attributes there it might be helpful IMO.

Also maybe we should mention about it in the docs more explicitly? Like rewriting one of examples to have descriptive titles like "Text to correct" rather then focusing on visual configuration (colors).

The other thing is that we could rename those markers to something descriptive (as in docs) but right now they are universal and fits better.

[oleq]

So, the problem is whether we can add more information to these marks? I've been thinking about some ARIA attributes, but their values would need to be provided by a developer who's integrating CKEditor 5 with some system.

As @jodator mentioned, pens and markers already have titles. So using these titles for ARIA attributes probably makes sense.

The other thing is that we could rename those markers to something descriptive (as in docs) but right now they are universal and fits better.

I second this, regardless of the decision we make in this issue. Or demos should present meaningful integrations. And since we're encouraging semantic content, moving from "Red marker" to "Text to correct" makes sense IMO.

[fredck]

@duracell80, although I understand the root issue of your request, it sounds conflicting. What you're proposing is to introduce yet another highlight pair of colors while, in reality, the colors in use are not really important because, as colors, they don't give any meaning.

In fact, @Reinmar pointed out this precisely, that the editor produces the <mark> element to satisfy exactly that, to give the semantic information, at some level at least.

In the other hand, it sounds like the real problem you want to point out is another level of accessibility, which is not about semantics but instead about styles. The fact that the colors proposed by default may not (or may) have enough contrast, according to accessibility standards. That's a different story and it must be checked before we decide if we want to do anything about it.

Finally, it is possible to configure and create a custom set of markers by configuration, which allows one that is not satisfied with the default colors to customize it to their requirements.

[fredck]

@Reinmar, your idea, together with @oleq's opinion, makes a lot of sense. It doesn't seem to be directly related to what the reporter wanted to solve though, so I think it deserves a separate issue.

[fredck]

Btw, as a general tip, let's keep in mind that accessibility is not just about Assistive Technology and blind people.