Are the disabled and readonly states relevant for SC 1.4.1?

[JAWS-test]

In the Understanding to 1.4.1, erroneous fields or required fields that are only color-coded are given as examples of violations of 1.4.1.

What about the disabled and readonly states when they are only transmitted in color. Is that ok or a violation of 1.4.1 (if contrast difference to operable elements is less than 3:1)?

I think that the difference between disabled and operable meets 2 of the 4 criteria in SC 1.4.1.:

• conveying information
• prompting a response

However, this seems to be controversial and that is why I would seek clarification. @alastc (https://github.com/w3c/wcag/issues/1781#issuecomment-839260059) wrote e.g.

I'm not convinced that WCAG requires you to differentiate a disabled button visually.

[mbgower]

Inactive

@JAWS-test I'd say it's an oversight that Use of Color does not contain exception language for disabled controls similar to Contrast (Minimum) and Non-text Contrast:

Except for the following...Text or images of text that are part of an inactive user interface component

There is clearly an established exception throughout WCAG that inactive (AKA disabled) controls are exempt from this kind of requirement.

Read only

That exception does not apply to read-only, however. Read-only controls are navigable and part of the UI in a way that inactive controls are not. The text of read-only controls needs to meet text contrast. To me, it's also clear that the indicators of read-only state would need to meet 3:1 for non-text contrast.

That said, understand that there are not a lot of established conventions for visual cues for read-only controls. For example, the only difference between a pure HTML input and a read-only input is that the cursor does not flash when you reach. Otherwise, for most browsers, they look identical. Some designers at IBM have been working on establishing a way to visually distinguish read-only from both operable and inactive controls for the opensource Carbon design system. It's been a fairly involved process because there are some tricky considerations.

Chromatic color

What about the disabled and readonly states when they are only transmitted in color

In regard to use of colour, a better way to describe it would be chromatic colour. Black, white and grey can be used for judging contrast, but are not considered colours in the chromatic sense.

@patrickhlauke do you think it is worth making a PR for Use of Color for both the inactive exception and making chromatic color the clear guideline?

[JAWS-test]

I don't think disabled controls should be exempt at 1.4.1. With them it is even more important than with readonly to recognize that they are not operable. I.e. disabled does not need sufficient contrast to the background (according to SC 1.4.3), but if operable and disabeld controls differ only slightly (e.g. contrast of 1.5:1), I think it is a problem according to 1.4.1.

[mbgower]

I don't think disabled controls should be exempt at 1.4.1.

I think we'd have to look at some examples. I can't think of controls that use chromatic colour when active except links--and since links cannot be disabled in straight HTML, I'm not sure this is a valid use case to consider. The whole point of excluding inactive controls from contrast is because they are by convention 'greyed out'. So we wouldn't want to fail someone for greying out an inactive link on the basis that the active control had color and the inactive one doesn't (again, understand that grey is not intended as a colour in this context).

but if operable and disabled controls differ only slightly (e.g. contrast of 1.5:1), I think it is a problem according to 1.4.1.

I think you're chasing the wrong line of thinking here. The challenge isn't a lack of contrast difference (which is exempt). The challenge is what visual cues in read-only controls do have sufficient contrast, and how do they differ from the active and operable control, as well as from the inactive (and low contrast) versions.

To state another way, this is a design problem. You can't solve this entirely by accessibility standards; but the correct accessibility considerations can help a design reach an improved way of communicating 'read-only' to all users. But I'd still need to see some examples of how you think it would be useful to apply Use of Color to inactive controls. My gut says they should have been (and were intended to be) excluded.

[mbgower]

So thinking for a second, buttons would be an example. Some (many?) buttons use color when active, and then they are 'greyed out' if inactive. But obviously a designer wants it to be clear when a button is active and when it's not. I think we have to acknowledge that if no one can tell the difference between an active and inactive button, this is a problem for everyone, and therefore not an accessibility issue per se. So the question becomes, does Use of Color alone come to bear in a disabled button situation so that users with disabilities are disadvantaged? I suspect no, because the contrast between a color and greyed out button is going to likely be sufficient. But if it isn't -- if the active and inactive button have a low contrast difference, then I think you could say that could add undue burden on some users with disabilities and so may be a candidate for failing use of color. But I'd want to see a lot of data to support this and ensure we're not making it worse applying an absence of colour as an assessment for Use of Color. AFAIK, it's gone on many years without this become a large point of discussion, so I suspect you'd be looking at a very small subset. Feel free to do some digging, if you like.

[mbgower]

@JAWS-test An example for you from Github. Here's what a Comment button looks like when it is inactive (no text in comment yet) The pale green of the button background is 1.7:1 against the white letters of "Comment" and white background.

Here's the same set of buttons, with Comment now active The green background is 3.2:1 against the letters and background.

So, first off, the active button will only be passing text contrast if the button letters are bold and 14 pt. Can't be bothered to dig for the CSS, so giving them the benefit of the doubt for now...

There's only a 1.9:1 contrast between the active and inactive button. Current practice is that the inactive control is effectively ignored from all considerations for visibility.

I think you are arguing that those should fail Use of Color.

If we applied that, the options would then be for the user either to strip out colour entirely on the inactive button (assuming you agree with the non-chromatic colour position on Use of Color) or go with a much darker green so that the disabled button would achieve 3:1 against the active button. That would have massive ramifications across the web.

If we were going to advance that, I think you'd need to do some significant research to confirm that the contrast threshold for active controls, when applied as a contrast requirement between active and inactive controls, provides marked user benefit. It's a significant change in application of contrast considerations that you're advancing!

[JAWS-test]

But obviously a designer wants it to be clear when a button is active and when it's not. I think we have to acknowledge that if no one can tell the difference between an active and inactive button, this is a problem for everyone, and therefore not an accessibility issue per se.

If the buttons (whether operable or disabled) are the same color, then of course this is true. But if they differ (e.g. disabled = red, operable = green OR disabled = light green, operable = green), then it is a problem for people who cannot distinguish colors or do not perceive small contrast distances (either without AT or with AT, e.g. a screen magnifier that displays colors with small contrast distances with the same color).

I don't understand why, according to 1.4.1, incorrect fields or required fields may not be marked exclusively with color, but deactivated or readonly elements may be

[mbgower]

@JAWS-test said

I don't understand why, according to 1.4.1, incorrect fields or required fields may not be marked exclusively with color, but deactivated or readonly elements may be

First, I have been clear that read-only elements do need to meet Use of Color, for instance:

That exception does not apply to read-only, however. Read-only controls are navigable and part of the UI in a way that inactive controls are not.

Second, it is my opinion that Use of Color shouldn't apply to inactive controls, but as i noted in my first comment, there is no exception listed for this. i think this needs to be examined and discussed, then acted on to clarify the requirement.

Thinking it over, I don't even think an explicit exception is needed, but it wouldn't hurt. Here's why I don't think it's needed... As long as a control has some difference in contrast between its active and inactive states, it is not relying solely on color to represent the states, right? For active controls, that contrast difference has to be 3:1 in order to be considered an acceptable way. But since there is no minimum contrast by which the inactive components need to differ, any contrast difference is sufficient.

it is a problem for people who cannot distinguish colors or do not perceive small contrast

The point I was trying to make is that there IS no contrast requirement between enabled and inactive components. Maybe I'm not being clear enough here. Remove any consideration of chromatic color. Think of a gray button. If that button is 3:1 against the page background when active and it is still visible but 'greyed out' when inactive, then obviously it is not going to be 3:1 against the original gray button. Say in that scenario, the inactive state is 1.5:1 against the active state. That passes WCAG fine, because the disabled state is just ignored (both for text and non-text contrast). It would be a little odd for us to say that the same button using green and pale green, also achieving 1.5:1 against the active green, would fail. From the perspective of relative luminence, they are the same.

[JAWS-test]

As long as a control has some difference in contrast between its active and inactive states, it is not relying solely on color to represent the states, right?

No, see note 2 in the Understanding:

If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction, as long as the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater.

[mbgower]

If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction, as long as the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater.

Yes, but that is applying the criteria of active components against an inactive component, which is not required to meet contrast. That is the nub of my problem with this whole discussion. If the contrast has been dropped down below required thresholds, as in the green button example, the loss of contrast is the cue the component is inactive. The use of colour is not germane. Here is those same buttons at grey scale:

Those variations in grey buttons pass Use of Color and contrast minimums due to the inactive exception (ignoring for now the question of whether this is actually 14pt bold). A user who cannot perceive color experiences exactly the same relative luminance as anyone else. You may argue there is insufficient contrast for a user to tell them apart, but that is what has been established for inactive controls. Thinking of these with the color back in, the color isn't changing from green to red. It's just a reduction in the luminance of the green. I do not believe it was intended to create a duality of failure here.

I agree that intent should be clarified in the requirements. I also think specific language to say inactive controls MUST be below 3:1 is something to consider (although realize there is a line of thinking that questions the inactive exception in the first place).

Rereading one of your last comments, I think you may be considering a situation where an inactive control maintains minimum contrast? In other words, instead of 'greying it out' a designer has decided to use, say, a red that appears to be active (i.e., is more than 3:1 against the page background) to designate inactive?

If so, I would say that that is a scenario not even considered by the authors of WCAG 2, because it would violate every established convention of digital design that has existed from several decades.

In any event, this two-way discussion has likely gone on long enough. I'll step away from it and let others add comments.

[JAWS-test]

Rereading https://github.com/w3c/wcag/issues/2308#issuecomment-1102872712, I think you may be considering a situation where an inactive control maintains minimum contrast? In other words, instead of 'greying it out' a designer has decided to use, say, a red that appears to be active (i.e., is more than 3:1 against the page background) to designate inactive?

Yes, I am concerned with cases where the disabled element has sufficient contrasts (which is not forbidden) or no sufficient contrasts (which is allowed). But in both cases a disabled element should be sufficiently distinguishable from an operable one, i.e. with at least 3:1 contrast or other visual characteristics. Even if there is no contrast requirement for disabled elements, there should at least be a requirement that I can tell that it is disabled. This is a status that is relevant in 1.4.1 and 1.4.11.

Also, the question remains regarding readonly. Are the browsers doing it wrong that the status is not detectable?

[brothercake]

If the use of grayed-out or dimmed appearance is considered insufficient in terms of 1.4.1, then what else can authors reasonably do to visually denote the appearance of a disabled control?

There are no other conventions. Explicit text like "(disabled)" could be used, but nobody's going to want to do that. An icon could be used, but there is no already-recognizable icon that means a control is inactive, as far as I'm aware.

I would say that it's not reasonable to expect disabled controls to meet 1.4.1, and given that 1.4.3 and 1.4.11 already codify this as an exception, then 1.4.1 should do the same thing.

[JAWS-test]

If the use of grayed-out or dimmed appearance is considered insufficient in terms of 1.4.1, then what else can authors reasonably do to visually denote the appearance of a disabled control?

I think: grayed-out or dimmed is not considered insufficient if the contrast to the operable controls is enough.

I am more concerned with the situation when the disabled controls are not sufficiently grayed out and thus cannot be distinguished

[brothercake]

grayed-out or dimmed is not considered insufficient if the contrast to the operable controls is enough

I'm not sure that's necessarily applicable though. If a page form only has one button, like a disabled submit button (putting aside that that's bad practice), then there's no other enabled button to compare it with, unless that state change occurs dynamically. You could compare enabled and disabled buttons within the same design scheme, but isn't that difference moot if they don't appear simultaneously?

I am more concerned with the situation when the disabled controls are not sufficiently grayed out and thus cannot be distinguished

I agree that's a concern, the question -- is the visual presentation of an element sufficient to convey its disabled state. But mandating that in terms of contrast difference still requires the simultaneous or sessionally-consecutive presence of both active and inactive controls of the same type, doesn't it?

But if not, if contrast is a reasonable distinction to make in either case, wouldn't that fall under 1.4.11 and imply that the disabled control exception shouldn't exist in that SC?

[JAWS-test]

If a page form only has one button, like a disabled submit button

Even if there is only one button, it is important to recognize that its status has changed and that, for example, I can now finally submit the form

But if not, if contrast is a reasonable distinction to make in either case, wouldn't that fall under 1.4.11 and imply that the disabled control exception shouldn't exist in that SC?

1.4.11 is about adjacent colors, i.e. contrast to the background (which can be sufficient and does not have to be sufficient with disabled controls), 1.4.1 is about being able to see differences between elements that do not have to touch each other, i.e. not contrast to the background, but between the button that is disabled and the button that is not disabled

[Myndex]

Hi Mike @mbgower

...In regard to use of colour, a better way to describe it would be chromatic colour. Black, white and grey can be used for judging contrast, but are not considered colours in the chromatic sense...

Yes, I agree.

It is important to recognize that the human vision system (HVS) makes a distinction between the luminance channel (lightness/darkness, without regard to hue) and the color channels (hue, meaning unique dominant wavelength, and colorfulness i.e. chroma/saturation).

Luminance and color are separated in the HVS, serve different cognitive roles, and should be separated in accessibility guidelines in general.

Click for "Color and Luminance are Separate" ⇦ ⇦

**The HVS:** - HVS senses visible light in three overlapping bands (LMS), and the opponent color process takes the LMS cone signals (red green blue) and converts to three axes: - A single axis of light to dark (luminance) which contains the majority of spatial information such as edges & fine details, and intensity information (distance from 0). - Two Axes of color, a red to green (a±) and a yellow to blue (b±), intersecting at grey. These hold very little spatial information, but includes intensity and discrimination information (a vector of magnitude and direction) and is _somewhat_ independent from luminance. - therefore HVS has a **lightness magnitude**, and a **colorfulness magnitude** with a **hue direction**, providing four unique colors (red yellow green violet) to which we can add an additional 3 to 4 _easy_ to distinguish color combos (orange cyan purple/magenta) and many variations. - Most CVD (color vision deficiency) have a problem with **hue direction**, but nothing else. Protan's lightness magnitude is substantially affected in reds and red related colors. Otherwise, CVD's sense of lightness magnitude and contrast is equal or better to standard vision (colorfulness magnitude may be as well, in some studies dichromates having greater saturation sensation). - HVS processes luminance and color _**separately**_ and in different regions $(Vn)$ of the visual cortex. - $V1$ processes luminance which contains nearly all the spatial details (edges, fine details) and is principally responsible for our contrast perception (lightness / darkness / brightness). $V1$ processing is dependent on spatial frequency as input stimuli effectively passes through multiple bandpass filters. - About 70ms+ later, $V4,V8a$ process color, distinguishing different wavelengths of light as hue, and the intensity of a dominant wavelength relative to the adapted white/grey as a colorfulness aka saturation. - Luminance and color are separate and are each used differently in later, higher level stages in the HVS and beyond. - For instance, the pre-lexical VWFA (visual word form area) which recognizes letter pairs or whole words, and the subsequent language processing, appears to rely on the 0.2°-2.0° visual angle bandpass luminance channel. Color (hue) is not part of this. - Color, as in hue/chroma on the other hand is used in _other_ areas, such as object recognition for distinguishing, such as between a green orange and a ripe orange.

In Short

Luminance is good for detail and contrast, but less effective for coding information. (FAA limits luminance coding to three levels). In WCAG 2, luminance specs are related to 1.4.3 contrast—but not 1.4.1, color.

As defined, color is bad for detail and contrast, but good for coding information—except that those with CVD may have issues understanding pure-color coding, which is the entire (and only) purpose of 1.4.1.

@mbgower said:

...But obviously a designer wants it to be clear when a button is active and when it's not. I think we have to acknowledge that if no one can tell the difference between an active and inactive button, this is a problem for everyone, and therefore not an accessibility issue per se....

Quick Tangent:

Interjecting a more personal opinion here: accessibility is for everyone. Something that is difficult for everyone to operate is most definitely still an accessibility issue. Now, whether or not it's "in scope" for WCAG 2.x is a separate matter. I mention this as I definitely consider it in scope for WCAG 3 and other standards.

.

---

@JAWS-test said:

...I don't think disabled controls should be exempt at 1.4.1...

Disagree

Click for the rest of my several replies to JAWS-test ⇦ ⇦

There's no basis to include disabled controls in 1.4.1. Reducing the contrast of a disabled control is **not a use of color**, it **_is a use of contrast_**. 1.4.1 is specific to the issue of **distinguishable hue**, and secondarily colorfulness (saturation/purity). There are other SCs that cover the functions of luminance. **Click the earlier twisty for details for why this is the case in the human vision system.** - - - @JAWS-test said: > ..._Yes, I am concerned with cases where the disabled element has sufficient contrasts (which is not forbidden) or no sufficient contrasts (which is allowed)_.... #### _Quick Tangent:_ As a tangent, APCA Readability Criterion provides for minimum contrast values for disabled controls, placeholder text etc. And again, what is being discussed in this thread is actually a _**change in contrast**_, not a change in color. Defining an SC that codifies minimum parameters for meta states would be OK, but not for WCAG2 because if you want to make that kind of fine distinction, you need reasonable perceptual uniformity in your methodology. Not to mention that having some actual science to back up statements regarding meta-states would be helpful, as meta-state distinction is a very different process than reading text. - - - @JAWS-test said: > ..._But in both cases a disabled element should be sufficiently distinguishable from an operable one, i.e. with at least 3:1 contrast or other visual characteristics_... #### _I really wish people would stop bringing up 3:1 contrast as if it was some miracle magical number, because it isn't._ It has little relevance today, and is particularly irrelevant without the use of a perceptually uniform method due to the proliferation of multiple color schemes including dark mode, light mode, high contrast, daltonized, and so forth. While we know the flawed WCAG 2.x contrast is the current thorn, it would be good if there was an **all stop** as far as promoting 3:1 as if it was meaningful. This concern incidentally extends far beyond web content and WCAG2, and misunderstanding of contrast perception and luminance is also a persistent problem in other contexts such as architectural signage.[(Arditi 2017)](https://jov.arvojournals.org/article.aspx?articleid=2628138) - - - @JAWS-test said: > ..._1.4.11 is about adjacent colors_,... #### _1.4.11 is About Pseudoscience_ 1.4.11 being one of the more flawed SCs as it lacks scientific support and fully ignores the principal driver of contrast, that being spatial characteristics of the element. Of all the contrast SCs, the one that arguably _needs to consider spatial characteristics the most_ would be the one talking about non-text elements, which have the largest range of spatial characteristics. - - - @JAWS-test said: > ..._1.4.1 is about being able to see differences between elements that do not have to touch each other_... #### _1.4.1 Hue Are You_ 1.4.1 is about distinguishing and understanding information without relying on hue.

---

Hi James @brothercake said:

...I would say that it's not reasonable to expect disabled controls to meet 1.4.1, and given that 1.4.3 and 1.4.11 already codify this as an exception, then 1.4.1 should do the same thing....

+1 I Agree

It is not at all reasonable, nor does it necessarily confer a functional need to be addressed. Meta states are somewhat complicated and nuanced, if anything they would deserve their own SC, though I don't think that WCAG2 is the right place.

@brothercake said:

...But mandating that in terms of contrast difference still requires the simultaneous or sessionally-consecutive presence of both active and inactive controls of the same type, doesn't it?...

YES EXACTLY

One problem with simply using contrast as a meta-state, is that a user unfamiliar with the interface may need a comparative example. A second issue is if the meaning or label of the disabled control is something that should be understood. Example is the understanding that is provided by knowing a form is not ready to submit, because the submit button is grayed out, etc.

Like everything else in visual perception, meta-states are extraordinarily context sensitive, and that makes trying to stick meta-state requirements into a normative (shall) SC not only difficult but potentially problematic, with unintended consequences.

And on that note, if this were to be placed someplace other than its own SC, the SC that it should be going into would be something like 2.4.13 -- while that's specifically about focus appearance, the focus related SCs could arguably be more about meta-states in general, than just focus.

---

Thank you for reading

[CharlesBelov]

I do read 1.4.1 as requiring some other visible indication in addition to color to designate that a field or button is not active, and I do feel that is appropriate even if website designers might be annoyed by it. If someone cannot distinguish between the colors, and is going to be physically challenged by content that they have to work to see, then how are they going to know that is something they can't do at the moment but might be able to do when prerequisites are met?

I would expect that other visible indication to meet 1.4.3.

Indication does not necessarily have to be in words such as "(inactive)". For a button it could be as simple as a dashed, contrast-meeting, border where active buttons have a solid border. Words would be more appropriate for text such as instructions accompanying a checkbox.

I'll note that faded text which doesn't meet contrast causes both vision and cognition issues for me, as it is both hard to read and distracting. That the gray-ness causes me to spend more attention on it is probably opposite of what the designer intended.