RE: eNewsletter Guidance?

There is a specific WCAG failure technique relating to specifying foreground colors without specifying background colors or vice versa.

https://www.w3.org/WAI/WCAG21/Techniques/failures/F24

Testing with dark mode might detect some instances of non-conformances, but it is not a particularly good way to test this type of failure. Automated testing tools are probably the best way, but as always you need to manually verify anything they report.

If you have been asked to do a WCAG audit, it is very important NOT to go beyond strict WCAG conformance. By all means provide a separate report that contains all the accessibility issues that are not WCAG non-conformances, but you must not simply invent new WCAG success criteria yourself and then claim that a website is non-conformant. A WCAG audit has a very specific scope, whereas an accessibility audit can be anything you want it to be.

Steve


From: Pyatt, Elizabeth J <ejp10@psu.edu>
Sent: 09 March 2021 00:15
To: Patrick H. Lauke <redux@splintered.co.uk>
Cc: w3c-wai-ig <w3c-wai-ig@w3.org>
Subject: Re: eNewsletter Guidance?

We're probably in general agreement, but....


On Mar 8, 2021, at 5:06 PM, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:

because there may be a contrast error generated which IS a WCAG violation.

Contrast checks are done against what the author defined, not against what the end result of a user adaptation may be, though ... because authors cannot account for the quirks in which users may have set their particular environment, what non-standard changes a particular OS/user agent does when switching to some form of forced dark or high contrast mode, etc.

In this case, I would argue that the author did not fully define the color palette to ensure contrast across multiple platforms. There's a different between specifying black text on white and black text on "default". The former is less likely to fail in dark mode (and I do know this from experience...)

If a user chooses to always override the author, then it's a different situation.




I'm interpreting your comments that the burden of remediating a darkmode glitch would fall on the user, but if the darkmode user is using it reduce visual strain, then it could be considered an accessibility issue to the user. The ideal is to NOT have the user remediate bad content.

Not saying anything about the burden, and yes an author should test and make sure their output is resilient. Again, we're making the distinction that this is NOT about WCAG compliance (which is silent about dark  mode etc at this point), and goes beyond the normative requirements of WCAG. Just want to be clear that if something fails to correctly adapt to dark mode, we can't just go around saying "so this fails WCAG".

This is where I think it's sometimes important to go beyond strict WCAG compliance, especially with new technologies. There will always be a gap in emerging technologies and the exact standard.

It seemed like people were saying that if it's not in WCAG, it isn't something to worry about. I don't think you agree with that.




For these reasons, I personally would recommend testing your email messages on darkmode. As I said, I've seen many colleagues switching to that mode.

And that's good advice of course. Just being clear that this goes beyond the pure requirements of WCAG.
Duly noted...

P

Elizabeth

=-=-=-=-=-=-=-=-=-=-=-=-=
Elizabeth J. Pyatt, Ph.D.
Accessibility IT Consultant
ejp10@psu.edu<mailto:ejp10@psu.edu>

The 300 Building, 112
304 West College Avenue
University Park, PA 16802
accessibility.psu.edu<http://accessibility.psu.edu>