Tracking and documenting high contrast

[jongund]

Currently we do not have a way to identify which examples support high contrast settings in operating system and which examples have support in mobile devices for both touch and mobile screen readers.

Issue needs to address:

• What is our definition of high contrast support?
• Which mobile devices and resolutions do we test with?
• What versions of mobile screen reader we test with?
• How do people using the practices learn which examples meet high contrast requirements?
• How do people using the practices learn which examples meet mobile support requirements?
• How do we document features to automatically generate information in the coverage report?
• Do all examples need to comply with high contrast compatibility requirements to be included in APG?

list of examples with high contrast compatibility issues

Mobile support is being tracked in the issue 1620

[a11ydoer]

@carmacleod Comment from Carolyn: List of examples that were previously noted to have WHCM issues: https://github.com/w3c/aria-practices/issues/1132#issuecomment-534418273

Comment from @a11ydoer
Potential place to add the info is ARIA APG coverage report. https://raw.githack.com/w3c/aria-practices/master/coverage/index.html

[carmacleod]

List of examples that were previously noted to have mobile/touch issues: https://github.com/w3c/aria-practices/issues/8#issuecomment-543176368

[a11ydoer]

Thanks for adding the related issue to this one, @carmacleod

[carmacleod]

I have hopefully answered the question, "What is our definition of high contrast support?" in the Accessibility review section of the Pull Request Review Process wiki page.

[JAWS-test]

@carmacleod

Make sure everything has suitable contrast and ensure that icons have at least 1:3 contrast ratio against background in both themes.

I think this sentence is not optimal:

• What is suitable contrast?
• Why only 3:1 contrast to the background? The High Contrast is used when I need better contrasts
• Why only in both themes? Maybe I need special color combinations

A better support would be that monochrome icons are designed to be displayed in the foreground color (currentColor). For non-monochrome icons it would be better if they are not transparent or have an outline

[carmacleod]

@JAWS-test Good points, and I will try to fix up the wording.

Here's some of my rationale, FYI:

• We don't have the resources to test all possible color combinations, so I chose 2 common themes that are opposites.
• I noticed that icons that have not been designed with high contrast in mind fail 3:1 on one of those 2 background colors (probably because the designer was either only testing on a light background, or only testing on a dark background).
• So I am using 3:1 for icons as a way to prove failure, and not necessarily as a goal to achieve.

Other notes:

• I didn't mention 4.5:1 for normal text because the OS forces all text to the high contrast text color, so there's not really a choice at this time (unless media queries are used, but we're not using those, and the new stuff isn't really available everywhere yet). I think the OS would still need to meet the WCAG minimums.
• I should also add a note about focus indicators and hover effects (i.e. both should be visible... or maybe I should say "highly visible"?).

Maybe I should use fuzzier words and not even mention contrast ratios? Something like, "Make sure all necessary UI elements are visible and inherit the selected high contrast theme. Make sure the page functions correctly and behaves consistently using keyboard and mouse in both themes."

Random questions that I just realized I should think about:

• Should/do purely decorative images disappear?
• Is there any scenario where the OS would choose to display an image's alt text in high contrast mode?

[StommePoes]

Should/do purely decorative images disappear?

Unfortunately, this was the case not so long ago. IE11 still hides CSS background images, the idea originally being if they're images set with the CSS background property, they're probably decorative. Unfortunately, CSS background images were and are used extensively as content images, causing WHC users a lot of problems. For this reason, Edge and Firefox expose background images, as well as CSS gradients and opacity.

The takeaway is, I don't believe it's possible for software to determine whether content is decorative or not.

Is there any scenario where the OS would choose to display an image's alt text in high contrast mode?

I don't happen to know of any that does. Heck, browsers aren't great at exposing alts when images don't load (if the image dimensions are too small... I recall Firefox was the only browser doing this correctly, but haven't checked these recently).

[JAWS-test]

@carmacleod No problem. First and foremost, I am glad that the High Contrast Mode is considered here at all. That is not a matter of course. Within WCAG, for example, it is controversial and many WCAG test procedures that I know of do not test High Contrast Mode.

We don't have the resources to test all possible color combinations, so I chose 2 common themes that are opposites.

That is clear. There are an infinite number of combinations. My point was to make recommendations for graphics that are not problematic with any of the combinations: no transparent icons unless they have an outline, or for monochrome icons the color of the icon matches the text color in high contrast mode (e.g. font icons or SVG graphics with currentColor). If I take this into account, I don't have to test in High Contrast Mode at all.

I should also add a note about focus indicators and hover effects (i.e. both should be visible... or maybe I should say "highly visible"?).

The focus indicator should be visible, of course. I am not sure if it is possible to define any contrast or size requirements for visibility. In principle, the requirements of WCAG 2.2 can be followed.

WCAG does not currently have any requirements for hover (except that when colors are changed on hover, the resulting contrasts for text and icons must not be less than 4.5:1 or 3:1, so that the content under the mouse pointer is still clearly visible - However, this should not be relevant in High Contrast Mode, since such color changes are then no longer visible anyway, at least with text.). But WCAG does not require that a hover state be displayed at all (see https://github.com/w3c/wcag/issues/899 and https://github.com/w3c/wcag/issues/896). In this respect, only a recommendation can be given here. But which ones? Color changes are hardly possible. I.e. only a border can be displayed or the already existing border style can be changed. But that would be very untypical for hover states.