New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[mediaqueries-5] high-contrast media feature #1286

Open
patrickhlauke opened this Issue Apr 24, 2017 · 15 comments

Comments

Projects
None yet
6 participants
@patrickhlauke
Member

patrickhlauke commented Apr 24, 2017

Wondering if there's still potential for standardising a very simple implementation of a high-contrast media feature, as an indicator that the user has enabled high contrast in their OS/UA.

xref w3c/css-a11y#1

@frivoal frivoal self-assigned this May 1, 2017

@frivoal

This comment has been minimized.

Collaborator

frivoal commented May 1, 2017

Yes, I believe there is potential on this topic, and that we should address it.

However, I do not believe it to be very simple. Primarily because high-contrast means different things in different OSes and UAs, to which authors should react differently:

  • First axis
    • Contrast-boost via image processing at the pixel level (possibly done by the OS with no understanding of the content)
    • Content-aware contrast-boost, which may pick different (contrasty) colors for different types of content, treats images differently from text, could affect which font or font-weight is used (necessarily done by the UA)
  • Second axis: Is the contrast boost coupled with a color inversion (which can be done at the pixel level, or content aware to avoid inverting images), or with enforcing dark-on-light or light-on-dark (which assumes an understanding of what's content and what's background).

So, do we need 2 (or 12) completely separate queries to express all the various things that exist? 1 query with a bunch of values? Expose some higher level semantics? How?

I've heard ideas on this topic, and have a few of my own, but I don't think we have firm conclusions yet.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented May 1, 2017

Absolutely. Having very detailed indication of what kind of high-contrast the OS/UA are actually using will be tricky. Was only thinking as a first stage having at least an on/off indicator, but agree that it's possibly of little practical use to devs beyond a basic "pick strong contrasting foreground/background color combinations" (which would still be strongly contrasted in situations where the color inversion is done at pixel/OS level, and would be replaced by OS' enforced colors in situations like Windows High Contrast).

@frivoal

This comment has been minimized.

Collaborator

frivoal commented May 1, 2017

Not sure even that would help. For instance, OS X (at the system level) has two settings that work on boosting contrast: one that works at the pixel level, and one that is more content aware. The one that's content aware also adds (in the native UI at least) borders around things. If the high contrast pair of foreground/background colors that a web author picks accidentally makes the background match the border, you may accidentally be making things worse. Also, I don't think it is useful for an author to react to content having been put in high contrast mode by putting content in high contrast mode, since it's already been done. Either the author needs to do it because there's a request to do so but the UA hasn't done anything itself, or because the author knows that a particular way to boost contrast gives undesirable side effects with their content, and want to remedy that problem, in which case they need to know what adjustment has been made.

