48

Very related to this question: Accessible Disabled State but that is about how to style disabled buttons to make them accessibility compliant, but my question is slightly different.

Is it actually an accessibility requirement for disabled features to be contrast compliant?

You are not hiding functionality from visually impaired people by making it grey on grey because the feature is unavailable to everyone, so they are not missing out on features because of this. Yes, it's always better for everything to be contrast compliant, but that might not be relevant here.

The situation is this - we have to disable features of our web application when the system is undergoing scheduled maintenance. Therefore we don't want to remove the buttons altogether because we want the user to know that the feature is only temporarily unavailable. Additional messaging is provided on the page stating that some features are unavailable.

We designed a standard inactive state button (dark grey text on lighter grey button background) but it has come back to us with the concern that it may be failing DDA compliance. However I disagree with that concern for the reasons I state above. Am I mistaken, or is it OK to have grey-on-grey buttons for such situations?

Note: I'm not looking for any alternative solutions (leave that to the linked questions) my query is specifically about whether or not this is an accessibility concern.

Improve this question
11
  • 2
    @RogerAttrill there is still messaging on the screen to give feedback to users of this. I am concerned that we may end up with a button that isn't so clearly disabled just so that it passes DDA / WCAG, but to the detriment of the majority of users (sighted ones) who will be less able to clearly tell that the feature is unavailable.
    – JonW ♦
    Jul 2, 2015 at 10:47
  • 3
    Disabled Buttons contain information and thus should be accessible
    – BlueWizard
    Jul 2, 2015 at 16:56
  • 1
    @JonasDralle: In many cases, the primary purpose of showing disabled buttons rather than hiding them altogether is not to convey information, but to visually reserve space. The fact that the space does not contain a usable button is generally more important than the nature of the active button that it sometimes (but not presently) contains.
    – supercat
    Jul 2, 2015 at 22:00
  • 1
    I know some lists who hide their entries if they're not available. Let's consider I'm using Photoshop and I'm opening one of the upper Menus. What happens when they would hide the disabled entries? First of all the list would be shorter, which is a bad thing because I know what List entry I want and I know where it usually is. Second of all I Know what entry I want bit when I somehow got anything activated that blocks it It's impossinle for me to find the Information that it's disabled.... (1/2)
    – BlueWizard
    Jul 3, 2015 at 4:01
  • 2
    axesslab.com/disabled-buttons-suck. Unreadable disabled buttons suck twice.
    – maaartinus
    Feb 16, 2020 at 4:21

5 Answers 5

Reset to default
61

No, it would seem not, as W3C states

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

  • Logotypes: Text that is part of a logo or brand name has no contrast requirement.

My emboldening

