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.

  • 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 '15 at 10:47
  • 2
    Disabled Buttons contain information and thus should be accessible – BlueWizard Jul 2 '15 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 '15 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 '15 at 4:01
  • 2
    axesslab.com/disabled-buttons-suck. Unreadable disabled buttons suck twice. – maaartinus Feb 16 at 4:21

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 | |
  • 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 '15 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 '19 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 '19 at 22:10
  • 1
    Unfortunately the spec doesn't define "inactive". It's not clear whether "inactive" is synonymous with "disabled." – Patrick McElhaney Aug 8 '19 at 20:22

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 | |
  • 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 '15 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 – Andrew Martin Jul 2 '15 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 – Andrew Martin Jul 2 '15 at 11:08
  • 3
    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 '15 at 11:10
  • 1
    @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. – Andrew Martin Jul 8 '15 at 7:34

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.


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 | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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