IAnswerable

Five Accessibility Fixes That Take an Hour

02 Nov 2026

None of these need a design review or a sprint. Do them in the hour you have between other tickets.

1. Bring back focus states

outline: none on :focus without a replacement is the single most common accessibility regression, and it’s usually in a global reset from three years ago that nobody remembers writing. Anyone navigating by keyboard loses all visual indication of where they are on the page.

/* Don't do this without a replacement */
:focus { outline: none; }

/* Do this instead */
:focus-visible {
  outline: 2px solid #2b6cb0;
  outline-offset: 2px;
}

:focus-visible shows the ring for keyboard users and suppresses it for mouse clicks, which is why it replaced the old “just always show :focus” advice — you get the accessibility win without the visual complaint about focus rings on mouse clicks.

2. Label every form input

A placeholder is not a label. It disappears the moment someone types, and most screen readers don’t announce it as a field name at all.

<!-- Broken: no accessible name -->
<input type="email" placeholder="Email">

<!-- Fixed -->
<label for="email">Email</label>
<input type="email" id="email">

If a visible label breaks your design, use aria-label — but a visually-hidden real label is almost always better, because it also gets picked up by browser autofill and “click label to focus input” behavior that aria-label doesn’t give you.

3. Check your contrast ratios

Text needs a contrast ratio of at least 4.5:1 against its background (3:1 for large text, 18pt+ or 14pt bold). Your browser’s dev tools will tell you this directly — inspect a text element in Chrome or Firefox and the color picker shows the ratio and a pass/fail against WCAG AA right there. Fix the ones that fail. Light gray text on white is the most common offender in any design system that leans on #999-on-#fff for “secondary” text.

4. Add landmark regions

Screen reader users navigate by landmark, jumping between nav, main, header, footer with a single keystroke instead of reading the whole page top to bottom. If your markup is div soup, that navigation doesn’t exist for them.

<header>...</header>
<nav>...</nav>
<main>
  <h1>Page title</h1>
  ...
</main>
<footer>...</footer>

This is a five-minute find-and-replace on most templates, and it’s the highest leverage change on this list relative to effort.

Without one, a keyboard user has to tab through your entire nav on every single page load before reaching content. A skip link is one anchor, visually hidden until focused:

<a href="#main" class="skip-link">Skip to content</a>
...
<main id="main">
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
}

Put it as the very first focusable element in the DOM, before the nav.

What this doesn’t cover

These five fixes get you past the most common automated-scanner failures, but they don’t replace testing with an actual screen reader or a keyboard-only pass through your critical flows — checkout, signup, search. Do those two things next; they surface problems no CSS fix will catch, like a modal that traps focus wrong or a custom dropdown with no keyboard handling at all.