Accessible Website Fixes That Actually Matter in 2026

Most accessibility audits hand you a 40-page PDF and a list of 200 violations, half of which nobody will ever hit. The fixes that actually matter are the ones that block real people from using your site: keyboard traps, invisible focus, unlabeled forms, missing alt text, and text you can’t read. Here are the five I fix first, with the code.

If you’re running a small business site and don’t have a developer on staff, most of these are copy-paste jobs. I do this kind of work as a Long Island web design project all the time, and these five come up on nearly every site I touch.

1. Kill the focus outline, and you kill keyboard navigation

Someone on your site is tabbing through it right now. Maybe they can’t use a mouse, maybe their trackpad died, maybe they just prefer the keyboard. If you’ve got outline: none anywhere in your CSS, they’re navigating blind. They have no idea which link or button is active.

The fix isn’t to remove outlines. It’s to style them so they look intentional instead of like a 1998 browser default.

/* Don't do this */
a:focus, button:focus {
 outline: none;
}

/* Do this instead */
:focus-visible {
 outline: 3px solid #1a5cff;
 outline-offset: 2px;
 border-radius: 2px;
}

/* Only remove the outline for mouse users who don't need it */
:focus:not(:focus-visible) {
 outline: none;
}

:focus-visible is the key. It shows the ring for keyboard users and hides it for mouse clicks. It’s supported everywhere that matters in 2026, including Safari. There’s no reason to use the old :focus hack anymore.

2. Every form field needs a real label

Placeholder text is not a label. It disappears the second someone starts typing, it’s low contrast by default, and screen readers don’t reliably announce it. If your contact form has five fields with placeholder text and no labels, you’re asking people to fill out a form blind.

<!-- Bad: placeholder as label -->
<input type="email" placeholder="Email address">

<!-- Good: real label, visible -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">

<!-- Also fine if you truly can't show a label -->
<label for="email" class="visually-hidden">Email address</label>
<input type="email" id="email" name="email" placeholder="you@example.com">

Two things people miss here. First, the for attribute has to match the input’s id exactly, or the label does nothing. Second, add autocomplete attributes. They help everyone, and they’re a WCAG 2.2 requirement under “Identify Input Purpose.”

Error messages matter too. Don’t just turn the border red. Say what’s wrong, and tie it to the field with aria-describedby.

<label for="phone">Phone</label>
<input type="tel" id="phone" aria-describedby="phone-error">
<p id="phone-error" role="alert">Enter a 10-digit phone number.</p>

3. Alt text: describe the image, not the file

I still see alt="image" and alt="IMG_4471.jpg" on sites built last year. Alt text exists so someone using a screen reader knows what the image shows. If it’s decorative, leave the alt empty (alt="") so the screen reader skips it entirely. Don’t write “decorative image” in there.

• Informative image: alt="Storefront on Main Street with a green awning"
• Decorative image: alt="" (empty, no text)
• Image that’s a link: describe where the link goes, not the picture
• Chart or graph: put the takeaway in the alt, and include the data in text nearby

One rule of thumb: if you removed the image and the page still made sense, it’s decorative. If you removed it and lost information, it needs alt text.

4. Contrast is a math problem, not a taste problem

Light gray text on white is the single most common issue I find. It looks clean in Figma on a bright monitor and turns into a ghost on a phone in sunlight. WCAG requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt+ or 14pt bold).

You don’t need to memorize ratios. Use the browser’s built-in checker: open DevTools, inspect the text element, and look at the color swatch. Chrome and Firefox both show a contrast ratio and a green checkmark or red X. Takes ten seconds.

/* Fails: light gray on white is about 2.3:1 */
.subtitle { color: #999999; }

/* Passes: about 4.6:1 */
.subtitle { color: #767676; }

/* Passes comfortably: about 7:1 */
.subtitle { color: #595959; }

Same rule applies to placeholder text and to buttons where the label sits on a colored background. A white button label on a light blue button is a classic fail. Darken the blue.

5. Test with a keyboard before you ship

This is the one that catches everything else. Unplug your mouse, or just don’t touch it. Put your cursor in the address bar and press Tab. Then keep pressing Tab and watch what happens.

• Can you reach every link, button, and form field?
• Can you always see where you are?
• Can you open and close any menus or modals with Enter and Escape?
• Can you get back out of anything you got into?

That last one is the killer. Custom dropdowns and modal dialogs are notorious for trapping keyboard focus. If you open a modal and Tab just keeps cycling inside it with no way to close, that’s a trap, and it’s a hard fail. A quick check with a screen reader like NVDA on Windows or VoiceOver on Mac (Cmd+F5) will surface the rest.

None of this requires a big budget or a six-week audit. It’s an afternoon of honest testing and a handful of CSS and HTML edits. Fix these five and you’ve handled the issues that actually stop people from using your site. The rest of the audit checklist can wait.

FAQ

Do I legally have to make my website accessible?

If you’re a business open to the public, the safe answer is yes. Courts have consistently treated websites as places of public accommodation under the ADA, and lawsuits over inaccessible sites are common. New York State also has its own accessibility standards for state agencies and contractors. Treat it as a legal risk and a usability win at the same time.

Will these fixes break my site’s design?

No. Styled focus rings, real labels, and darker text are all small visual changes. The contrast fix is the only one that might shift your palette slightly, and it usually makes text look sharper, not worse. Nothing here requires a redesign.

How do I know if my site has these problems?

Run the keyboard test in section 5 first. Then run your homepage through a free tool like axe DevTools or WAVE. Neither catches everything, but both will flag missing labels, low contrast, and missing alt text in under a minute. If the report comes back long, fix these five before you touch anything else.