Re: High contrast modes

Sarah, As you rightly say, one of the purposes of the WCAG is to allow
users to change colours of web content to suit their particular needs, and
they should be able to do that without losing any information. Using
Windows High Contrast mode, or one of several similar modes offered by
various browsers and browser extensions, is a legitimate and very common
way to do this. Many of these tools work a similar way, reducing all
background colours to one colour, and foreground text colours to another.
Unfortunately, Windows High Contrast Mode (WHCM) and similar modes have not
received much attention in the WCAG world. There is nothing to specifically
address them in the WCAG itself, though maybe that will change one day, and
many accessibility people are not even aware of these modes. But in fact
lots of users use them all the time, and other users switch to them at the
end of a long day when their eyes are tired. So they are important modes to
consider.

When radio buttons and checkboxes are customised, developers hide the HTML
element and replace it with their own custom graphics. Some use a
background image as you describe, but more commonly they create a tick icon
for checkboxes, and a dot icon for radio buttons. For ticks, they often use
a tiny div with a border, then rotate it through 45 degrees to make a tick!
They use various methods.

Whatever method used, the critical problem is that they then use JavaScript
to hide the ticks and dots in the unchecked components, either by the trick
of changing their colour to their chosen page background colour, or by
using the CSS opacity:0 property. Both these are where the problem lies,
because High Contrast modes are simply converting all foreground colours to
a single colour, and they do this without taking account of the default
page colour or the opacity. I once audited a component library for a survey
company where they had multiple checkboxes and radio buttons - several
rows, of ten checkboxes/radios each. When I switched to WHCM, wham,
suddenly every checkbox and radio on the page was checked! I swear they
were glaring up at me! It was like being hit by one of those steel balls
they use for demolishing buildings!

So developers who want to be truly accessible need to be aware of this, and
not use their page background colour, or opacity, to hide their ticks and
dots. The solution is simple; we normally tell developers who want to hide
something to use display: none. That is what they should use in this case
also, on the elements making up the ticks and dots. Or remove the :before
or :after items if they used them.

This is a very serious matter for people who have to use colour modes like
WHCM, because it means they cannot see whether radio buttons and checkboxes
are checked or not - making it impossible for them to complete forms. (And
by the way, saying they should switch out of WHCM when on websites like
that is not a valid solution, because the user doesn't know that's cause of
the problem. All they know is they have non-working checkboxes!)

Does this fail the WCAG? I think it does, for the following reasons. The
Use of Color SC, 1.4.1, says "Color is not used as the only visual means of
conveying information, indicating an action, prompting a response, or
distinguishing a visual element". Now it is true, the creators of that SC
were thinking in terms of designers intentionally giving colours meanings,
as for example using red and green to mean things. But though technology
has moved on, the principle stated in 1.4.1 still applies the same as ever.
Giving checkbox ticks a white colour to hide them on the white page (or
using opacity), to indicate the boxes as unchecked is using the different
colour as a coding mechanism, rather than giving meaning to the white
colour as such, and the consequences for WHCM users is entirely
unintentional.  Nevertheless, that unintended consequence is a direct
result of disregarding the SC by using a change in colour as "as the only
visual means of conveying information". So yes, this is not complying with
1.4.1. It is therefore a WCAG fail.

Purists will say the WCAG doesn't tell us to consider High Contrast tools.
But the WCAG doesn't tell us to consider switches, or voice-control tools,
or even screen readers come to that, but we do nevertheless. It just says
assitive technology, and High Contrast modes are  just another example of
that.

As regards your question about using outline: none, that is another trap
for the unwary where again, no thought is given to the many people who use
colour changes like WHCM. (Google's Material UI does it where it allows
shaded areas instead of a keyboard focus outline.) If people want to use
their own special effects to show focus (hey, it's good to find web
designers who actually bother to consider keyboard focus, too many don't!),
 I generally recommend they do that, but also create a focus outline that
is the same colour as their page background (and it must change colour as
it moves onto different backgrounds).

That way the outline will be invisible to most people, but users who are
using special colours of any kind, using any mechanism, will see the
keyboard focus outline (if they are also keyboard users). They may also see
the custom indicator as well depending on how that is done, but too much is
better than too little - at least they can see where they are and operate
the page! We should teach full accessibility, not limit ourselves to just
WCAG compliance alone.