How to Build Accessible Websites That Hold Up in 2026

Most sites I audit are not inaccessible because someone decided to ignore accessibility. They are inaccessible because the people building them never got a straight answer about what “accessible” actually means in practice. So here is the straight answer, with code, and with the parts that trip up real projects.

I have been building and fixing websites for a long time, much of it for small businesses around here. The rules have not changed much. The tooling has. Let me walk through what actually matters in 2026.

What “accessible” means right now

The working standard is WCAG 2.2 at Level AA. That is what ADA-related lawsuits and most procurement checklists point at. WCAG 2.2 added a handful of success criteria over 2.1, and a few of them catch people off guard:

• 2.4.11 Focus Not Obscured (Minimum): when someone tabs to a link or button, a sticky header or cookie banner cannot cover it.
• 2.5.8 Target Size (Minimum): interactive targets need to be at least 24×24 CSS pixels, with some exceptions for inline links and spacing.
• 3.3.8 Accessible Authentication (Minimum): no puzzles or memory tests as the only way to log in. Paste must work in password fields, and a password manager has to be allowed to do its job.
• 3.2.6 Consistent Help: if you offer a help mechanism (phone number, chat, contact link), it needs to appear in the same relative place on every page.

That last one is boring and easy. A consistent footer contact block satisfies it. Do that.

The four failures I see over and over

1. Divs pretending to be buttons

If it does something, it should be a <button> or an <a>. A clickable div gets no keyboard focus, announces nothing useful, and breaks under screen readers. The fix is not to bolt on ARIA. The fix is to use the right element:

<!-- Don't do this -->
<div class="btn" onclick="submitForm()">Submit</div>

<!-- Do this -->
<button type="submit">Submit</button>

Same visual result, and you get focus, keyboard activation, and the correct role for free. ARIA does not add behavior. It only changes how things are announced. If you find yourself adding role="button" and tabindex="0" and a keydown handler, you have already lost.

2. Images with no alt, or worse, alt that says nothing

Decorative images get alt="". Meaningful images get a description of what the image conveys, not what it is. “Chart showing Q3 revenue up 12 percent” beats “chart.” And never start with “image of” or “picture of.” Screen readers already say that.

<img src="revenue-q3.png" alt="Q3 revenue up 12 percent over Q2">
<img src="divider.svg" alt="">

3. Color contrast that fails by a hair

4.5:1 for normal text, 3:1 for large text (18pt, or 14pt bold). This is measured, not eyeballed. Gray text on white is the usual culprit. That light gray placeholder look people love in mockups frequently lands around 2.5:1.

One thing worth knowing: the old practice of disabling zoom on mobile to “fix” layout is a WCAG failure (1.4.4). Let people pinch and zoom. Fix the layout instead.

4. Forms that only tell you what went wrong visually

Red borders mean nothing to someone using a screen reader. Every input needs a real label, and errors need to be announced and tied to the field.

<label for="email">Email address</label>
<input id="email" name="email" type="email"
 aria-describedby="email-error" aria-invalid="true">
<p id="email-error" role="alert">Enter a valid email address.</p>

The aria-describedby links the error to the field so it gets read when the field is focused. role="alert" makes it announce as soon as it appears. Two attributes, big difference.

Skip links and focus order

A skip-to-content link is still one of the highest-value things you can add. It needs to be the first focusable element on the page and visible when focused:

.skip-link {
 position: absolute;
 left: -9999px;
}
.skip-link:focus {
 left: 0;
 top: 0;
 background: #fff;
 padding: .75rem 1rem;
 z-index: 1000;
}

Then the markup:

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

Do not use tabindex values greater than zero to control order. It creates a nightmare for keyboard users. Source order should match visual order. If it does not, fix the markup, not the tabindex.

How to actually test this without guessing

Automated tools catch roughly a third of real issues. They are useful, but they are not the whole job. A workable routine:

• Automated pass: axe DevTools or Lighthouse in Chrome. Fast, catches contrast, missing labels, bad ARIA, landmark issues.
• Keyboard pass: put the mouse away. Tab through the whole page. Can you reach everything? Can you always see where you are? Can you get out of any modal?
• Screen reader pass: VoiceOver on Mac (Cmd+F5) or NVDA on Windows. Free, and it will humble you in about five minutes.
• Zoom pass: browser zoom to 200 percent. Nothing should overlap or get cut off.

I do this on a handful of pages per site, not every page. Pick a form page, a content page, and a page with a modal or menu. That covers most of the risk.

Where this fits into a real build

Accessibility is cheaper when it is part of the build, not a cleanup afterward. A few habits that pay off:

• Use semantic HTML first. Reach for ARIA only when there is no native element that does the job.
• Run the automated scan in your build pipeline so contrast and label regressions get caught before launch.
• Write alt text as you add images, not in a pass three months later.
• Test with a keyboard before every deploy. It takes ten minutes.

If you are working with a designer or developer on a new site, ask them how they test for accessibility. If the answer is “we run Lighthouse,” that is a start, but it is not enough. Most of what matters only shows up when you put the mouse down.

I do this kind of work regularly for small businesses and agencies, both local and remote. If you want a sense of how I approach builds end to end, my Long Island web design work covers the same ground: clean markup, real testing, no shortcuts.

FAQ

Do I legally have to make my website accessible?

In the U.S., the ADA does not spell out a web standard, but courts have consistently treated websites as places of public accommodation. WCAG 2.2 AA is the de facto benchmark used in settlements and in most procurement requirements. If you take government contracts or serve the public, treat it as required, not optional.

Can I just install an accessibility overlay widget and be done?

No. Overlays do not fix the underlying markup, and they have been named in lawsuits rather than preventing them. They can help in narrow cases, but they are not a substitute for accessible code. Fix the source.

How long does it take to make an existing site accessible?

It depends on size and how the site was built. A small marketing site with clean HTML is often a few days of work. A large site with custom components, modals, and forms takes longer, and the honest answer is that accessibility is ongoing maintenance, not a one-time project.