We need a more accessible way to disable things

The convention for displaying disabled controls is to make them light grey, or semi-opaque.

Which is fine if you have decent eyesight and can perceive them. Much less so if you can’t.

WCAG is wrong

The WCAG 2.1 guidelines appear to give designers a get-out-of-jail-card on it:

Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, have no contrast requirement.

https://www.w3.org/WAI/WCAG21/quickref/#contrast-enhanced

There’s a lot of chat about this on the forums, and I agree with many people when they argue the guidelines are wrong and that all users should be able to perceive disabled controls if they convey useful information in their own right.

For example, consider a disabled Submit button on a form that’s waiting to be completed. The presence of the button, and the fact sighted users can see it’s disabled, conveys information about the state of the form and the promise of being able to interact with ’Submit’ when we’ve done some more work.

Another example would be an item in a checkbox list that is pre-ticked and disabled. In this case, being able to see the value is checked, even though we can’t change it, might be a critical piece of information.

To be fair to WCAG, they do acknowledge the problem and are understood to be working towards introducing a minimum contrast ratio for disabled controls in the next major edition of the guidelines, Silver.

This thread on the W3C’s issues list perfectly summarises the conversation.

The HTML spec, browser and assistive technology makers are all wrong

If a control is disabled, it’s essentially hidden from the flow of the DOM.

Many assistive technologies ignore disabled controls, refusing, for example, to read them out.

These deliberate behaviours exclude a significant proportion of users from being able to perceive disabled controls. The intention was clearly that disabled items are irrelevant for the user at this moment, but in practice they can often still provide otherwise useful, important or critical information.

The introduction of an additional aria role, such as aria-disabled might help authors better construct pages, but there’s certainly work to be done to the spec.

Designers are wrong

Rarely within the forums have I seen designers holding their hands up and taking some of the blame for all this.

Historically, designers have been slow to consider accessibility (my hands are up, I’ve been there).

It’s easy as a designer to point the blame at the W3C, browser makers, teachers, mentors, clients and employers – for making a hash of the spec, not providing appropriate guidance, or by putting speed and profit ahead of compliance.

But designers created and blindly peddled the greyed-out solution that became a convention. A convention that works for some, excludes or frustrates others.

It became a lazy shortcut because it’s easy to visually disable something by greying it out and still convey lots of meaning in context.

To help fix the problem, designers need to explore different ways of indicating a disabled state of a control that meet the current WCAG spec (not taking 1.4.6 Incidental all that seriously, of course).

The instant challenge here is that the minimum contrast ratios for both text and graphical elements are by definition incompatible with the ’traditional’ method of reducing contrast ratios by greying-out – it’s just too ‘readable’ for the purpose.

A better challenge for designers

A better challenge for designers might be to change the way pages are designed in the first place.

If we’re relying on disabled controls to convey meaning and context, what other way can we achieve the same goal?

What happens to the page when those disabled controls are removed? What meaning have we lost? How can we put it back in a universally accessible way?

None of this represents an insurmountable problem. It just needs thought and care.

Shared responsibility

There are clearly some issues to sort out:

• The WCAG spec needs to properly consider disabled states and provide clear, unambiguous guidance
• The HTML spec needs some work with contribution from the W3C, browser makers and assistive tech makers
• Designers need to re-think how disabled controls are used.

All three need to come together to create a proper working solution to the problem. The first two will take some time to get it right, but designers can start exploring and implementing solutions right now.

It won’t be easy, but that’s no excuse. We all have a responsibility to our users to get it right.