Text input
You can edit this value.
Unavailable while the project is archived.
Appearance settings
These controls change presentation only. They do not change the semantics or focus behaviour of the examples.
Showing current Drupal styles using the system colour preference.
| Comparison | Ratio | Interpretation |
|---|---|---|
| Enabled input border to page | Calculating | Useful control-boundary check. |
| Disabled background to page | Calculating | Diagnostic only. Inactive controls are exempt from WCAG contrast requirements. |
| Disabled border to page | Calculating | Diagnostic only. A disabled control should still be perceivable. |
| Disabled text to disabled background | Calculating | Diagnostic only. The exemption is not a recommendation for low contrast. |
| Enabled checkbox boundary to page | Calculating | Diagnostic only. Checkbox boundary perceivability. |
| Enabled radio boundary to page | Calculating | Diagnostic only. Radio boundary perceivability. |
| File-input text to its background | Calculating | Diagnostic only. |
::file-selector-button text to its background |
Calculating | Diagnostic only. |
| Treatment reason text to its surface | Calculating | Diagnostic only. The reason should stay readable, not dimmed to the control surface. |
| Enabled text to disabled text (state difference) | Calculating | State-difference research, not a WCAG pass or fail. WCAG exempts inactive controls from contrast requirements. |
Control comparison
Compare each enabled control with a disabled equivalent. The current treatment reproduces the relevant Default Admin tokens and the dark-mode unchecked-checkbox selector from Drupal main. The proposal reproduces the changes in merge request !16905.
Select and textarea
Only an administrator can change visibility.
Checkboxes
The dark-mode failure reported in issue #3617875.
Radio groups
Each group is a real multi-option choice. Compare a fully available group, a group with one unavailable option, and a group that is entirely unavailable.
Toggle checkboxes
The proposal also gives this label the disabled text colour.
Buttons
File input
Available and unavailable use the same field name. The badge communicates availability; the reason is kept separate from the format hint.
PDF or PNG, up to 5 MB.
File uploads become available after the record is saved.
PDF or PNG, up to 5 MB.
A separate secondary example. PDF or PNG, up to 5 MB each.
Date and time inputs
Native browser controls are kept; no scripted picker replaces them. Each type is a direct available / unavailable pair with the same field name. The reliable state cue is on the label and surrounding field, not on the browser-rendered calendar or clock icon, whose appearance varies between browsers.
Set automatically when the content is published.
Reminders follow the site default until you enable custom timing.
Locked while the event is in the published calendar.
Number and range inputs
Placeholder matrix
This tests how browsers render placeholder text in enabled and disabled states. It is not a recommended form design: every input keeps a real visible label, and placeholder text is never the label, the reason a control is unavailable, or the only format instruction.
Visual treatment alternatives
Every treatment below uses the same native disabled control and the same content, so only the presentation differs. None of these is presented as WCAG-required or proven better. They are options to compare, not recommendations. The point is that state can be conveyed by more than grey text.
1. Token-only treatment
Drupal's current approach: the disabled state is carried by colour tokens alone.
No extra text or icon. This is the baseline the other treatments are compared against.
2. Text-first treatment
A visible “Unavailable” label plus a plain-language reason.
Turned off by your administrator.
3. Icon-and-text treatment
An icon paired with text. The icon never carries meaning on its own.
Turned off by your administrator.
4. Group-level treatment
An availability message in the group heading area, so the state is announced once for the whole group.
5. Border and pattern treatment
A distinct border and a subtle hatch, combined with visible text. No diagonal strike, and never a pattern alone.
Turned off by your administrator.
Interaction patterns
The same visual treatment does not make these patterns equivalent. Test each example with Tab, Shift+Tab, Enter, Space, a pointer, and a screen reader.
1. Native disabled
Publishing is unavailable until the editorial review is complete.
Expected: unavailable to pointer and keyboard activation, and omitted from the sequential keyboard focus order. The nearby reason remains readable, but a keyboard user cannot focus the button to discover its description.
2. Focusable aria-disabled
Publishing is unavailable until the editorial review is complete.
Expected: included in the focus order and announced as disabled. ARIA supplies no behaviour, so the script must block activation. Keeping it focusable can make the control and its reason discoverable, but adds a stop that cannot perform an action.
3. Active action with validation
Expected: the action remains available. An incomplete attempt produces a specific error and moves focus to the error summary. This is often more useful than making users infer why a button cannot be used.
4. readonly value
Generated by the system. It can be focused, selected, copied, and submitted, but not edited.
Expected: focusable and announced as read only. Use this for an immutable value, not for an unavailable action.
5. Temporarily inert region
Expected while inactive: the whole region is visibly obscured, its controls cannot be focused or activated, and its content is not exposed to assistive technology. The status message and explanation stay outside the inert subtree, and aria-busy is carried on the wrapper that remains in the accessibility tree.
6. Dynamically disabled fieldset
Expected: the controller stays outside the disabled fieldset and keeps focus when toggled. Enabling the fieldset does not move focus into it. Each transition produces one status message. The status container is present and empty from page load; only its text content changes.
7. Form-submission consequences
Submitted form data
Disabled controls (disabled-text, disabled-check, and everything inside the disabled fieldset) are omitted. The readonly-text value is submitted.
Expected: disabled controls are absent from the submitted data; the readonly value is present. Submission is intercepted; nothing is sent anywhere.
Decision guide
| Situation | Starting point | Critical requirement |
|---|---|---|
| One form control is temporarily unavailable | Native disabled |
Explain why nearby. Confirm that removing it from the focus order and form submission is intentional. |
| An unavailable control must remain discoverable in the keyboard order | aria-disabled="true" |
Keep native semantics, block every activation path in script, style the state, and provide the reason. |
| A value can be read or copied but not changed | readonly |
Do not substitute disabled; readonly values remain focusable and are submitted. |
| A whole visible region is temporarily unusable | inert |
Visually obscure the region and keep the explanation outside the inert subtree. |
| The user can correct missing or invalid input | Keep the action enabled and validate | Give a specific, programmatically associated error and manage focus when appropriate. |
| The action can never be available to this user | Usually omit the control | Do not expose an unusable action unless knowing it exists serves a tested user need. |
Do not use styling as behaviour
pointer-events: none, reduced opacity, grey text, and cursor: not-allowed do not disable a control for keyboard or assistive-technology users. Cursor changes are, at most, a supplementary pointer cue.
References and scope
- Drupal issue #3617875: Better Dark Mode Support for Disabled Elements
- Drupal merge request !16905 plain diff
- Drupal issue #3049086: Supporting disabled buttons leads to poor usability and accessibility
- Drupal issue #3200635: Description text of disabled form elements
- HTML Standard: disabled form controls
- WAI-ARIA:
aria-disabled - HTML Standard:
inert - WCAG 2.2 Understanding 1.4.3: inactive controls
- WCAG 2.2 Understanding 1.4.11: inactive controls
- GOV.UK Design System: disabled buttons
This is a focused browser experiment, not a pixel-for-pixel build of all Drupal form components. The token values and selectors under comparison are sourced from Drupal main and merge request !16905 as retrieved on 3 September 2026. See the testing plan for evidence limits.