Disabled Controls Explained
Group: help-and-feedback • Guideline: help-available
Summary in Plain English
When a control is visible but disabled, the content explains why, and if the user can do something to enable it, says what.
Why It Matters
A greyed-out button with no explanation is a dead end: the user cannot tell whether they have missed a step, lack permission, or hit a bug.
Examples from the Draft
Worked examples the W3C editors wrote into the provision itself, not examples invented here.
When a submit button is disabled until all required fields are filled in, explain that this is the case.
Test Procedure from the W3C Draft
Quoted from the provision's informative document, informative/guidelines/help-and-feedback/help-available/disabled-controls-explained.md. It is the group's own procedure, not an editorial testing guide.
Procedure
For each visible disabled control:
- Check that instructions are available that explain how to enable it.
Expected results
- #1 is true.
W3C Working Group Status
The draft records no open editors' notes on this provision.
W3C Threads on This Provision
2 GitHub threads carrying 5 comments, fetched from w3c/wcag3 by the tracker. Titles, numbers and states are the threads' own.
⚠️ This summary is stale — comments landed after it was written.
What the Argument Is About
Light discussion across two issues: a 2019-2020 exchange over whether disabled controls need a mandated icon or just adequate contrast, and a separate COGA request that explanations be persistent rather than transient.
Positions taken in the thread
DavidMacDonald opened #197 noting that disabled interface elements work badly for people with low vision precisely because WCAG 2 exempts them from 1.4.3, and proposed requiring either 3:1 contrast or an icon marking the element as disabled. bkimmel seconds the problem, particularly where disabled states are used to signal future potential — fill these in and you can submit — calling the exemption a large safe harbour that cuts against the Perceivable goal. bkimmel is explicitly unsure an icon is the right remedy.
Would rather see some minimum contrast applied to solve readability than have WCAG start demanding icons everywhere, which impinges on visual design decisions. Suggests a more general intent of "indicating that something is disabled" as the flexible form. Also notes a likely crossover with how user agents themselves indicate disabled state.
Points out that "Interactive elements distinguishable" is adjacent to this problem, but the definition of interactive element — responds to user input and has a distinct programmatically determinable name — excludes disabled elements, which instead fall under non-interactive element. Since disabled elements are not mentioned in the examples or notes around that definition, he questions what the group actually intends, and floats broadening the term or adding a new one for elements that exist to be interactive but may conditionally be disabled or read-only. Flags this provision as also applicable and links w3c/wcag#5053.
Filing for the COGA Task Force in #783, notes the provision requires that information explaining why a control is disabled be available but says nothing about timing or persistence. A snackbar that vanishes after three seconds fails a user with slower processing speed. Recommends requiring explanations be persistent and visually co-located, and asks that this be checked for compatibility with "Notifications adjustable" in the User Control section. Cites MCU 3.1.2, 3.2.1, 3.7.5 and A.4.
Agreed
- Disabled controls being exempt from contrast requirements is a real low-vision problem worth addressing — nobody in #197 disputed the premise, only the remedy.
- alastc took #197 off the WCAG 2.2 slate in 2020 as needing more work, consideration and research, and it has stayed there.
Still open
- Whether the fix is contrast, an icon, or a technology-neutral requirement to indicate disabled state — patrickhlauke's objection to mandating icons has gone unanswered since 2020.
- Whether the definitions of interactive and non-interactive element should be revised to account for disabled and read-only states, raised by adampage.
- julierawe's persistence and co-location requirement, filed in August 2026 with no replies.
Note
#197 predates WCAG 3 and sat untouched from 2020 until adampage revived it in May 2026. #783 has drawn no response at all.
WCAG 2.2 Criteria That Map Here
From this site's reviewed WCAG 2.2 → WCAG 3 map. The map is an interpretation, not a W3C mapping: W3C has not published one yet.
No mapping recorded. No WCAG 2.2 criterion in this site's map is recorded as a predecessor of this provision.
W3C Raw Source Text
Verbatim from guidelines/groups/help-and-feedback/help-available/disabled-controls-explained.md · informative document: informative/guidelines/help-and-feedback/help-available/disabled-controls-explained.md
Information explaining why a visible interactive element is disabled is available and, if the user can take action(s) to enable the element, those action(s) are described. :::example When a submit button is disabled until all required fields are filled in, explain that this is the case. :::