Here are a few things we may want:

  1. have colors been forcibly inverted at the pixel level (if yes, authors should do things like double-inverting images and removing shadows) (see https://drafts.csswg.org/mediaqueries-5/#inverted)
  2. has contrast been forcibly boosted at the pixel level without inversion (if yes, authors should do what???)
  3. Is the UA enforcing a content-aware color scheme (light-on-dark, dark-on-light...), or content-aware contrast-boosting measures other than the color scheme (think solid borders, sans-serif fonts, different styles of native components or focus hightlights)
  4. Is the UA doing nothing particular, but suggesting (based on a user preference) that the author does the sort of things described in 3
  5. Do we want to give authors a property that lets them disable UA-provided content-aware contrast boosts on a particular element, so that they can provide it themselves in a way that is more appropriate for their content? (like https://msdn.microsoft.com/en-us/library/windows/apps/hh441137.aspx)
  6. Does this interact with https://drafts.csswg.org/mediaqueries-5/#light-level, and if yes, how?
@frivoal

This comment has been minimized.

Collaborator

frivoal commented May 1, 2017

@grorg I'm curious to have your/Apple's thoughts on this.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented May 1, 2017

If the high contrast pair of foreground/background colors that a web author picks accidentally makes the background match the border, you may accidentally be making things worse.

not necessarily worse, provided that the foreground/background the author picked is high-contrast. the forced border would not show, but as that border is only there to ensure contrast (and not to make things fatter/bolder), the end result would still be a strong contrast, arguably.

but yes i can see how all this is far more nuanced than a simple true/false statement would allow for (which is likely why this hasn't been standardised until now).

@frivoal frivoal changed the title from [mediaqueries-4] high-contrast media feature to [mediaqueries-5] high-contrast media feature May 5, 2017

@alice

This comment has been minimized.

Contributor

alice commented May 25, 2017

I understand that this is supposed to be subsumed by https://drafts.csswg.org/mediaqueries-5/#light-level

However, I wonder if "high contrast" would be better as the primary concept, with light levels mapped onto the various high contrast preferences (dim -> light-on-dark, washed -> dark-on-light)?

I think that would better match the way people would tend to think about these options.

@frivoal

This comment has been minimized.

Collaborator

frivoal commented May 25, 2017

I understand that this is supposed to be subsumed by https://drafts.csswg.org/mediaqueries-5/#light-level

Maybe, maybe not. These things overlap for sure, but exactly how to sort that out is still unclear.

@alice

This comment has been minimized.

Contributor

alice commented May 26, 2017

@frivoal

Maybe, maybe not. These things overlap for sure, but exactly how to sort that out is still unclear.

Good point. I chatted offline with @minorninth about this.

Some slightly scattered thoughts:

  • light-level defines more of a "why" than a "what", and I think page authors would be more interested in "what".
  • @minorninth pointed out that there are at least three axes as to "what":
    • Inverted colors: on/off
    • Grayscale: on/off
      • Plus more subtle colour modifications like "warm light" or "daltonized", maybe?
    • Increased contrast: none vs maximum (slider)
  • And further, each of these may be:
    • controlled by the OS: the page needs to react to the "pixel level" change, or
    • expressed as a user preference: the page needs to apply the preference (e.g. "I am a hacker and I want light on dark theme for everything all the time so I can pretend to be in the matrix")
  • User preferences may ideally be browser-wide or (like text zoom) site specific and frequently changed.
  • It would also be nice to be able to configure the relationship between light level and the above factors, with some good defaults.
@frivoal

This comment has been minimized.

Collaborator

frivoal commented May 26, 2017

@alice: Thanks, a bunch of good points.

And further, each of these may be:

  • controlled by the OS (pixel level)
  • expressed as a user preference

I think there's one more:

  • Controlled by the UA, taking the markup/semantics into account
@fvsch

This comment has been minimized.

fvsch commented Mar 25, 2018

I would like to suggest a prefers-high-contrast query, set by the UA either with a dedicated preference or by inheriting the OS accessibility settings (when relevant).

My main use case would be site designs that are expected to use a brand color which has bad contrast (when contrasted with a white background or white text). Switching the brand color with a more accessible one would be more acceptable to site owners if done for users who specifically requested it.

Currently, websites with this use case either don’t address the issue, or offer in-site controls like on sncf.com:

Screenshot of accessibility controls on sncf.com

Options in this example are:

Contrast: default | stronger | inverted
Animations: enabled | disabled

@frivoal

This comment has been minimized.

Collaborator

frivoal commented Mar 26, 2018

@fvsch This issue is indeed about creating something like this, but I am not quite sure how your proposal answers the questions/concerns raised above it. The other prefers-* media queries are dealing with simpler topics, where there's just one axis, but this has multiple concepts overlapping, at it still isn't clean to me how to expose all the relevant parts in a way that is both sufficiently detail to be able to do the right thing, and sufficiently well designed that it is easy to do the right thing.

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Mar 26, 2018

agree with @frivoal here. prefers-high-contrast indicates the user's wish. the discussion here is about detecting if the environment/OS is already set to deliver a different presentation to the user (and to then possibly take that into account when defining your own styles to take THAT already into account).

i could see potential for a prefers-high-contrast, separate from this discussion here. though then there's a (small?) risk that a browser would report that the user prefers high contrast, and a site changes its styles accordingly, but that the user also has their OS already doing some adaptation for them - leading to a doubling down on contrast potentially too far the other way? (e.g. if the author used the prefers-high-contrast as an indication to load in much more contrasty photos/images, which would then be made even more contrasty by the OS)

@fvsch

This comment has been minimized.

fvsch commented Mar 26, 2018

I am not quite sure how your proposal answers the questions/concerns raised above it

I’m not answering them and I know this is not an easy topic. :) I just felt this thread lacked input from authors about common design requirements and the client-side workarounds we use today (accessibility preferences that users have to find and enable on every site).

leading to a doubling down on contrast potentially too far the other way?

If a site switches to e.g. black text on white background on prefers-high-contrast, or shows black-on-white diagrams instead of diagrams with more subtle colors, I don’t think the OS contrast rendering pass would make it worse.

It might be an issue if authors use this preference hint to add body { filter: contrast(2); } or something similarly indiscriminate.

@Wolfr

This comment has been minimized.

Wolfr commented Nov 10, 2018

Chiming in with a real-life use case from a recent design project.

If the user has set increase contrast to “checked” in their host OS:

screenshot 2018-11-10 at 15 35 45

I would like to switch the orange in my designs to a11y orange in order to pass WCAG requirements.

1

It would change this:

2

To this:

3

As an author I would like to do it with the simplest code possible:

.button {
   background: #F96830;
}

@media (prefers-high-contrast) {
    .button {
        background: #D03F06;
    }
}
@cookiecrook

This comment has been minimized.

Contributor

cookiecrook commented Nov 10, 2018

This thread might be duped out to either the original #443 or the more recent syntax discussion in issue #2943.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment