Are browser/OS settings (exposed to web content as prefers-* features) acceptable as a mechanism?

[patrickhlauke]

We've had some related discussions in past, but just to get some clarify (hopefully): is it acceptable for a site/app to enable certain features/behaviours/styles (which then pass the requirement of a Success Criterion) only when a particular browser/OS setting is enabled?

To be clear, not talking about reliance on 3rd party/assistive technologies, but more things like:

• a site uses colour combinations that fail 1.4.3 Contrast (Minimum), 1.4.6 Contrast (Enhanced), 1.4.11 Non-text Contrast, but if a user explicitly has their OS set to high contrast (which is now possible on most platforms), it switches to a theme/colour combinations that do pass (via prefers-contrast media feature query )
• a site uses animation effects and/or autostarting videos etc, failing 2.2.2 Pause, Stop, Hide and 2.3.3 Animations from Interactions, but suppresses them or offers play/pause/stop functionality if the user has set their desire for reduced motion (via prefers-reduced-motion media feature query)

(assume for this discussion that all target operating systems support a way for the user to set these - i know there are currently some edge cases, such as on android, where this is not fully consistent yet)

While initially I was a bit skeptical of this, it does seem to gel conceptually with other cases like 1.4.4 Resize Text (though the normative wording there is obviously different from the scenarios above, as it talks about "text can be resized", while the SCs above have more clear cut language).

A possible way to see the prefers-* adaptations may perhaps be that they constitute a way to switch/change a site to a conforming alternate version - then the question becomes more whether or not the OS/browser settings for the preferences can be consideres accessibility supported methods (not provided by the web content itself, but by the OS/browser though).

---

Of course, one argument against allowing this would be if we treated prefers-* adaptations as simply "variations" of a page, in the same way that we treat different viewport-size-based presentations in the last note of Full Pages.

In that case, we could argue that no, even if a user hasn't explicitly expressed a preference, the SCs should not fail (i.e. contrast should be sufficient, animations/motion should pass the related requirements of the SCs, etc, even in the variations where a user has not explicitly expressed their preference).

This is a tricky one: while I'm personally all in favour of including the prefers-* into the "Full Pages" note for all other SCs (i.e. if a site switches to some variant that does inaccessible things not just based on viewport, but any of these other media query features, then in my mind it fails), I would still think that for those specific SCs about contrast and animation/motion it is acceptable to accept only those variants as being the minimum needed to pass the SC, even though other page variations may fail them. This makes it slightly tricky to explain tersely (but I think it makes logical sense).

---

Related, this idea of a browser setting counting as a mechanism (provided it's widely available) seems to also feature in trusted tester (from @mraccess77's comment here #1824 (comment))

[patrickhlauke]

Ah, forgot the we already have Technique C39:Using the CSS reduce-motion query to prevent motion as a sufficient technique for 2.3.3 Animations from Interactions, which does rely on prefers-reduced-motion.

So, based on that, can one infer that providing high-enough text/non-text contrast based on prefers-contrast media feature query would be just as acceptable/sufficient? Or is C39 only allowed because the normative wording for 2.3.3 says "can be disabled" (implying that it doesn't need to be disabled by default, and that there can be a mechanism), whereas 1.4.3/1.4.6/1.4.11 don't have that suggestion of "the user has the ability to influence this"?

[alastc]

The concern (for me at least) is whether a particular feature is sufficiently well known to be an easy 'fix' across users.

For Animations from Interactions it didn't create concern because:

• The SC text included mechanism like wording: "can be disabled", leaving it open to a user-agent means of doing that.
• It had good support across platforms, so adding a sufficient technique was fairly safe.
• The complaints about iOS7 and other things lead to fairly widespread knowledge of the feature (relatively, not universal).
• It was AAA.

It makes me think there's a bit of a continuum of user-agent related options:

1. Full AT which works with / on-top-of a browser.
2. Browser based pluggins, not provided by default browser, but built on them (e.g. stylus, heading navigation pluggin)
3. Specialist features of the browser (e.g. the extra focus indicator in accessibility settings, or overriding the default font family)
4. General features such as zoom, with one-step access in the interface.

We've felt able to rely on 1 because if you need it, it is necessary to use. 4 is considered reliable as it is built in and obvious.

2 & 3 have historically been considered useful, but not reliable (for an SC), due to cross-platform differences and lack of user-knowledge about them.

I think most prefers-* features fit into 3, with the added complication that they can apply in different ways (e.g. dark mode having a default of on during the night on some platforms).

For colour contrast, I'm not sure that there is a clear relationship between the settings and the browser action? I.e. at what point on the iOS / Mac slider does the prefers-preference trigger the "more" contrast setting? And how much is done at the OS level? Is that consistent across android & windows?

I think we need to take it on a case by case basis, as they apply in different ways...

[patrickhlauke]

Cross-posting (from https://mastodon.social/@patrick_h_lauke/109662042329032053 ) some of my findings while testing for the contrast media query and general availability of an explicit high contrast preference:

[on Windows] high contrast is tied with forced colours (née Windows High Contrast Mode, WHCM). so yeah, this sways me towards this preference not being production-ready on this platform.

however, on macOS, there's a distinct "System Preferences > Accessibility > Display
Increase contrast" option, which doesn't force colours, but does make prefers-contrast: more evaluate to true.

Ditto in iOS/iPadOS: "Settings > Accessibility > Display & Text Size > Increase Contrast"

on Android, there's "Settings > Accessibility > High contrast", but currently it is not exposed correctly to browsers (or browsers don't take advantage of it/get a hint from it). https://bugs.chromium.org/p/chromium/issues/detail?id=1344929

The oddest one out is Samsung Internet on Android, which has its own kind of WHCM in "Settings > High contrast", but then still evaluates prefers-contrast: no-preference and forced-colors: none to true.

In short yeah, it may not be as stable/reliable yet as it should be

[alastc]

Response agreed by the group:

---

Whether a prefers-* feature can be used as sufficient to pass a criterion will need to be evaluated on a case by case basis.

It requires that the SC use text that allows for user-agent mechanisms (like Animation from Interactions), and that there is sufficient cross-platform support.

In that case we can either create a sufficient technique, mention it in the understanding document, or open and resolve an issue to that effect.

It is possible that organisations could rely on it before the group assesses something, if they have a constrained envirnoment for users (e.g. intranet users with that setting available to everyone).

[detlevhfischer]

@alastc As discussion seems to have petered out (perhaps everyone being happy with the draft response), should this then be the proposed WG answer, and the issue ready for survey?

[juliemoynat]

It would be, for me as a concerned person, terrible to allow websites to rely on prefers-contrast to provide sufficient contrast. Not everyone who needs text to have sufficient contrast needs all interfaces to have the same colors or to be in very high contrast (black/white, black/yellow...). For some people, very high contrast (or dark background) even hurts their eyes.

On Windows, the high contrast mode changes the colors everywhere and it is not necessarily suitable for all people who need sufficient contrast for texts.

My Android phone, in high contrast mode, adds a border around each letter, which makes the text even more unreadable.

For the 1.4.3 and 1.4.11 criteria, this does not seem appropriate at all. Eventually, it might do for the AAA level 1.4.6 criteria.

Moreover, about prefers-reduced-motion, as I understand it, these feature exist mostly for people with a vestibular disorder which is different from having ADHD (Attention deficit hyperactivity disorder). For example, smooth animations on scrolling a page may triggered a person with a vestibular disorder but not a person with ADHD. Or, animated GIFs in articles may triggered a person with ADHD but no a person with a vestibular disorder.

And, it's "reduced motion", not "no motion". So I think it addresses a different problem than what criterion "2.2.2 Pause, Stop, Hide" is intended to address.

[mraccess77]

Like Juliemoynat, I would be concerned if I only get sufficient contrast when my system is in high contrast mode as I don't use high contrast mode. When these other modes are activated other things could break and as we have discussed in another Windows HC mode is not required - so HC mode then might break other things for use while HC mode support is not required and we end up in a loop of the only way to get sufficient contrast text is to now get an inaccessible site where state or focus indication is lost in HC mode.

[patrickhlauke]

a late rejoiner on this thread, but this may be relevant https://tetralogical.com/blog/2023/04/21/meeting-wcag-level-aaa/

in short, for our work site, we opted to only show very high contrast (7:1) AAA colours when prefers-contrast: more evaluates to true. however, for AA, we have valid colour combinations by default. this is, admittedly, a pragmatic compromise

[alastc]

Closing as the response above was agreed.

It is possible for techniques to be created which would utilise one of the prefers mechanisms, but we'll take it on a case by case basis.

[patrickhlauke]

just to add more context for @juliemoynat and @mraccess77 's concern about Windows High Contrast: that is currently quite a rubbish limitation in Windows that there's no user setting that cleanly separates high contrast from forced colours. and agree that not everybody who wants more contrast also wants forced colours.

and regarding Android, as I noted in the article, there's no "proper" high contrast setting for web content, unless things have progressed since...

Android currently lacks any support for setting high contrast. While there is a "High contrast text" toggle in "Settings > Display > Display size and text" in the default Android OS and an equivalent "High contrast fonts" toggle in "Settings > Accessibility > Visibility Enhancements" on the popular Samsung-flavoured version of Android OS, these settings only affect the operating system itself. Regardless of this OS-level setting, browsers on Android always report prefers-contrast: no-preference, and the custom prefers-contrast: more styles are not applied.

https://tetralogical.com/blog/2023/04/21/meeting-wcag-level-aaa/