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 (#1781 (comment)) 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 #2308 (comment), 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?