search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.14k stars 256 forks source link

Do issues with Windows high contrast mode fall under WCAG 2.1? #623

Open mraccess77 opened 5 years ago

mraccess77 commented 5 years ago

There are some Windows high contrast mode issues that I’m not sure where how they fit into current WCAG criteria/testing. If these are deemed to not fall under WCAG 2.1 I will propose to the LVTF for discussion in future versions.

Examples from Windows with IE 11 and Firefox

The closest SC that might fit would be SC 1.4.8 Visual Presentation as it talks user selection of foreground and background colors -- but it's not clear if it applies to text and if borders are considered foreground or background colors.

patrickhlauke commented 5 years ago

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).

jake-abma commented 5 years ago

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

Turning on Chrome in Windows High Contrast mode

Turning on Firefox in Windows High Contrast mode

Mac OSX Invert Colors

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).

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

lauracarlson commented 5 years ago

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?

mraccess77 commented 5 years ago

@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.

jake-abma commented 5 years ago

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!

patrickhlauke commented 5 years ago

@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...

mraccess77 commented 5 years ago

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".

patrickhlauke commented 5 years ago

"...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

jake-abma commented 5 years ago

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...

patrickhlauke commented 5 years ago

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)

StommePoes commented 5 years ago

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.

patrickhlauke commented 5 years ago

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?

alastc commented 5 years ago

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:

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.

alastc commented 5 years ago

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.

mraccess77 commented 5 years ago

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.

alastc commented 5 years ago

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.

StommePoes commented 5 years ago

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).

alastc commented 5 years ago

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.

StommePoes commented 5 years ago

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?

alastc commented 5 years ago

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.

electronicwoft commented 5 years ago

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?

alastc commented 5 years ago

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

JAWS-test commented 5 years ago

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

Problems in HCM can be:

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.

JAWS-test commented 5 years ago

@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?

JAWS-test commented 5 years ago

@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)

JAWS-test commented 5 years ago

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

JAWS-test commented 5 years ago

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 commented 5 years ago

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.

HCM, similar to users setting their own user stylesheets etc, is outside of the direct control of authors. So you can't expect authors to be on the hook if a particular HCM implementation (or a particular user's own stylesheet) end up with failed combination of contrast. so from a WCAG perspective, I'd say there is no requirement at all...you can't make authors responsible for the choice of tools/solutions that ignore most author-set styles and apply their own.

JAWS-test commented 5 years ago

See also discussion starting at: https://github.com/w3c/wcag/issues/867#issuecomment-524186272

StommePoes commented 5 years ago

@JAWS-test

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.

It is a bug, but I see it was fixed recently! https://bugzilla.mozilla.org/show_bug.cgi?id=697836

"custom-css-selections-become-invisible bugs" What does that mean?

It means custom CSS selections (using ::selection) become invisible when users run Windows High Contrast: https://github.com/csstools/sanitize.css/issues/173

And I could have sworn there was a bugzilla on this but since I haven't been able to find it in a while, I may make my own. They can always dupe it if I'm wrong.

JAWS-test commented 5 years ago

@StommePoes

It is a bug, but I see it was fixed recently!

Using Firefox 69.0 with Windows 8: The "bug" still exists even if the ticket was closed at Mozilla. I don't see it as a bug because the colors can be set in Firefox.

There are other bugs in High Contrast Mode that occur in Edge, IE 11 and Firefox. This affects e.g. the mark element when its colors are adjusted. Then (depending on the color) the text content is bad or no longer visible. But this does not change the fact that the High Contrast Mode is well supported by Edge, IE and Firefox (where the implementation in Edge is best) and should therefore also be considered in the WCAG.

jlukosky commented 5 years ago

Using Firefox 69.0 with Windows 8: The "bug" still exists even if the ticket was closed at Mozilla

The update is in Firefox 70. If you install the beta it will be available.

brennanyoung commented 3 years ago

I'd like to add that Windows HCM expresses UI state via border color, but not in an entirely predictable way. A disabled control is drawn in a different color, whereas aria-disabled is drawn in the default color - indistinguishable from a non-disabled control. That's bad.

Does this mean that aria-disabled fails 'info-and-relationships' under HCM because the state is not communicated when the presentation format changes to HCM? Can authors not argue that the state is (nonetheless) 'programmatically determined' by the attribute, and Windows HCM is screwing up? Really need clarity here.

