Website Accessibility Fixes That Actually Help (2026 Guide)

Most accessibility advice you find online is either a vague checklist or a sales pitch for an overlay widget. Neither helps you ship a better site. Here’s what actually matters, in the order I fix things when I audit a client’s site, with code you can use today.

Accessibility is not a nice-to-have anymore. It’s a legal exposure and a usability issue at the same time. And the fixes are usually smaller than people expect.

Start with the stuff that breaks for real users

Before you touch anything, install a screen reader and tab through your own site. On a Mac, VoiceOver is built in (Cmd+F5). On Windows, NVDA is free. Spend ten minutes. You’ll find problems fast, and you’ll understand why they matter instead of just checking boxes.

Then run a scanner. axe DevTools is a solid free browser extension. Lighthouse in Chrome DevTools has an accessibility audit too. Treat these as a starting point, not a finish line. Automated tools catch maybe 30 to 40 percent of real issues. The rest needs a human.

Color contrast

Low contrast text is the single most common problem I see, especially with gray-on-white body copy that looked fine on a designer’s monitor. WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold).

Here’s the trap: a color can look accessible and fail. Light gray text at #999999 on white is only about 2.85:1. It fails. Bumping it to #767676 gets you to 4.54:1, which passes.

/* Fails: 2.85:1 */
.muted { color: #999999; background: #ffffff; }

/* Passes: 4.54:1 */
.muted { color: #767676; background: #ffffff; }

Don’t guess at ratios. Use the WebAIM contrast checker or a browser extension. And check your hover states and placeholder text too, since those get missed constantly.

Alt text that isn’t garbage

Alt text is not keyword stuffing. It’s a description of what the image conveys, for someone who can’t see it. If the image is decorative, leave the alt attribute empty so screen readers skip it.

<!-- Good: describes the content -->
<img src="storefront.jpg" alt="Storefront on Main Street with a blue awning">

<!-- Decorative: empty alt, screen reader ignores it -->
<img src="divider.svg" alt="">

One thing people get wrong: if an image sits inside a link and the link has no other text, the alt text becomes the link’s accessible name. So it needs to describe the destination, not the picture. “Read the pricing guide” beats “arrow icon.”

Keyboard navigation

Anything you can do with a mouse, you should be able to do with a keyboard. Tab, Enter, Space, arrow keys. Test it. Common breakages:

• Dropdown menus that only open on hover, so keyboard users can’t reach the links inside.
• Custom buttons built from <div> or <span> that don’t respond to Enter or Space.
• Focus outlines removed with outline: none and nothing put back in their place.
• Modal dialogs that don’t trap focus or return it when closed.

That last one is worth a code fix, because it’s easy to get wrong:

<!-- Use a real button. It's focusable and keyboard-operable for free. -->
<button type="button" onclick="openMenu()">Menu</button>

<!-- If you must build a custom control, add the semantics and key handling -->
<div role="button" tabindex="0" onclick="openMenu()"
 onkeydown="if(event.key==='Enter'||event.key===' '){event.preventDefault();openMenu();}">
 Menu
</div>

And never kill focus styles without a replacement. If the default outline clashes with your design, style it instead:

:focus-visible {
 outline: 3px solid #1a5fb4;
 outline-offset: 2px;
}

:focus-visible is the modern approach. It shows the outline for keyboard users but usually not for mouse clicks, which is exactly what you want.

Forms people can actually complete

Forms are where accessibility and conversion overlap. Every input needs a label tied to it. Placeholders are not labels, because they vanish the moment someone starts typing.

<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email" required>

Also: mark required fields in text, not just with a red asterisk. Announce errors in a way a screen reader picks up. Use aria-live for status messages that appear after submission. And keep the autocomplete attributes, since they help everyone and are a real WCAG criterion (1.3.5).

Headings and landmarks

Screen reader users navigate by headings the way sighted users scan visually. If your page has three <h1> tags or jumps from <h2> to <h4>, that navigation breaks. One <h1> per page, headings in order, no skipping levels for styling reasons. Use CSS for size, not heading tags.

Wrap your major sections in semantic landmarks: <header>, <nav>, <main>, <footer>. Add a skip link so keyboard users can jump past the nav:

<a class="skip-link" href="#main">Skip to content</a>
...
<main id="main">...</main>

<style>
.skip-link {
 position: absolute;
 left: -9999px;
}
.skip-link:focus {
 left: 0;
 top: 0;
 background: #fff;
 padding: 8px 16px;
}
</style>

What changed heading into 2026

WCAG 2.2 has been the current standard for a while now, and it added a few things worth knowing. Target Size (Minimum) means clickable elements should be at least 24 by 24 CSS pixels, which mostly kills tiny icon links. Focus Not Obscured means a sticky header shouldn’t cover the element someone just tabbed to. Dragging Movements means if you have a drag interaction, there needs to be a non-drag alternative.

There’s also a draft of WCAG 3.0 floating around, but it’s years from being a requirement. Don’t wait for it. Fix what’s broken now against 2.2.

Skip the overlay widgets

You’ve seen them: a little accessibility icon in the corner that promises instant compliance. Overlays don’t fix the underlying markup. They can’t add alt text that isn’t there or repair a broken heading structure. They’ve also been the target of lawsuits, and in some cases the overlay itself introduces new problems. Real accessibility lives in your HTML, CSS, and JavaScript. There’s no shortcut around that.

Where to go from here

You don’t have to fix everything in one pass. Prioritize by impact: contrast, alt text, keyboard access, and form labels cover most of what hurts real users. Get those right, then work through the rest. If you’d rather hand it off, this is the kind of work I do as a Long Island web design project, and it’s often a few focused hours rather than a rebuild.

FAQ

Do I need to be fully WCAG compliant to avoid a lawsuit?

There’s no legal bright line, but courts generally look at whether you made a genuine effort. Fixing the real, user-facing issues goes a lot further than installing an overlay and calling it done.

How do I test accessibility without hiring someone?

Turn on VoiceOver or NVDA and tab through your site. Run axe DevTools and Lighthouse. That combination catches most serious problems for free. A paid audit makes sense when you need documented results or a formal compliance report.

Will fixing accessibility break my design?

Rarely. Better contrast, real focus states, and proper labels usually improve the design for everyone. When something does clash, it’s almost always solvable with CSS rather than a compromise.