Disabled button styles do not have sufficient contrast

[edwardhorsford]

The style for disabled buttons does not have sufficient contrast - it's 2.48:1.

IMHO in most cases we should avoid using disabled styles, but where they are needed, we should come up with a style that can be seen easily.

[joelanman]

Seen easily and obviously disabled seems like conflicting goals.
Can we just ban disabled buttons? If a button action can't be done, message the user about why and how to rectify when they press it.

[matthewford]

Disabled buttons are useful to prevent double form submissions, especially on a slow connection and it takes time for the form to submit.

[joelanman]

In that use case, is fading the button the best visual solution? Maybe a spinner or something?

[matthewford]

Although you could so something fancy with animations.

Fading is quite a common pattern for disabled buttons - even this github comment from does it.

[edwardhorsford]

I think we should separate the discussion of whether 'disabled' styles should exist from whether they're accessible.

For the purposes of this issue, it would be good if we had a style that supports users with visual impairments whilst also looking correct.

[matthewford]

I agree a better disabled style that is accessible is a good thing. I use the disabled styles in the use case above, so wouldn't want to see them go (without fighting my corner).

[edwardhorsford]

Interestingly it seems meeting contrast checks for inactive elements is not a W3C accessibility requirement.

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

Link: https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html

See also these interesting threads:
http://ux.stackexchange.com/questions/80881/do-disabled-buttons-still-need-to-be-contrast-compliant-for-accessibility
http://ux.stackexchange.com/questions/60359/accessible-disabled-state

[matthewford]

That thread also argues that disabled buttons are not 'pure decoration', so are not incidental.

[sanjaypoyzer]

Have we got any research that shows people with visual impairments have a worse experience because of this issue?

The first thing to do seems to be gathering examples of disabled buttons that help any kind of user, then testing to see if the impact is the same.

[edwardhorsford]

I don't know about any specific research we've done, but the contrast ratio of 2.48:1 is well below the recommended WCAG ratio, so some users will definitely be effected.

Can you clarify your 'first thing to do' suggestion?

[joelanman]

Find example of actual user needs for disabled buttons, and testing them (and alternatives) with users with visual disabilities and without

[sanjaypoyzer]

I guess I'm trying to work out what need disabled buttons are solving more generally. One need that's mentioned above is to stop people from trying to "double submit", but it's also been mentioned we could solve that by using a spinner instead of a fade.

Is there anywhere else disabled buttons are used? If we can find them, and identify what usefulness they have, then we can test to see if they have the same usefulness for people who can't see them.

[edwardhorsford]

Right, gotcha.

Some possible use cases off the top of my head - would be good to see what others use if for:

1. - Where working with someone else's system and they require disabled buttons - how do you style them? (payments provider)
2. - To indicate that an action is not currently available (eg zooming-in in a map, where you're at the max zoom level), but normally would be.
3. - Where you're waiting for user action - eg 2-FA and you need them to enter a code to continue.
4. - Where the choices a user makes on a page might enable or disable certain options.
5. - Where something is not available, but it's better to show something than nothing - eg calendar appointments - you might grey out the days that have no bookings available.

[sanjaypoyzer]

1. I think this depends on the use case of the button, but in general should be styled however we choose to style the equivalent button on our own systems.
2. The zoom example is a bit of an odd example, because there's always another active button next to it for the user to compare it to. Doesn't mean this button shouldn't be disabled, but I think it's a lot easier to show when it is, making it not a very good example to design for.
3. Should we be using disabled buttons in this context? Any submit button on a form needs to wait for the user to fill in the form (at least the mandatory fields anyway), and if they miss some then we'll tell them what went wrong. If you show a disabled button then people who don't realise it's disabled and click it anyway won't get that error message.
4. We have a pattern for conditionally shown elements. Shouldn't we be using that in this case?
5. Yeah, this feels like something we should have a pattern for in general. Do you know of any GOV.UK services that use calendar appointments?

In general I feel like we're agreed that disabled buttons tend to be a bad thing. I'm a very digital native user and I've often tried to click them in the past. I'm always annoyed by the fact that clicking them does nothing. Even in the case of the zooming on a map for instance, it would probably be useful to have a message that says "You've zoomed to the maximum level."

[edwardhorsford]

Would be good to see what others use them for - I agree in most cases you can and should avoid them. Mine were just examples of possible use cases.

To your comments:

1. Depends - in general we want to avoid / recommend alternate patterns. But there will be use cases where we don't have any control and need some recommended styles.
2. I agree the fact that there's often an active button next to it alleviates some of the concern. In this case it's more decorative than anything.
3. Might depend be good to do some research. It's not just that it needs information, it needs the user to do something offline. Having done many 2-FA fields this weekend, it felt like different styling (not necessarily disabled) might be helpful.
4. I've not described the case properly. Something like amazon - on a product page once you pick your clothing size, it disables certain colour options, and visa versa. It's easier to see what's available, and I think it's more explicit that these choices are not available than them not being present.
5. Prison visits booking, passports booking, driving test booking, etc.
6. I didn't mention before, but admin apps are also a likely big use case for disabled buttons.

nb: If google had a popup "You've zoomed to the maximum level." each time you zoomed in fully - I think that would be mighty annoying. In that case I reckon doing nothing feels better. Depends on the action though.

[sanjaypoyzer]

Added a PR just to try and address some of the issues around usage, but the core problem of accessibility is still there.

Would adding a border around the button solve the issue?

[gemmaleigh]

@aduggin, it would be great to get your feedback on this one.

[markhurrell]

how about changing the content of the button to reflect the current state?

we typically advise against using colour to infer meaning. is this different?

[joelanman]

we could replace the button content with a spinner animation? That will always fit in the existing button width

[edwardhorsford]

Doesn't the spinner indicate that something is happening? Ie it could work for some usages of disabled buttons (pause while uploading?), but not others?

[edwardhorsford]

@markhurrell I think it better to say that we'd advise against using colour as the only way of conveying meaning. It can be very helpful as an additional way.

[joelanman]

@edwardhorsford yeh we had that discussion downstairs :) in this case, the disabled state is only being shown through a change in colour/saturation, but yes the advice is specifically about not being the only way, as you say.

[edwardhorsford]

Possible solution?

[cjforms]

It's fun,
The word 'disabled' is inappropriate here. (Due to a clash with the general use of the word 'disabled' to mean 'having an impairment'). How about 'not available'?

[sanjaypoyzer]

"Not available" is clearly better than "disabled", but people still need to know why it's not available. PR #212 aims to add guidance around this.

However, regardless of supporting content, we still need a visual design for the button that is accessible. Would be good to know if adding a border could work.

[aduggin]

Apologies for not seeing this thread and replying sooner.

From a technical accessibility point of view (i.e what do you need to do to pass WCAG), my understanding is that a disabled button doesn't have to pass minimum colour contrast requirements.

There is a thread about this on WebAIM mailing list:
http://webaim.org/discussion/mail_thread?thread=5023

The rationale for this is explained by here:

But how is this
information conveyed to the low vision magnifier user who can not discern
the difference in contrast?

It's the lack of contrast that conveys this information. It seems odd,
but it's the slight inaccessibility of the control that conveys that
it is disabled. To maintain high contrast on the control would suggest
that the control is actionable, thus making it less accessible and
usable to everybody.

[joelanman]

However, someone with great vision can still easily read the button label, and know that the action they want to do exists, its just disabled for now (if they understand that from the visual design which is arguable). I think this is another reason not to use disabled buttons if at all possible.

[gemmaleigh]

Additional guidance on using disabled buttons is added in #304