One thing that always struck me with Windows high contrast is how (some) browsers apply their own custom heuristics based on it. It's not standardised behavior as such. Browsers just willfully decide to ignore specific author styles / style combinations, and modify their user agent styles. I really wish there was some documented behaviour/set of rules for UAs to follow when implementing adaptations based on WHCM.

Having said all that, I could imagine some high-level SC that would require that content/functionality is not lost if users have some OS-level adaptation/preference set (though this then brings up the issue of, say, macOS, where a high contrast setting is available, but this affects contrast at the overall display level, meaning it's not necessarily something authors can somehow control/predict other than testing specifically how the display of their content behaves in this mode).

Thinking further, there are other settings like a preference for a "dark mode", or reduced motion, that could also be added here. Though here it's likely more a question of content actively adapting to these settings, where supported by the UA (as this is not something that actively changes the way UAs render things, so even if content doesn't do anything specific for dark mode/reduced motion, it's not going to change in any way that is adverse).

Short answer on where to fit at the moment I think is nowhere, simply because you're not supposed to take into account any / all of the (implicitly contained OS) AT settings and all of the variations out there to test the content on (UNLESS specifically specified, like Zoom, Reflow, Accessible Names and Role, states and properties...)

The questions is if we will like to go that way and what exactly we are trying to tackle as the testing fase would increase a lot in knowledge and time to make sure these kind of options work consistently in different OS, UA, AT and plugins combinations.

I do agree though that we have an interesting challenge here though.

As we speak, the last couple of weeks I was confronted with high contrast issues with an application where people are complaining about it not working anymore properly in a newly build environment.

Some findings when investigating:

Windows High Contrast / Edge

• Input fields black on black
• borders for input fields do not appear at all (some web component setup...)
• focus indicator no contrast at all (as box shadows are ignored)
• the focus indicators present are based on 4 different kind of techniques as there is legacy code present (so not 1 solution fits all)
• some content not shown at all (because <mark> element is used)
• Other styling shown, a border while not present without high contrast (also with <mark> element)
• hover colors no contrast at all
• buttons have no adjacent colors anymore

Turning on Chrome in Windows High Contrast mode

• I get message to use a plugin for high contrast, Chrome ignores the setting
• Plugin doesn't work as it's not able to process webcomponent styling at all

Turning on Firefox in Windows High Contrast mode

• All colors are completely different than with Edge, blue on black instead of yellow on black for regular text.
• Get special focus colors (extra red and/or yellow lines, not coded for...)
• More fancy colors for hover, active etc. not expecting these at all

Mac OSX Invert Colors

• Input fields black on black
• border for input fields not enough contrast but visible
• Grey (placeholder) text on black not enough contrast
• contrast for buttons and adjacent background not enough
• focus indicator not enough contrast
• hover colors not enough contrast

This story continues for Android, iOS and many more UA/OS combinations and we're not even talking about the possibility for different default high contrast themes in OS / AT - zoomtools / extensions (besides adjust colors yourself).

• We also see a lot of accessibility options appear OS based (every year more and more) for Adroid, Windows, Apple iOS, OSX etc. so where does it stop?
• Do we need to account for settings for Grey Scale, Protanopia, Deuteranopia, Tritanopia etc.?
• Other setting like Color Corrections, Increase contrast, Invert Color, Colored Lense, etc.?

Doesn't mean we have to try to fix as much issues for the most common setting (as we have taken on the challenge for High Contrast) but a SC, how to objectively say Yes/No and all variation to test... will be very very hard and time consuming.

My 2 cents on responsibility goes to the OS/UA makers who need to make sure these helpful setting "translate" the content in the proper way in all its forms and appearances (like at least adopt all CSS properties and be consistent when different UA are used.)

Cheers,
Jake

Jake wrote:

My 2 cents on responsibility goes to the OS/UA makers who need to make sure these helpful setting "translate" the content in the proper way in all its forms and appearances (like at least adopt all CSS properties and be consistent when different UA are used.)

Perhaps tag this issue as issue(s) for Silver?

@jake-abma the challenge with my examples is that the author set the width to 0 and relied only on background colors -- so really isn't the platforms fault. The issue would affect users who turn off colors and with custom style sheets as well unless the user adjusted the width. There are clearly things the author can do break the experience -- and so I see it as a shared responsibility -- we just need to split out who is responsible for what.

Hi @mraccess77 , this will probably be a box of pandora as there are many combinations possible where it goed wrong with HCM on. Not only with background colors but lots more combinations. I do agree this is a real world issue and for specific components there are specific fixes possible (working on them myself too this week...) but failing on basis of a clear SC criteria will not be possible I'm afraid.

See here also a nice article from Scott with some more issues: https://www.scottohara.me/blog/2019/02/12/high-contrast-aria-and-images.html
Yes, sticking to native helps a lot, but will we prohibit the use of "our own" ARIA and CSS because HCM does a bad job?

Methods on how to fix common HCM issues will be a nice welcome, but the hard part must be done by OS/AT or do you see lots of imposed obligations for authors?

Propose to the LVTF for discussion in future versions seems like a good one anyway!

@jake-abma the challenge with my examples is that the author set the width to 0 and relied only on background colors -- so really isn't the platforms fault. The issue would affect users who turn off colors and with custom style sheets as well unless the user adjusted the width. There are clearly things the author can do break the experience -- and so I see it as a shared responsibility -- we just need to split out who is responsible for what.

there are very specific things authors should avoid doing not to break the current very specific WHCM custom adaptations that the various browsers do. the problem, as with custom style sheets, is being able to define this in a general way that is predictable and testable for authors. as WHCM adaptations are non-standard, and essentially custom styles that browsers decide to apply/styles they decide to ignore, it's difficult to formulate a high-level SC that doesn't turn into a shopping list of "do this, but don't do that, or if you do, make sure you also do this, oh but in this other browser, that can also cause issues for different reasons". it gets very messy, very quickly.

unless we go for a very handwavy AAA "make sure it works with the most common browser/high contrast combinations" - which would at least put a marker down, but be ripe for reinterpretation, misinterpretation, and shifting of goalposts as browsers change their behaviors since it's all non-standardised stuff...

I wasn't suggesting a broad HCM criteria -- but something concrete and similar to 1.4.11 such as "When user interface components are created using markup languages, visual information required to identify user interface components does not rely on background color".

"...or on a box-shadow, or outline, or ..." and all the other things most HCM modes in windows browsers drop/ignore? or focus just on background? i think that's the danger here, that it becomes a laundry list of stuff that we tell authors not to rely on

We also welcome CSS Dark Mode into play and what will happen when HCM is turned on...? Interesting here is how we ever get designers / developers to take into account all these variations as we already have such a long list to communicate. I do see possibilities for "bonus point methods" for silver or gold in WCAG 3.0 possibly...

yup, and being able to get away from normative testable "binary" hard statements, and to more vague/common sense descriptions, a la "make sure that the content works/can be understood when users enable adaptations like WHCM, dark mode, prefers-reduced-motion" (this would require that content doesn't actively break apart/drop stuff as the minimum), and a more stringent "make sure that the content correctly detects and appropriately adapts to user preferences like WHCM, dark mode, prefers-reduced-motion" (where this requires authors to actively detect these and provide appropriate adaptations/styles)

While sometimes we can use "color-alone" (for example when an author relies on a red border color change for showing an error state) when auditing, we've mostly been unable to use WCAG for it, and instead stuffing many under a general "ux" section: since technically if you add in a bunch of aria-foo, you're not relying on color alone to expose information, but in practice sighted users don't get access to aria-foo, so as far as they're concerned, you are.

That last point (yeah there's something programmatic but invisible) hits so many things, really. Invisible labels!

but something concrete and similar to 1.4.11 such as "When user interface components are created using markup languages, visual information required to identify user interface components does not rely on background color".

This would be awesome (or even if that were simply made "color", referring to the discussion on color-alone as difference between links and non-links) and I think it's on the right track. It feels a stretch today to say something along the lines of "if the only visual indication of ... is color, then we're interfering with ... contrast-enhancing or color-adjusting assistive technology" (under 5.2.5 Non-Interference). If new SCs are to be made, this one would be high o my list.

We haven't found it too hard to make actionable lists of DO's for those we audit, mostly because they almost all fall under "use something in addition to color/color changes" with then the WHC-specific notes on box-shadows and background images. Is there a problem with mentioning that in an Understanding page, just to give authors some info even though it's tech-specific? Something nice to document instead of hoping someone's given a talk on such a thing and has slides, or hoping some corporation documented this on an internal guidance page or something.

the hard part is coming up with a sufficiently descriptive normative requirement that actually catches the problem, while being tech agnostic, doesn't result in false positives that wouldn't be a problem, and also doesn't leave glaring loopholes that authors can use to essentially respect the letter, but not the spirit, of the SC. and again, in my mind, this is down to the very binary nature of normative SC language.

it starts to get harder when we see that certain browser/WHCM modes also mess with/ignore/omit borders, or don't provide stylings for things like default/unstyled <mark> and similar. how to catch that sort of problem (which arguably is a problem/quirk of that browser's WHCM choices)? or do we live with the imperfection that these still won't be covered, and that a proposed SC would only mitigate, rather than solve, the core problem?

Looking at the issues raised by Jon & Jake, it does seem they would be easier to solve in the user-agent rather than the website.

For example:

• If the UA changes the color of an input border, ensure it is at least 1px thick.
• Focus indicators have an enforced/over-ridden color that contrasts with the over-ridden background.

It is a bit like the requirement for authors to set both foreground and background colors, but more so.

Unless there is a relatively simple mantra for developers that will fix these issues (e.g. include borders, even if they are transparent), I don't think we'll get far with this one.

A more positive step might be to start raising bugs for the UAs, e.g. the chrome plugin, or Microsoft.

They might fix them, or they might respond with "oh we tried that but it didn't work because authors do X & Y". In which case that should give us a better idea of the problem space, and what authors would need to do.

I'll propose a response to conclude this:

We recognize that this is a difficult and important issue for users, but it is currently a grey area as to what the responsibility of the author and the user-agent should be.

It is also difficult to include a general requirement that content works with user-agents in the WCAG 2.x series, that might be better handled in Silver where user-agents are in scope.

In the meantime, it would be useful for people with experience of the issues to submit bugs to the current user-agents.

Indeed adding transparent borders and outlines is an important aspect of meeting this need. Pushing everything to User Agents is a challenge -- Chrome's high contrast mode doesn't meet the needs of users and often makes pages harder to see and I've gotten nowhere raising those concerns last year at CSUN. You could make the UA argument for about anything including contrast -- why have a contrast requirement -- contrast should all be at the UA level. Same thing for color -- if you have ARIA-required the UA should use that to expose the meaning for people who can't distinguish red. The UA for that matter should restrict focus in dialogs, could change the focus order to match the DOM and also provide keyboard access to interactive elements with appropriate roles. We've been down this rabbit hole before. The UA can detect language -- why require authors to use the lang attribute? UAs can fix parsing issues -- no need for 4.1.1 either.

You could make the UA argument for about anything including contrast -- why have a contrast requirement -- contrast should all be at the UA level.

You probably know the history better, but there are implicit levels to it. The guidelines push authors "this far" to avoid creating barriers, and users / UAs are pushed to support certain things as well.

Having contrast by default helps a lot of people, and doesn't push the design too far.

If there are some concrete things we can ask from authors, great, I'm not opposing that at all. But I'm not keen on a general "it should work with this type of user agent".

I've gotten nowhere raising those concerns [with Chrome] last year at CSUN

Ok, good to know. Has anyone asked Microsoft? Especially with their move to Chomium for Edge, they might be up for changing things.

Has anyone asked Microsoft? Especially with their move to Chromium for Edge, they might be up for changing things.

Looks like they are looking to do it?
https://twitter.com/aardrian/status/1093498936495689734
Reading the link, it's not clear to me what exactly is going on. The github https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md shows examples of high contrast working in Chrome theoretically, but also states only IE and Edge support, when in fact Firefox has a sort of half-assed support as well (though with the links-are-blue-even-in-dark-themes and custom-css-selections-become-invisible bugs make using a dark theme in FF pretty much impossible).

Thanks @StommePoes, I’d missed that.

It looks early stages, but if that media query were defined as part of the CSS standards it would give us something concrete to point to.

For example, something to the effect of: if you remove any of the elements from the CSS high-contrast media spec, you need to define the replacement in a media query.

I’m a little worried by the way the query is intended to work, where you can define colours for the ‘any custom contrast’ mode, that seems odd, but perhaps if it progresses (probably not in Edge?) we can comment on that.

Also, I think (as above) it would help to ensure that some elements appear in HC mode, even if the author has tried to remove them.

I'd kinda rather people didn't set colours for high contrast themes. We choose our preferred theme for a reason. The only reason we need to discuss it really is because of WHC's failings: aria-foo'd components aren't recognised as form controls, aria-disabled cannot offer a disabled state to the OS, etc.

Maybe indeed this needs to come from Microsoft's end, though they have good arguments about all the things they can't know from the browser... maybe the exposed a11y tree could be offered to the OS?

Yea, it seems like it should be a matter of conveying the structure (including custom elements) and the UA should do the rest.

Something that confuses developers about ARIA (including me to start with) is that making something <span role="button"> doesn't trigger any behviour change, e.g. keyboard focus.

Similarly, if something has a role of button, in HCM we'd like that to look like a button regardless of what the developer's CSS says.

to what extent is support for high contrast covered by UAAG and the 'accessibility features' of user agents as specified in WCAG conformance requirement 4? Would the google high contrast extension fall under the latter, for example?

The google high-contrast extension would count as assistive technology from the point of view of accessibility supported.

@mraccess77: To answer the initial question from 15.02.:

• 1.4.8 is only AAA and therefore relatively worthless (rarely aimed at and not legally required)
• 1.4.8 is not suitable, because "Foreground and background colors can be selected by the user" does not mean the contrast adjustment, but the adjustment of text colors via the browser or the web application itself (and not via the operating system), see e.g. https://www.w3.org/WAI/WCAG21/Techniques/general/G148

Problems in HCM can be:

• Images of text not adaptable in HCM: 1.4.5 and 1.4.9
• Colour error marking not visible in HCM: 3.3.1
• If the role and status of interactive elements in contrast adjustment is not perceptible, this could also be 4.1.2, but I suspect that this is a somewhat too free interpretation of 4.1.2 that is not shared by others
• Reference to visual features, such as color, that are no longer visible in HCM: 1.3.3
• Most of the problems with HCM fall under 1.3.1 because:

The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes. For example, the presentation format changes when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author

HCM is a "presentation format change" and its simular to "user style sheet is substituted for the style sheet provided by the author"

Unfortunately, the examples under 1.3.1 are very screenreader-intensive and do not deal with the many other use cases such as HCM, User Styles etc.

@StommePoes

links-are-blue-even-in-dark-themes

The link color is not adopted by the operating system, but it can be set in Firefox: so I don't think this is a problem.

custom-css-selections-become-invisible bugs

What does that mean?

@alastc

The google high-contrast extension would count as assistive technology from the point of view of accessibility supported.

I agree that the Google High Contrast Extension is an assistive technology. Nevertheless, Chrome doesn't fulfill the UAAG because it requires it:

1.4.5 Default to platform text settings: The user can specify that platform text settings be used as the default values for text configuration. (Level AA)

About the relevance of HCM:

51.4% of respondents report using some type of high contrast mode. Of users that implement a high contrast mode, the majority use light text on a dark background.

https://webaim.org/projects/lowvisionsurvey2/#contrastMode

In this context, I am interested in what contrast requirements must be met in HCM? Surely the requirements of 1.4.3. and 1.4.11 must be fulfilled. However, visually impaired users probably use this mode because the contrasts 3:1 and 4.5:1 are too low for them. Therefore, the contrasts of 1.4.6 should perhaps be achieved in HCM (even if the criterion itself is AAA). How do other accessibility testers handle it?
Low contrasts in the HCM can arise e.g. by using the CSS property opacity. And with all applications, which do not possess the extent of the HCM of the operating system, like Chrome, Zoomtext etc..

@patrickhlauke

If I understand you correctly, we agree that 1.3.1 requires proper markup for both the screen reader and the HCM to work. However, HCM errors are not a violation of WCAG because they are not the responsibility of the web designer, right? The only dissent then would be that I would still say that aria-disabled is not accessibility supported in HCM and therefore should not be used without further markup thus.

If I understand you correctly, we agree that 1.3.1 requires proper markup for both the screen reader and the HCM to work. However, HCM errors are not a violation of WCAG because they are not the responsibility of the web designer, right?

Right!

If I understand you correctly, we agree that 1.3.1 requires proper markup for both the screen reader and the HCM to work. However, HCM errors are not a violation of WCAG because they are not the responsibility of the web designer, right?

Right!

What of the case where an author dictates the HCM experience? I've seen sites that have used custom colors and overriding the user's HCM color choices (I call it High Contrast Hijacking). Would that be SC 1.3.1, something else, or not applicable?

Does 1.4.1 apply on HCM?

For example, in the example @JAWS-test shared in #623 (comment), the three buttons are distinguishable only by color. When browsing through the WCAG issues, I stumbled upon #1076 (comment) whew @JAWS-test proposed that 1.4.1 should not apply on HCM, but I wasn't sure if any resolution was reached on the matter or if 1.4.1 had been updated accordingly (I couldn't find anything relevant on https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html).

as accessibility supported and non-interference are often cited in the context of HCM - just pointing out that if one takes the stance that HCM is/should be covered under these terms, then that would essentially negate most uses of CSS as an accessility supported technology, since HCM chooses to override/ignore specific aspects of any author-defined CSS. as a logical conclusion, it would mean that authors can never rely on CSS. i doubt this is a desirable outcome.

i'd be strongly in favour of a working group note (similar in style to, say, the Inaccessibility of CAPTCHA one) that collates material around designing in an HCM friendly way. but as far as making a new normative SC that's HCM-specific, I think that'd be very tricky to unambiguously articulate.

we do need some official take on whether or not HCM needs to be considered for certain key SCs dealing with visual presentation, such as 1.4.1. (where now a color difference of 3:1 or better is considered "not just color, but also luminosity/brightness" ... but HCM could override this regardless), 1.4.3, 1.4.6, 1.4.11, 2.4.7 (if CSS is used to suppress default outlines and instead uses things like box shadow, this may be overridden by HCM and result in no focus indication). personally, I think adding a note to all of these (or a note in the normative conformance definitions somewhere) to explicitly exclude tools/user agent features that modify author-defined styles (unless explicitly stated, like 1.4.12 and, to an extent, 1.4.4)

Totally agree with @patrickhlauke and the burden should be placed at MS for adding support for e.g. ARIA and CSS styles etc. not honored.

HCM can also be tweaked from the default by users and those options are... up to the user and to MS for making them even more mature.

the burden should be placed at MS for adding support for e.g. ARIA and CSS styles etc. not honored.

No, that defeats the purpose. They're removing author colours specifically to ensure the high contrast. They're removing fuzzy things like box shadow specifically because soft fuzzy partially-opaque things are not high contrast (they could consider painting box-shadows as solids in one of the theme colours but box-shadow's uses aren't just as focus indications and one could worry making them all solid would break some other number of things, visually).
I'm already fearful of some of the new CSS properties allowing authors (developers) to force their colours on me when I'm running high contrast. This is almost almost almost always someone's design preferences and looking around the web, I see most design preferences as user-hostile. Yes, it's pretty. But it's subverting my attempt to make it usable.
Even when I'm not running WHC, I regularly run into pages where some designer/developer insisted that the difference between the neutral state of a button and its focused state is going from medium purple to a slightly darker purple. Trying to get WHC to do that would probably fall under my definition of evil.

I do agree with wanting some ARIA support, so that things with aria-disabled can get the same styling as disabled elements... but I'm not sure how that would work on an OS-level setting dealing with applications who interpret ARIA (a browser, and not the OS). Currently I'm relying on lowered opacity, which works for WHC but can't say whether that would work for most other OS-based contrast settings.

They're removing author colours specifically to ensure the high contrast. They're removing fuzzy things like box shadow specifically because soft fuzzy partially-opaque things are not high contrast (they could consider painting box-shadows as solids in one of the theme colours but box-shadow's uses aren't just as focus indications and one could worry making them all solid would break some other number of things, visually).
I'm already fearful of some of the new CSS properties allowing authors (developers) to force their colours on me when I'm running high contrast. This is almost almost almost always someone's design preferences and looking around the web, I see most design preferences as user-hostile. Yes, it's pretty. But it's subverting my attempt to make it usable.

The problem as I see it is twofold:

• WHCM does very unique, and most of all undocumented/non-standardised, things to an author's styles. In terms of WCAG, we'd need to very prescriptively say, based on what it does today from testing etc, that authors can't rely on X (be it box shadows or whatever)
• at any point, WHCM could decide to change how it does things, how it works, making the SC either obsolete, or out of step with reality, or even counter-productive

It's a moving goal-post to try and define a normative SC that covers this, is my fear.

Yeah I can't see WCAG having much specific about WHC. Why, just the other blink-and-I-missed-it, a common "fix" for ensuring SVG icons did what text did in WHC (set the fill or stroke to currentColor so it does what text does) has suddenly quit working and now we're alerting clients everywhere they have to add m0aR CSS media queries (using the media query I'd otherwise rather devs not use). Who knows what'll change tomorrow?

So putting any of that in the spec sounds like a recipe for disaster.

Agreed response so that we have something "for the record":

The AG group appreciates that having customisations like High-Contrast-Mode (HCM) work properly are vital to many users.

However, WCAG 2.x does not explicitly address HCM. There are some failure techniques today such as failure techniques for pseudo content and CSS Background images as well as defining both foreground and background colors.

The place for more specification would be on the user-agent side of the equation, at least for the moment. Any criteria created for HCM could become rapidly outdated, possibly harmful if the user-agents change their behaviour.

If there were sufficient interest (i.e. volunteers) for creating a note or WAI-guidance page for authors, that is something we could tackle. It is also something that AG members could raise with vendors (e.g. Microsoft) to work with them to get more aspects of HCM publicly specified.

I agree with the response.

WCAG is scoped to content authors. Problems related to alternate/non-standard display modes is out of the hands of author control in part because it is not implemented consistently nor to any real standard across technologies.

This makes the media feature queries such as "...inverted-colors, monochrome, prefers-color-scheme, prefers-contrast..." dangerous territory for web developers tasked with creating a stable production site.

Guideline Guidance

Developing useful guidance for contrast is far from trivial, even when restricted to basic readability. Potential guidelines for contrast enhancement, contrast inversion, and daltonization become intractable without cooperation and alignment of the user agent and OS technologies.

Not to mention that the nature of these enhancements requires perceptually uniform color and contrast prediction methods to support them in a stable and consistent way, and I'm not going to finish this sentence because you all know what I'm going to say next... 😉 ...but I will add this is a subject of interest to many stakeholders, and a topic of active discussions therein.

Did we ever get to any consensus position on this?

The responses in this issue suggest that WCAG doesn't cover HCM currently, which I agree with, as I do with Alastair's proposed response.

do we think there's anywhere we can/should clarify this? any specific understanding documents? just that it's a question that bubbles up on occasion (most recently on the wai-ig mailing list), so would be good to have somewhere to point people to/prevent this question from even arising

Seems like a good topic for EO to take on.

I'm late to the party, but I wanted to provide some additional resources in reference to this earlier comment:

I really wish there was some documented behaviour/set of rules for UAs to follow when implementing adaptations based on WHCM.

Firefox content (ie. browser surfaces that are under control of the UA) is generally evaluated for HCM "compliance" based on the principles of this design guide. This is a relatively new piece of documentation, and one we're revising as our accessibility review process matures. It's our attempt to regulate HCM, in the absence of HCM-specific standards.

We've also started to document our current color overriding behaviour, both for HCM and general system color inheritance. You can read more about that here.

It seems like this issue aims to standardize HCM guidance for web authors, but if there is a desire to engage with browser vendors on this topic as well, please let me know. I'm a platform engineer on Mozilla's Accessibilty team, and I'm the primary developer for HCM in Firefox :)

Since no one has cited it before, it's worth mentioning that section 508 has 2 very relevant requirements for this.

502.2.2 No Disruption of Accessibility Features
Software shall not disrupt platform features that are defined in the platform documentation as accessibility features.

503.2 User Preferences
Applications shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor.

Add these 2 together, and the outcome should be that the user agent should not disrupt the Windows High Contrast Mode Setting, and that authors should preserve user preferences.

Telling where something breaks in that model is very challenging -- as is testing that something has broken.

It is possible to try to have this covered in some way by "accessibility supported" but as shown by some of the above discussion, it's difficult to know how to report such things.

it's worth mentioning that section 508 has 2 very relevant requirements for this

The same applies to the EN 301 549:

11.6.2 No disruption of accessibility features
Where software provides a user interface it shall not disrupt those documented accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software.

11.7 User preferences: Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.

The response above was accepted by the group as our position.

We are leaving it open as there is a desire to add this information to the understanding document (e.g. min contrast). (See survey)

As this has popped up in the A11y Slack today, with a project last week, and in a casual chat the week before (in the context of styling for forced colors mode in CSS), I would very much also like to see this identified in the Understanding document.

We were discussing this in A11y Slack again, which brought me here and caused me to dig a little deeper on the following:

Since no one has cited it before, it's worth mentioning that section 508 has 2 very relevant requirements for this.

502.2.2 No Disruption of Accessibility Features
...

503.2 User Preferences
...

Add these 2 together, and the outcome should be that the user agent should not disrupt the Windows High Contrast Mode Setting, and that authors should preserve user preferences.

In playing around with the GSA's Accessibility Requirements Tool (ART), I think 502.2 and 503.2 only apply if it is software not delivered through a web interface. For instance, the boilerplate the ART produces for Solicitation Development doesn't include 502.2 and, for 503.2, it specifically says the following:

Exception from E503.2 User Preferences: Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform to 503.2.