(These two attributes are already 'false friends' because disabled removes the control from the tab sequence, whereas aria-disabled does not. And I would argue there are valid use cases for both of these implementations, but that's another discussion).

patrickhlauke commented 3 years ago

Does this mean that aria-disabled fails 'info-and-relationships' under HCM because the state is not communicated when the presentation format changes to HCM

info and relationships works the other way around - ensuring that something that's clear visually is also conveyed structurally/programmatically. what you're asking is whether the fact the visual presentation isn't obvious of the programmatic state is covered by 1.3.1? in which case i'd say no.

patrickhlauke commented 3 years ago

and yes, aria-disabled has no influence on anything other than conveying the state to AT/via the accessibility tree. it does not change presentation or behaviour in user agents.

patrickhlauke commented 3 years ago

and lastly, by default, aria-disabled also doesn't change the way a control is presented in regular, non-HCM view. so not quite sure why you're mentioning it specifically here

brennanyoung commented 3 years ago

I mentioned aria-disabled because Windows HCM is ditching many of the visual indicators of markup state that the author may have chosen and unevenly imposing its own.

Consider this CSS example:

button[aria-disabled='true'] {opacity:0.8;}

In such a case, the author takes the trouble to provide the state info in both a visual and programmatic way. Windows HCM hides these distinctions, but I'm not convinced that WCAG unambiguously lets the author off the hook here.

JAWS-test commented 3 years ago

@brennanyoung

I personally consider it a violation of SC 1.3.1 if content in Windows HCM is not displayed correctly. I think the majority of the WCAG community sees this differently and would not consider Windows HCM to be relevant for testing.

In the case of aria-disabled, there are several ways to convey this correctly in HCM as well

disabled Screenshot: 3 buttons in HCM

<button>not disabled</button>
<button disabled>disabled</button>
<button aria-disabled=true style="opacity:0.8;">aria-disabled</button>
patrickhlauke commented 3 years ago

I personally consider it a violation of SC 1.3.1 if content in Windows HCM is not displayed correctly. I think the majority of the WCAG community sees this differently

because you're flipping the requirement of 1.3.1 on its head.

"Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

if, when switching to WHCM, the presentation is modified by HCM and a particular info/structure/relationship is now NOT conveyed through presentation anymore, the whole SC become moot. there is no SC that does the opposite, i.e. that says "a particular info/structure/relationship (and/or, to invoke kind of the opposite of 4.1.2, a particular role or state) must be visually presented", which is what you're trying to fail here it seems

JAWS-test commented 3 years ago

@patrickhlauke

if, when switching to WHCM, the presentation is modified by HCM and a particular info/structure/relationship is now NOT conveyed through presentation anymore, the whole SC become moot. there is no SC that does the opposite, i.e. that says "a particular info/structure/relationship (and/or, to invoke kind of the opposite of 4.1.2, a particular role or state) must be visually presented", which is what you're trying to fail here it seems

I see it differently: there are various AT with which the visual information is not perceptible, e.g. screen readers or HCM. However, both AT (screen reader, HCM) can recognize programmatic information and output it correctly. For example, HCM removes all colors, but then reassigns a color to elements according to their role and status in order to distinguish them. The screen reader also outputs role and status correctly only if this information is stored programmatically.

The Understanding of 1.3.1 states in the 1st two sentences:

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.

I can also achieve the display of the HCM by userstyle. I.e. if userstyles are relevant in 1.3.1, then it is also HCM

patrickhlauke commented 3 years ago

The Understanding of 1.3.1 states in the 1st two sentences:

yes and what that means is: the state etc is not just implied visually, but programmatically. so that somebody who uses user style sheets can craft a stylesheet that targets things based on the markup/programmatic information. it doesn't mean that authors need to foresee any possible user styles. the onus is still on the person making the user style sheet to target those programmatic/structural hooks. again, this is the exact opposite of what you think it means.

patrickhlauke commented 3 years ago

HCM removes all colors, but then reassigns a color to elements according to their role and status in order to distinguish them

so it's a failing of HCM for not doing it. again, nothing to do with a page's author.

JAWS-test commented 3 years ago

@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.

jake-abma commented 3 years ago

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!

jlukosky commented 3 years ago

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?

zelliott commented 3 years ago

Does 1.4.1 apply on HCM?

For example, in the example @JAWS-test shared in https://github.com/w3c/wcag/issues/623#issuecomment-760234894, the three buttons are distinguishable only by color. When browsing through the WCAG issues, I stumbled upon https://github.com/w3c/wcag/issues/1076#issuecomment-725172968 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).

patrickhlauke commented 3 years ago

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)

jake-abma commented 3 years ago

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.

StommePoes commented 3 years ago

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.

patrickhlauke commented 3 years ago

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:

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