Improve this answer
5
  • Ah bingo! Not sure how I missed that in the WCAG guidelines, but it does support my opinion, so I'm happy!
    – JonW ♦
    Jul 2, 2015 at 10:50
  • 2
    Would this exception include text on inactive tab buttons/links? By inactive I only mean not currently selected (perhaps there's a less ambiguous term here). I'm assuming this would not, since these tabs are still clickable, and are functioning navigation. I'm referring to these kind of tabs: codepen.io/VoloshchenkoAl/pen/dMWxoL
    – jbyrd
    Apr 9, 2019 at 20:18
  • 1
    @jbyrd This exception wouldn't include unselected tabs - those tabs are still an active part of the ui, even if not currently selected, and so would still need to have suitable contrast. Think of the items of a tab header as essentially being radio buttons that happen to trigger a change in content within an attached area. And all active radio buttons (whether selected or unselected) still need to comply.
    – Roger Attrill
    Apr 9, 2019 at 22:10
  • 2
    Unfortunately the spec doesn't define "inactive". It's not clear whether "inactive" is synonymous with "disabled."
    – Patrick McElhaney
    Aug 8, 2019 at 20:22
  • 2
    This is an incorrect interpretation of the spec. It DOES define what inactive is further down: "user inactivity: any continuous period of time where no user actions occur". This exception might only apply to hidden or dismissed parts of the UI, e.g. the content behind a modal, the content inside a sidebar, an element that is transitioning into an active state (fade in), the video controls of a video that is being watched. A disabled button in a form is not in an inactive UI.
    – ecc
    Nov 9, 2020 at 14:33
9

I had a problem like this recently.

The answer I came up with was this: Elements/controls must be contrast compliant when disabled as this provides vital clues to the user telling them that their task is incomplete or that certain options are selected/deselected. - In short: Yes, they need to be contrast compliant.

EDIT - The following is incorrect however I do beleive that the WCAG may be wrong in this instance:

The WCAG guidelines quoted by @Roger_Attrill does not cover disabled controls as these are NOT decorative items and ARE visible to sighted people.

Improve this answer
8
  • 3
    The WCAG Guidelines are not saying that the "part of an inactive user interface component" has to be a "decorative item" and/or "visible to anyone". These are three separate criteria.
    – Roger Attrill
    Jul 2, 2015 at 11:01
  • Even so @RogerAttrill, The section you quoted does not cover disabled controls. - The reason I mentioned those two particular criteria is that a disabled control fails to fit into either of them. The only reason I didn't mention the first criterion is that I don't know how large the buttons (and the text on them) in question are - in other words the section you quoted is largely irrelevant to this case
    – Roux Martin
    Jul 2, 2015 at 11:05
  • Oh, sorry @RogerAttrill - I see what you're saying there - I take it back - that section is relevant, but that one place where I think the WCAG may be wrong
    – Roux Martin
    Jul 2, 2015 at 11:08
  • 4
    You make a good point though. Just because something officially / legally ticks all the boxes, that isn't going to help those individuals who get into difficulty as a result of a design decision. They won't care the site is 100% AA compliant if they can't do something they wanted to.
    – JonW ♦
    Jul 2, 2015 at 11:10
  • 2
    @supercat - If something is available to sighted users it should also be available to non-sighted/low-vision users - even if it's just a signal that something isn't ready to be used yet.
    – Roux Martin
    Jul 8, 2015 at 7:34
1

I was having this problem with low contrast text causing my site to fail accessibility audits. The element in question was part of an inactive user interface component, and therefor an exception to the contrast rule, but it was still getting caught by the accessibility audit.

Solution

By adding aria-disabled="true" to the element in question, I was able to pass the accessibility audit without adjusting the contrast.

Improve this answer
1
  • 2
    Very late reply but: this is not the right approach. aria-disabled will clarify it for people who use screen readers, but the purpose of the Minimum Contrast criterion is to help people with low vision and colour blindness, not people who use screen readers. Passing some automated accessibility audit with that logic isn't the same as being accessible.
    – Victor
    Jul 21 at 12:11
0

I realize this is an old thread, but it pops up prominently in searches, so to update:

Is it actually an accessibility requirement for disabled features to be contrast compliant?

Do inactive elements need to be of a certain contrast to be accessible, or does it need to be of a certain contrast to pass WCAG 2.x?

Those are two different things.

WCAG 2.x is a voluntary guideline, not a law, and it does not always promote actual accessibility. Some regions have used WCAG 2.x as the basis of some laws, in no small part as there is a lack of solid standards relating to accessibility in general. Contrast in particular. Even the ADA removed the actual contrast specs for signage (see Ardiiti's 2017 article on this "rethinking ADA signage")

Short Answer

Under WCAG 2.x. contrast, there is no requirement for a disabled element to meet the contrast specifications.

Beyond WCAG

There are other methods, standards, and guidelines though. The draft APC Readability Criterion (which I am a contributor to) for instance does specify a minimum contrast level for things such as disabled controls.

As for actual accessibility, then yes, absolutely, disabled components should be visible, but also, whould be allowed to be at a lower contrast than is required for main content. Varying contrast to create a visual hierarchy is an accessibility feature, too. Not all things should be at "high contrast".

But there is a spectrum of useful contrasts, depending on use case, purpose, etc. The Readability Criterion is being developed with this in mind, and to promote actual accessibility.

Improve this answer
-1

The correct answer is: buttons should never be disabled.

A disabled button causes a loss of focus, therefore keyboard users get stuck on the page. Rather than disabling the button, the button should be active and should not complete the action until the user has completed the necessary states.

E.g. Google. On the Google homepage, if a user does not enter text in the form field, they still have the ability to interact with the button as much as possible. The page simply does not reload until the text has been added.

However, you could semantically leave a button active and style it to appear disabled, and in that situation, you should comply with the aforementioned color-contrast minimums.

This was a lesson I learned while working with Prime Access Consonants. In addition to being accessibility consultants, they also help write the WCAG laws. Hopefully, this context helps shed more light on disabled button states.

Improve this answer
2
  • 4
    Sina is a great guy and Prime Access Consulting is reputable, but there aren't any WCAG laws so they won't be helping with that unless they work for Congress. They might be on one of the WCAG groups to help contribute but I don't see "Prime" or "Sina" listed in any of the author sections of w3.org/TR/WCAG21. Having a button remain active when it's not selectable is purely a subjective decision. You might like that behavior, as might others, but there are probably an equal number of people that don't like that behavior. Saying buttons should never be disabled is just opinion.
    – slugolicious
    Apr 14, 2022 at 18:34
  • I very much agree with @slugolicious — there are many valid reasons to have disabled buttons. And while WCAG2 says disabled components have no contrast requirement, APC-Readability Criterion does have requirements for things like disabled buttons and corporate logos.
    – Myndex
    Oct 31 at 9:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.