Thank you for commenting. For more information about how the AG WG will process this issue, see the following:

• Issue Processing - How the WG will discuss the issue
• Issue Resolution - Identifying and responding to the official WG response
• Issue Notification - How to limit notifications from GitHub

@timothywhalin The Working Group has considered this question in #745 and #617 so it would be great if you took a look at those.

I'm not answering for the group but I do think that this has been discussed quite a bit and I suspect that it isn't likely to change, but may be a good candidate for Silver.

For your examples, a few comments:

1. I agree that this isn't the best experience as portrayed, but I think that users should know whether they are signing in or creating a new account using more than just the label on the final submit button. Expecting users to look to the end of a process to understand the process at the start seems like a usability failing.
2. Attachment?
3. This example is a good one in that the information isn't otherwise available. The WG has discussed that there are scenarios where text on inactive UI components is useful/needed and that there is a gap in WCAG 2.0 (and in the CR 2.1). Given the feedback that the WG has received about needing the exception for inactive controls I suspect that this will require a broader solution.

Thank you for sharing the other two tickets for context and I have read both. Could you clarify what a "Silver" is?

My apologies for missing the attachment. Here's the Pinterest example I referenced in #2:

For #1: I agree with the idea that there should be other page context to inform the user about what form they are filling out, but this isn't guaranteed. Both a sign in form and a register form would require a username/email and a password field. In many cases, there should be other context clues (heading, forgot password, etc) but shouldn't the guidelines consider that the contrast should be agnostic of following other basic usability practices. Here is an example of the similarities in the form...

Here is another visual for an inactive UI component that is useful for a stepper for #3:

My meta-point that isn't raised in the other concerns it that inactive information is communicating to the user. If a user needs to know that something is inactive (which is why it's still somewhat visible in the interface), then the contrast should be strong enough for anyone to read it and understand what is disabled.

Here is an example from Amazon product selection where you can choose to the size and color:

Now, I am guessing this is a good example of one that doesn't meet the qualifications of an inactive component and here you can see a disabled state meeting the minimum contrast without sacrificing usability. If an element is on the screen, its communicating to the user its state and someone should have the ability to read that element.

@timothywhalin Thanks for the extra info. Silver is the next generation guidelines that we are working on in a dedicated Task Force within the WG. WCAG 2.1 is designed to be backward compatible but Silver is where we are allowing ourselves to rethink everything.

Hi @timothywhalin personally I agree with you. I haven't look at detail but it sounds like you have two situations

1. something is active but has a state of unchecked, not selected, etc. I'd argue that this is not the same as disabled and is already covered by the 2.0 standards.
2. Truly disabled items may have value to help you know that you have not done something that will then make that item enabled. This is something that I'd like to address and it's something I pushed for but did not make it in to the updates. It's something we will have to tackle later unfortunately. it is complicated to address this issue and may require other visual indicators such as an icon/formatting because contrast is an important cue. It's better that we get something right then introduce a requirement that the community won't accept and therefore will reject WCAG 2.1 because of that.

Actually it gets worse. I think I'm right in saying that some screen readers do not even announce disabled fields! Though that is more of a user agent problem rather than a developer issue.

Proposed AG Response. DRAFT
Thank you for your comments and suggestions.

Due to the different needs and preferences of low vision users and cognitive users, the contrast requirements for inactive user interface components (also known as disabled interactive elements) is recommended for inclusion in Silver. The WCAG 2.1 Low Vision Task Force has recommended that Silver consider adding something like an ARIA-status of "disabled" so automated testing tools can ignore these elements.

- Low-vision - some users want to ignore the disabled elements, just focusing on the enabled elements. If we force stronger contrast on the disabled elements, it will be difficult for all sighted people to distinguish between what is active (and what is disabled). Other low vision users want to see the disabled items clearly. So...we do not have a one size fits all solution.
- Cognitive - some people with cognitive differences really want to be able to focus on the active elements (and ignore the non-active elements). If we force stronger contrast on the disabled elements, it will be difficult for all sighted people to distinguish between what is active (and what is disabled).

