The :disabled pseudo-class in CSS targets form elements that are currently disabled. Disabled elements cannot be interacted with by the user, such as <input>, <button>, <select>, and <textarea>. This pseudo-class allows you to style these elements differently to indicate their inactive state.

Example: Using :disabled

In this example, disabled inputs and buttons are visually distinct and indicate that they cannot be interacted with, improving user experience and accessibility.

Best Practices

1
Use :disabled to style elements clearly when they cannot be interacted with.
2
Combine with visual cues like color, opacity, and cursor changes for better UX.
3
Do not rely solely on color to indicate disabled state; ensure sufficient contrast and other cues for accessibility.
4
Test disabled styles across browsers, as form element styling can vary.

Difficulty: 4/10

Topics: pseudo-classes, form controls, accessibility

Scenario Questions

0-2 years experience

1
If you add button:disabled { opacity: 0.5; } to a page, what will happen when the button element has the disabled attribute? Explain why.
2
You need to style a <select> element differently when it's not interactive. How would you use the :disabled pseudo‑class to achieve that?
3
What happens if you apply pointer-events: none to a disabled input—does the :disabled selector still match?

2-5 years experience

1
We have a form where some inputs are dynamically disabled via JavaScript. The styles for input:disabled aren't applying. What could be causing that and how would you fix it?
2
During a UI review, a disabled button still receives focus and can be activated via keyboard. Why might the :disabled pseudo‑class not be preventing interaction, and what changes would you make?
3
Explain the difference between using the disabled attribute versus adding a .disabled class and styling with .disabled. When would each be appropriate?

5-8 years experience

1
Our component library needs to support custom form controls that mimic native disabled behavior across browsers. How would you design the CSS and JavaScript to ensure :disabled styles work consistently, considering shadow DOM and accessibility?
2
We discovered that in Safari, :disabled does not apply to <fieldset> children when the fieldset is disabled. How would you handle this edge case in a large‑scale UI framework?
3
Discuss performance implications of using :disabled selectors on a page with thousands of form elements. How would you mitigate any impact?

8+ years experience

1
We're planning a migration from a legacy UI that uses .disabled classes to a standards‑compliant approach using the native disabled attribute and :disabled pseudo‑class. What architectural considerations, testing strategies, and rollout plan would you propose?
2
In a multi‑team product, some teams need brand‑specific disabled styling while others rely on default :disabled behavior for accessibility. How would you design a theming system that balances these needs without breaking accessibility?
3
Consider a design system that must support both web and native mobile (React Native) where the concept of :disabled doesn't exist. How would you abstract disabled‑state handling across platforms to keep a consistent developer experience?

Follow-up Questions

❓How does the browser decide whether an element matches :disabled?
❓What accessibility concerns arise if a disabled element is still focusable?
❓Can you describe how cascade order affects multiple :disabled rules?