Re: is any WCAG criteria to account both default and Dark mode for content

What has already been said is all perfectly true. However, I do think web
development teams, and ourselves in the accessibility industry, should be
prepared to go beyond mere WCAG requirements where needed, and consider
other aspects of accessibility that affect people. In particular, we should
consider use of these dark modes, which are used permanently by a sizeable
number of people with vision issues. And Windows High Contrast (WHC) mode
is probably the most commonly used one, so we should certainly consider
that.

For instance, a very common practice among web designers is to eschew
HTML's checkboxes and radio buttons, in favour of something better looking.
Unfortunately, they regularly end up producing components that are unusable
by people using Windows High Contrast or dark modes.

Now, if designers and developers are going to depart from standard HTML in
this way, that's not wrong in itself. But they should be prepared to accept
responsibility to give some attention to ensuring their creations are
usable in most commonly used modes. And we, as accessibility consultants,
should be prepared to give them the guidance they need in doing so. The
principles and methods are, after all, easy enough to both teach and apply.

The basic principle to understand with WHC mode is that the system
overrides the website's CSS - it reduces the foreground colours of all
content to one colour, and all background colours to another one, and
borders are likewise reduced to just one colour. Knowing that, it is easy
to ensure that a custom component remains visible in WHC mode, and many
other dark modes.

For instance, the above custom checkboxes are usually done by creating a
tick shape, often using shapes in the page's background colour in their
CSS, so they look unchecked. Then the developer changes the colour to a
different one when the user checks the checkbox. But in WHC these ticks,
both checked and unchecked, all become the same colour as the rest of the
background, so remain invisible. Or if the developer made them from lines
in a foreground colour, they all reduce to the WHC foreground colour, so
all look checked! But this is easily solved - once aware of the problem,
the developer only has to use different CSS to hide the unchecked ticks,
and all is well. (I can outline methods for other components if wanted.)

It just needs testers and auditors to test in WHC mode to look for anything
unusual like that, and to explain the solution to the developers when it
happens.