A personalization solution to consider for Silver is to make it a preference to "enhance color contrast for Low Vision AND/OR add a symbol for "disabled interactive elements".

So, we acknowledge this need and have concluded that the best solution will be found in personalization in Silver.

Action 1: Defer to Silver
Action 2: Changes made to Understanding Non-Text Content (needs Call For Consensus CFC from WCAG Working Group). See Pull Request files at https://github.com/w3c/wcag21/pull/776/files

Hi @goodwitch: Thanks for the proposal. I'm not sure I agree and perhaps I'm not understanding what you mean about personalization. I would love to discuss this further. There are a few assumptions in the text above that I'm not sure are good assumptions to make:

1. "Some users want to ignore the disabled elements". As a designer, I am not sure of a use case where you need a user to ignore an element if it needs to be on the screen. If it can be ignored, why shouldn't this element be removed? If it is to be visible in any contrast, its there to communicate that its disabled and therefore a user should understand what is disabled. In this case, these elements aren't meant to be ignored but are meant to be less of the focus of the screen than the non-disabled elements. In the examples above, the disabled states are communicating something to the user. And this is a case I have found in most instances of a disabled state. Can you please share examples where the element isn't communicating anything but can't be removed?
2. "it will be difficult for all sighted people to distinguish between what is active (and what is disabled)". This seems like a design problem but is solvable. You can see the screenshot I shared above that meets minimum contrast in the Amazon app for disabled elements. In this case, the dashed lines along with the lighter gray text communicate disabled.
3. "So...we do not have a one size fits all solution." My suggestion would be to consider providing a minimum contrast guideline, even if its lower than standard AAA or AA guidelines. The example above from Pinterest is 1.4:1. Providing a minimum even on disabled states would help avoid this.

I tend to agree with @timothywhalin; disabled elements are not good design practice in general, because of various accessibility concerns, I would like to see solutions evolve to consider not using them. If a designer has deemed it important that they are included on an interface, they are important enough that ALL users should be able to glean important information from them. It is possible to design disabled states that meet accessibility requirements; icons, using low or no fill colors, etc. It may take a designer looking back at their primary enabled states and ensuring the meet contrast guidelines, but is something worth our consideration.

I agree with all the others above who are challenging the disabled fields part of this SC (that's several people now). Disabled fields are visible to some, so they should be visible to all.

Some users don't want to see various kinds of content. Ads, for instance, and carousels and animations, and explanations for newbies that more experienced people don't need. But we don't say hide those things from certain groups of disabled people. We just say show them in a mannner that helps all users. It should be the same for disabled fields.

I sometimes audit websites where disabled fields aren't announced by screen readers so blind people won't know they are there. I always feel I ought to be failing them, but there currently isn't anything in the WCAG to fail them under!

And I don't think "personalisation" is the answer. There is danger of personalisation become a sort of "cure all" for all manner of sins. The average person doesn't have time to go looking through all their settings to see if there is a way they can stop something they don't like; and some users aren't sufficiently computer literate to know what they can adjust that way. The problem with personalisation is that if you stop something because it is annoying on one website, then it is stopped on all websites - or are you going to ask people to keep all kinds of personalisations for different websites? The correct answer is to do it right in the first place, and in the case of disabled fields simple solutions are available.

My concern is the likely impact on designs, it is fairly easy to get into a situation where a disabled element would appear active.

You can see the screenshot I shared above that meets minimum contrast in the Amazon app for disabled elements. In this case, the dashed lines along with the lighter gray text communicate disabled.

If they were not disabled they would fail 1.4.11 as the grey / white is around 1.8:1, as is the solid line on the boxes underneath that. (NB: I don't think they are disabled, they are just not currently selected?)

We've discussed this one quite a lot, and the aspect that stopped it (for me) was that making disabled controls have sufficient (generally similar) contrast as other controls creates usability issues for many people.
There are other cues that can be used, but having a relatively low-contrast control is well understood. Ignoring that convention leads to people thinking the interface is broken as they try to use the controls.

We didn't have enough good examples of other methods to be sure that it would be implementable on any website.

I don't think it would controversial to recommend good contrast for disabled controls in the understanding document, but without a method of personalisation (so you can increase the contrast for yourself), I don't think it is viable to change the SC requirement.

Let me try to reframe my feedback into a question because I don't think I'm communicating it quite well. The question is: When is a disabled element not communicating something to a user but cannot be removed entirely?

My hypothesis is that the purpose of an element being disabled is to communicate to the user: 1) something is disabled, and 2) the specifics of that disabled element. If the disabled element is not intended to communicate anything, then it should be removed. I believe if any user should read the element to understand what it's doing, they should be able to do so.

