Disabled means the capability is off and usually not interactive

What it is

Disabled takes a control out of the current interaction: no focus, no edit, and usually no treating the value as selectable text. It says “this capability is not open now”—submit before the agreement is checked, province before a country is chosen. It is not “the value is here, please copy”; that is read-only. The issue is capability off, not whether the grey looks like read-only, and not where the reason is written after the off.

Why it happens

A disabled implementation drops the control from Tab order and from clicks; some screen readers skip it, some say “unavailable.” That is right when a precondition must be met first: focus should not sit on an action that will fail. The side effect is that the value becomes unreachable too—autofill cannot write, copy needs another node. Making a “temporarily uneditable filled value” disabled locks still-needed data into an unreachable state. Disabled also kills hover: pointer events are eaten, a title bubble never appears, and a reason that lives only on hover might as well not be written.

Studying it

Have people complete a task locked by a precondition, comparing disabled, read-only, and visible-but-click-explains. Record: whether the control is noticed, whether the current value can be read, whether focus is wrongly sucked in. Factors: still in focus order or not, static reason text. Outcomes: accuracy at “why can’t I use this,” disabled mistaken for breakage. A screen-reader walk is required: visual grey and an “unavailable” in the tree are not automatic correspondents.

Where it stops holding

A whole-page preview should not mark every control disabled; assistive tech then hears a litany of unavailable. Use read-only or static instead. A custom widget that is only visually grey and still clickable is fake-disabled; submit still fires. A loading lock on a button is another case: a short lock against double-submit, usually still in place, name retained. Disabling a field after a server validation error so the user cannot fix the mistake is the wrong object to disable.

Applying it

• Use disabled only when the capability is not open; use read-only when an existing value must still be copied or spoken.
• Do not put the reason only on hover; place static copy beside the disabled control, or let a click still open an explanation.
• When disabling a custom widget, cut pointer and keyboard together and expose disabled on the accessibility tree.
• Verify by tabbing a row: disabled items should be skipped or clearly announced unavailable. Then try copying the value—if the task needs that value taken, disabled was the wrong state. A click with no explanation means the off has not been accounted for.

Related

• Within the group: E2.21.1 Read-only means not editable now, but still selectable and copyable · E2.21.3 Similar looks hide whether unlock can even be asked for · E2.21.4 A disabled reason must be discoverable; read-only must say when editing returns
• Adjacent: E1.02 Button states · E3.03 Switches
• Search terms: disabled as non-interactive · disabled field · unavailable control