Remove syntax highlighting because can be perceived as colourblind friendly?

[hidde]

(this issue was created by request of brewerj)

Background: in the AGWG mailing list it was noted many of our HTML examples use green and red as to distinguish different parts of the syntax. This is not because of the syntax highlighting theme we use (a11y-syntax-highlighting), it is because code examples in Techniques don't have language indication, so we use a tool that guesses the language, and it guesses some of our examples are XML, when they are HTML.

[brewerj]

Let's defer adding color syntax highlighting till phase 2, to allow time to sort out more carefully colored syntax highlighting, so as not to go against WAI best practices of color-blindness-friendly color choices.

[hidde]

I suggest we keep it:

• current Techniques offer syntax with no highlighting at all, which is not friendly to colour blind users or non colour blind users, adding the highlighting as we have done is a net improvement, at least for a majority of users
• removing it is extra work
• making it more colour blind friendly requires syntax indication which we do in some docs but not in Techniques; I believe we don't want to either, for maintainability reasons, so if we don't do it as we do now, we're unlikely to do it ever in these documents

I think these outweigh the point that it may not be a good look to use green and red together in some occassions, or the point that we would want to be a colourblindfriendly website.

[brewerj]

Additional clarification: getting better customized colors would require coding in a way that AGWG may not want to support. So, it's unclear if it will be possible, in this context, to do the color-blindness-friendly syntax highlighting.

My understanding then is that it's even more important to have additional input on this before deploying, so I still recommend for Phase 2.

[brewerj]

...Hidde is noting that the previews do actually pass color-blindness friendly tests -- that may change things. He will add screen shots.

[hidde]

I have taken screenshots of emulators for a number of different types of colour blindness and it seems, if the emulator is correct, our HTML colors are distinguishable for all but one (full colour blindness or Achromatopsia; but that's not fixable with different colours):

[brewerj]

Thanks Hidde for this additional info. Interesting.

We've had a few instances before where WAI has deployed something that appears not to meet our own guidance, but actually does. When we've built in clear explanations or disclaimers right in proximity to an apparent violation of our own guidance, that's gone OK.

When we haven't explained the apparent violation of our own guidance, it has become a problem, on two levels: the people who think we're violating our own guidance publicly question why they should follow our other guidance (which is hard to respond to well once that theme starts, even if we were "right"). Also, we're missing an opportunity to model certain guidance clearly.

If we go the disclaimer route, in this case, since the apparently-not-color-blind-friendly syntax highlighting is distributed throughout the entire resource, we would need to figure out a lightweight, distributed disclaimer, then review that to make the disclaimer itself isn't confusing. That's hard to do on the fly -- it needs someone to develop and propose the disclaimer -- and it needs review. That would put this into phase 2 (e.g., needs feedback from EOWG).

If we go the route of using more obviously color-blindness-friendly syntax highlights, we'd need Michael's input on how that technical approach would work in the WCAG documents, and he'd need time to do it, which I'm guessing would be hard during TPAC.

So my recommendation from earlier this week remains:

Let's defer adding color syntax highlighting till phase 2.

I do like the idea though, and am hoping we can figure out a way to do this with color-blindness-friendly syntax highlights in phase 2.

[hidde]

’Defer‘ sounds like doing some work later, but just to be clear, ’defer‘ in this case means someone from our team will have to go in and do the work of removing syntax highlights. ’Defer to phase 2‘ means ’adding an extra task to do for phase 1‘.

I'd like us to also consider backlash that could come from lack of syntax highlighting. Without syntax higlights our code examples are harder to use, for people with and without disabilities and especially for people with cognitive impairments, for whom highlights could make code especially more digestable. It even net benefits people with most forms of colour blindness, as shown in the screenshot.

Removing this costs time, it adds an accessibility barrier and a usability barier, with no (?) user benefit.

Btw, it was described by JF as ’not a hill to die on‘, so arguably a decision to not remove highlights would be in the spirit of AGWG comments in this case (and as I said, very glad to have received the comment so we could investigate).

[brewerj]

Clarifying next steps:

• see if possible to use more color-blindness-friendly color choices before deploying syntax highlighting,
• or otherwise use colors from current prototype and see if possible to add disclaimers.
• attempted reclarification of issues label to: Remove syntax highlighting until can refine to more color-blindness-friendly OR until can add disclaimers that this may meet best practices

[hidde]

Strongly recommend not to add a disclaimer, this colour scheme is colour-blindness-friendly, even the original commenter said they would not die on a hill for this, and if we get questions we are in a strong position to answer them. Adding a disclaimer would deprioritise the end user, because it adds the cognitive burden on them to understand what's going on.

Strongly recommend not to look for other colours, but instead find out how we can mark this code as HTML (currently gets recognised as XML, hence strange colours) (see example of when it would get highlighted as HTML in the README of the colour theme we're using).

[shawna-slh]

site-wide issue w3c/wai-website#267