One alternative I'll suggest is to provide some minimum to color contrast for any text (disabled or otherwise). As it stands today, disabled elements have no guidance on readability from WCAG and this is where you get awful usability in the case of the Pinterest screenshot above.

When is a disabled element not communicating something to a user but cannot be removed entirely?

When you need to know there is something there, but it isn't ready yet. If the button were removed entirely, it would often cause layout issues (as other stuff gets moved around when it appears), or lead you to think there is no next step.

To turn the question around, what is the usable version of the sign-up form or steps examples above?

(I'm channeling the reasonable arguments I get from design & UX folk.) If they were given sufficient contrast they wouldn't fulfill their purpose. I.e. if step 5 had sufficient contrast, it wouldn't look different enough from steps 1-4, and wouldn't convey that step was not done yet.

I don't think anyone is saying that the low contrast on disabled controls doesn't cause issues, but that there are not reasonable solutions for that issue.
We could spit-ball solutions to individual cases (and we have previously!), but there wasn't a solid, widely recognized solution that could be recommended as an alternative.

I don't think anyone is saying that the low contrast on disabled controls doesn't cause issues, but that there are not reasonable solutions for that issue.

I agree! The proper solution may need to come from new design convention. If we can get enough people to adopt that design pattern, maybe it can become best practice.

[Official WG Response]
Thank you for your comments and suggestions.

This issue is complex and we do not have consensus on a solution at this time, even deciding on a lower contrast ratio for inactive controls requires more information and time. In addition, this issue also impacts WCAG 2.0 SC 1.4.3 and 1.4.6, and making a change for 1.4.11 would impact these SC and impact the backward compatibility requirement of WCAG 2.1.

As a result, the WG will take the following actions:

• Action 1: Defer to Silver
• Action 2: Changes made to Understanding Non-Text Content (needs Call For Consensus CFC from WCAG Working Group). See Pull Request files at https://github.com/w3c/wcag21/pull/776/files

Sorry for my delay as I've been traveling.

When you need to know there is something there, but it isn't ready yet.

I think this is the point I'm trying to make: Someone needs to know its there AND therefore be able to read what is there.

To turn the question around, what is the usable version of the sign-up form or steps examples above?

To answer this, I can give usable versions of each of the examples I've given so far. For the Sign in/Sign Up form I provided, I would make the buttons active. Upon tapping on the button without a correctly filled in form, I would provide a message to the user of the right way to complete the form. In this case, the high contrast helps inform the user what they will submit the form with and gives the opportunity to educate them if they fill it out incorrectly (versus leaving it disabled until filled in correctly). This not only improves the contrast but also provides a more usable form. In most cases, the requirement to meet minimum contrast regardless elements are disabled or not will actually increase usability and force designers to think more critically about their work. This is the same theme I give whenever I teach about accessibility: accessibility makes you a better designer because it makes many passive decisions become active, thoughtful decisions.

Here's how I would correct the pinterest example above:

Here's how I would correct the stepper image, which still communicates its not the step you are on through multiple visual cues:

Here's the case from a co-worker of mine who needs this section of WCAG to be reconsidered:

I might be a good test case. The vision in my left eye has been getting progressively worse recently, because of damage to the retina. And I have mild (stage 1) cataracts. While I have no trouble at all reading text that has appropriate contrast, reading low contrast text is hard. If I have to do it for very long (e.g., having a conversation with someone in a tool with low contrast), my left eye begins to hurt.
But even just a label on a disabled control will irritate me. I have to make an effort to read it, and I don’t want to. But I need to know what it is, and why it’s there, so I make the effort. Usually. But I’d rather not. It doesn’t make for a delightful experience.

Hi @timothywhalin,

For the Sign in/Sign Up form I provided, I would make the buttons active. Upon tapping on the button without a correctly filled in form, I would provide a message to the user of the right way to complete the form.

In which case it is adding another step, and in usability testing I've seen people get annoyed by this approach. Why proceed when it's wrong? (This does assume error messages are dynamic.)

Here's how I would correct the pinterest example above:

I had to put that side by side to see the difference, I think it's just removing the grey background on the 'Tap at least...' button?

NB: The grey text on white is around 2.4:1, so doesn't meet text contrast (but that's easily fixed).

