Do disabled buttons still need to be contrast compliant for accessibility?
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.
A disabled button still imparts a message in its own right even if the content behind it cannot be accessed. Wouldn't you effectively be saying that you only want users without visual impairment to know that the feature is only temporarily unavailable?
@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.
A disabled button transmits data. A disabled Button says "This Feature exists but is currently deactivated". If you have issues keeping it in your Interface Style + Colorblind Accessible then just create an Option in the Settings "Enable Extendet Colorscheme for colorblind"
You need to keep in mind what your target audience is. If you create a software that will be ised by very old people than it's absolutely critical to be accessible for people with colorblindness. When you create an online shop where you sell trending cloth for the youth then it might be less important
@JonasDralle I'm not suggesting having a colourblind inaccessible site as a whole, my concern is with inactive buttons only and whether their colour contrast could be considered an accessibility fail. We're not serving up less content to colourblind users - there is messaging on the page to inform them of missing functionality - and to make disabled buttons more accessibly in contrast may mean that fully sighted users (which make up the majority) do not realise the option is disabled, therefore being a worse experience for more users.
@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.
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)
.... This Information is absolutely critical to me because only when I know that the Problem exists I'm able to fix it. It could be that I got the mask selected insted of the layer. I dont see that I got the wrong thing selected, search the Entry i want and then Photoshop tells me that it's currently disabled. Then I can try to seek my mistake. But I can only do that if I'm getting the Information. (2/2)
https://axesslab.com/disabled-buttons-suck/. Unreadable disabled buttons suck twice.
My idea would be to leave it enabled with some kind of error notification process. I would style it visually as disabled trying to respect at least to some degree, as best as possible the contrast requirements and WCAG 1.4.1 requirement (Color is not used as the sole method...). Because I think worse would be to have buttons that are inconsistently sometimes shown, other times not. A user might not understand why. Recommend this article: https://medium.com/@sean_1138/a11y-tips-disabled-buttons-and-colour-contrast-f8824d5e9610
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.
Ah bingo! Not sure how I missed that in the WCAG guidelines, but it does support my opinion, so I'm happy!
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: https://codepen.io/VoloshchenkoAl/pen/dMWxoL
@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.
Unfortunately the spec doesn't define "inactive". It's not clear whether "inactive" is synonymous with "disabled."
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.