Style Accessible Hover, Focus, and Disabled States

Interactive controls can communicate different things:

• Hover state means a pointer is over an element.
• Focus identifies the current interaction target, such as a control reached with the keyboard.
• A disabled control is a supported control that is unavailable.

These are different conditions, even when each changes an element’s appearance. Before any interaction, a link, input, or button still needs a recognizable default appearance so people can identify its purpose.

Create a folder containing index.html and styles.css. This local starter page includes an underlined link, a labeled input, an enabled reset button, and an unavailable submit button. The browser’s native focus indicator is intentionally left intact for now.

Save this complete file as index.html.

Save this complete starter stylesheet as styles.css. It contains base styles only; later steps add interaction-state styles.

A :hover pseudo-class matches while a pointing device is over an element. It can provide useful feedback, but it must not be the first moment a person can recognize what a control does.

Keep the link underlined and the button labeled in their default state. On hover, add another cue: strengthen the link underline, and underline the button text as its background changes. A person using touch may not get the same hover behavior, so labels and instructions must already be visible.

Add these rules in the hover styles section of styles.css, after the base styles. The link’s underline is already present by default; hover makes that underline thicker. The button changes its surface color and gains an underline, so the feedback is not only a hue change.

Add these rules below your base styles in styles.css. Save, refresh the local page, and move a pointer over the link and enabled reset button.

Focus marks the current target

A control has focus when it is the current target for interaction. :focus matches any focused element, whether focus arrived through the keyboard, a pointer, or another browser action.

:focus-visible is narrower: it matches focused elements when the browser determines that a visible focus indicator is needed. It is not a strict keyboard-only detector. For example, a text input can match :focus-visible after a pointer interaction because typing needs a clear target.

Keep the browser’s native focus indicator unless you provide an equally clear authored replacement. Never remove an outline globally just to change its appearance.

Use Tab to move forward through reachable native controls and Shift+Tab to move backward. With focus on a link, Enter activates it. With focus on a native button, Enter or Space activates it.

State CSS changes appearance only; it must not replace these native keyboard behaviors. Test the local page in a browser after adding the styles.

Add this section after the hover styles in styles.css. It gives the link, field, and action button the same clear focus indicator.

A disabled control gets its unavailable behavior from HTML, not from a faded appearance. On a supported control such as a <button>, the disabled attribute prevents operation and removes the button from sequential keyboard focus: Tab moves past it.

The :disabled pseudo-class selects a control that is already disabled. CSS can make that state recognizable, but CSS does not create the behavior. An enabled button with muted colors—or only a different cursor—can still be activated and reached with Tab.

A link does not support native disabled behavior through a disabled attribute. Giving that attribute to an anchor does not stop it from working as a link.

Keep the native attribute on the unavailable submit button and keep the explanation visible beside it. The message tells people why the action is unavailable; muted color is not the only cue.

Keep this markup in index.html. The disabled attribute supplies the unavailable button behavior, while the adjacent text supplies a persistent explanation.

Add this rule in the disabled styles section of styles.css, after the hover and focus sections. It selects the button that HTML has already disabled and gives it a muted but readable appearance. These declarations do not disable an enabled button; the HTML attribute remains necessary.

Append this rule to the disabled styles section. Save and refresh the local page.

An enabled control can be in a hover state and match :focus-visible at the same time. The selectors describe separate conditions; neither state cancels the other.

Give them separate visual jobs. Hover changes the button background and adds an underline. The focus indicator uses an outline outside the control. When a keyboard-focused button is also under the pointer, both cues can remain visible.

A disabled control can also be under a pointer and match :hover. Its unavailable appearance must therefore replace enabled hover feedback.

Keep the state sections in this order: hover, focus, then disabled. Hover and focus-visible set different properties, so their feedback can coexist.

.action:hover and .action:disabled have equal specificity: each contains one class and one pseudo-class. They both set background-color and text-decoration. Because the disabled rule comes later, it replaces the hover values for a disabled button under the pointer.

Keep these state sections in this order in styles.css, below the base styles. Save and refresh, then inspect both combined conditions in your browser.

Contrast is a comparison between a cue and the color directly beside it, not a judgment based on the whole screen.

For this normal-size interface, enabled text needs at least 4.5:1 against its background. Visual information needed to identify an enabled control—such as an essential input boundary or button fill—needs at least 3:1 against adjacent colors. An authored focus indicator also needs at least 3:1.

Ask whether the feature communicates something necessary. A purely decorative border does not need its own target. But if a boundary is what makes a white input recognizable as a control, it is an essential non-text cue.

Enter the supplied hexadecimal values into a contrast checker and interpret the ratio by the cue’s purpose and state. Small display-rounding differences between checkers are normal.

The button label and its fill are separate pairs: white label text is compared with the blue fill, while the blue fill is compared with the surrounding white surface when that fill helps identify the enabled control. Likewise, the hovered link is a changed text pair that needs its own check.

Replace the contents of styles.css with these two code blocks in order. Together, they are the final reference stylesheet for the local Workshop signup page. This base section keeps every enabled control recognizable before interaction: the link is underlined, the field has a visible boundary, and the enabled button has a filled surface.

Part 1 of 2 — save this base section first in styles.css.

Part 2 of 2 — append these state sections after the base styles. The order lets the later disabled rule replace matching hover properties.

Save both files and refresh the local page. Gather evidence with these trials:

1. Before hover, confirm that the link is underlined, the field has a boundary, and Clear form is visibly a button. Confirm that no purpose or instruction appears only on hover.
2. Hover the link and Clear form.
3. Use Tab and Shift+Tab. With focus on Workshop details, press Enter.
4. Type Pointer test in the field, then activate Clear form with the pointer and confirm the field empties.
5. Type Keyboard test in the field, Tab back to Clear form, then activate it with Enter or Space and confirm the field empties.
6. Keep Clear form keyboard-focused and move the pointer over it. Confirm that its hover cue and focus indicator both remain visible.
7. Continue with Tab and confirm Join workshop is skipped. Move the pointer over it and confirm its unavailable appearance remains and it cannot be activated.

Use the table readings as focused evidence for these states, not as a complete accessibility audit.