As it has lost the button outline you're taking that example out of scope of this SC anyway. From a usability standpoint I think people could argue that it helps to know where the 'next' button is going to be, and indicate it is not ready yet.

In that particular case I think having a message rather than a button is reasonable. However, there are other cases where having a disabled button is necessary.

I like the advice Gov.uk provide for this (and they do a lot of testing):
https://govuk-elements.herokuapp.com/buttons/#button-disabled

I.e. don't if you can help it, but if you need to, here's the best way.

Unfortunately that approach isn't available to us in WCAG 2.x.

Here's how I would correct the stepper image

Sorry, I'm struggling to tell the difference, is the text slightly darker? The text isn't covered by this SC, and we can't adjust WCAG 2.0 SCs.

Here's the case from a co-worker of mine...

Most of the low vision task force have low vision (including Wayne who commented above) and have similar views. No one is arguing that it is not an issue, the problem is solutions.

Thanks @alastc, I appreciate the ongoing discussion and I think I've exhausted my cases for an argument to change this

I do believe in each of these cases, the requirement to have a higher contrast text forces designers to rethink their use of a disabled state and how to communicate information to a user. In the case of both pinterest and the stepper image, I updated the text color to meet 4.5:1 (not sure if it appeared correctly for how Github resized them) and I don't know if we could assume some usability issues without more thorough testing.

In any case, I'll agree to disagree here. I'm currently advocating our teams reconsider moving away from disabled states or use a minimum contrast on all text as a starting place here, but was hoping we could consider carrying that guideline more broadly. I'll look forward to the considerations in the updated Silver guidelines.

@timothywhalin thanks for your pursuit of this. If it's any consolation, this has been an ongoing discussion amongst designers at IBM for some time (as it has with many folks involved in the working group). The issue of low-contrast disabled controls not being perceivable to all is understood; a technical means to resolve the issue in a way that can gain traction could not be incorporated satisfactorially into this iteration of WCAG.

There can be significant usability value built into the convention of disabled controls having lower contrast -- if you can see them! I suspect the approach of bringing in a disabled attribute will likely be the most graceful solution to allow everyone to realize the benefit delivered by the existence of visible disabled components. In combination with personalization, that should allow many to derive the benefit while eliminating the conflict of interests, much as aria provided an ability to retrofit the needs of some users without modifying the default presentation of a page for others.

The WG decided on the above response, so we changed the text in the comment containing the proposed response to read "[Official WG Response]". Please confirm is you are satisfied with the response within 3 days. If we haven't heard a response by then we will regard the resolution as satisfactory.

Leaving open for Issue 776 regarding understanding changes

Referencing #782 for actioning.

Please note we have specific issues setup iterative updates to the understanding documents, this issue is not lost, but will be tracked on that issue.