HTML5 Accessibility: A Practical Guide for New York Business Websites (2026)

Most accessibility advice you find online is either a checklist with no code or a lecture about why it matters. Neither helps when you’re staring at a form that fails a screen reader. This is the version I wish someone had handed me years ago: what to actually write in your HTML, why each piece matters, and how to test it without buying anything.

I build and maintain sites for small businesses around Commack and the rest of Long Island, and accessibility comes up constantly because of ADA-related demand letters. The good news is that most of the fixes are cheap and permanent once you understand them.

Start with structure, not ARIA

The single biggest mistake I see is reaching for ARIA attributes before fixing basic HTML. ARIA is a patch for when native elements can’t do the job. If you use the right element, you usually don’t need it. The first rule of ARIA is literally “don’t use ARIA if a native HTML element will do.”

Use real landmarks. Screen reader users navigate by jumping between regions of the page, and they can only do that if the regions exist.

<header>
 <nav aria-label="Main">
 <ul>
 <li><a href="/services">Services</a></li>
 <li><a href="/contact">Contact</a></li>
 </ul>
 </nav>
</header>

<main>
 <h1>Roof Repair in Suffolk County</h1>
 <!-- page content -->
</main>

<footer>
 <p>&copy; 2026 Example Co.</p>
</footer>

Two things trip people up here. First, only one <main> per page. Second, if you have more than one <nav> (header and footer, say), give each an aria-label so the screen reader can tell them apart. Without labels they both just announce as “navigation,” which is useless.

Headings matter too. Don’t skip levels because the CSS looks wrong. Style an <h3> to look like a <h2> if you want, but keep the document outline logical. Screen reader users often pull up a heading list to skim your page the way sighted users skim visually.

Forms are where most sites fail

If you only fix one thing, fix your forms. Contact forms and checkout flows are where accessibility failures hurt the most, and they’re also where a demand letter is most likely to point.

Every input needs a programmatically associated label. A placeholder is not a label. A <div> next to the input is not a label.

<form action="/contact" method="post">
 <label for="email">Email address</label>
 <input type="email" id="email" name="email"
 autocomplete="email" required>

 <label for="message">How can we help?</label>
 <textarea id="message" name="message" rows="5"></textarea>

 <button type="submit">Send message</button>
</form>

Notice autocomplete="email". That’s not just a nicety. WCAG 2.2 added Success Criterion 3.3.8 (Accessible Authentication) and there’s a long-standing requirement that you help users avoid re-entering information. Autocomplete tokens like email, name, tel, and postal-code do a lot of quiet work.

When something goes wrong on submit, don’t just turn the border red. Announce the error, tie it to the field, and put focus somewhere useful.

<label for="zip">ZIP code</label>
<input type="text" id="zip" name="zip"
 aria-describedby="zip-error" aria-invalid="true">
<p id="zip-error" role="alert">
 Enter a 5-digit ZIP code, like 11725.
</p>

The aria-describedby link means a screen reader reads the error when the field receives focus. role="alert" makes it announce immediately when it appears. And aria-invalid="true" tells assistive tech the field is in an error state. Three attributes, big difference.

Focus management: the part everyone forgets

Keyboard users navigate by tabbing. If you build a custom dropdown, modal, or mobile menu, you own the focus behavior. The browser won’t do it for you.

• When a modal opens, move focus into it.
• Trap focus inside the modal while it’s open.
• When it closes, return focus to the button that opened it.
• Never remove the focus outline without replacing it with something visible.

That last one is the most common. Someone sets outline: none on everything because they don’t like the default blue ring. Now keyboard users are flying blind. If the default outline clashes with your design, replace it, don’t delete it.

:focus-visible {
 outline: 3px solid #005fcc;
 outline-offset: 2px;
}

Use :focus-visible rather than :focus here. It fires for keyboard navigation but not on mouse clicks, which is exactly the behavior people actually want. It’s supported everywhere that matters in 2026.

Color contrast and the 2026 reality

WCAG 2.2 requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (roughly 18pt or 14pt bold). This is measurable, not subjective. Open your browser’s dev tools, inspect a text element, and the contrast ratio is right there in the color picker. No excuse to guess anymore.

One thing that catches people: don’t use color alone to convey information. If a required field is marked only by making the label red, a colorblind user misses it. Add an asterisk with a legend, or the word “required.” Same goes for error states and status indicators.

There’s also the newer WCAG 2.2 criterion 2.4.11 (Focus Not Obscured). Sticky headers and cookie banners that cover the focused element are now a failure. If your site has a fixed header, test tabbing through and make sure the focused link isn’t hidden behind it. scroll-margin-top on your focusable elements fixes this cleanly.

Images, video, and the stuff that’s easy to skip

Every meaningful image needs alt text. Decorative images get alt="" (empty, not missing). The empty alt tells the screen reader to skip it, which is what you want for a background flourish or a spacer.

<!-- Informative -->
<img src="crew.jpg" alt="Two-person crew replacing shingles on a two-story house">

<!-- Decorative -->
<img src="divider.svg" alt="">

For video, captions are required for anything with speech. Auto-generated captions are a starting point, not a finished product. I’ve seen auto-captions turn “Suffolk County” into nonsense often enough to stop trusting them. Review and fix them, or use a service.

If you embed a YouTube or Vimeo player, check that the captions are actually enabled by default and that the player is keyboard operable. Some embed configurations break tab order, especially on mobile.

How to actually test this without spending money

You don’t need a $40,000 audit to catch 80% of problems. Here’s the routine I run on every project before launch:

• Keyboard only. Unplug your mouse. Tab through the whole page. Can you reach everything? Can you see where you are?
• Screen reader. VoiceOver on Mac (Cmd+F5), NVDA on Windows (free), or TalkBack on Android. Spend ten minutes listening to your homepage. It’s humbling.
• Zoom to 200%. WCAG requires text to be readable and functional at 200% zoom without horizontal scrolling. Most sites break here.
• Automated scan. axe DevTools (browser extension, free tier) or Lighthouse in Chrome. These catch maybe 30% of issues. Useful, not sufficient.
• Contrast checker. Built into dev tools. Just look.

Automated tools are a floor, not a ceiling. They’ll catch missing alt attributes and low contrast. They won’t catch a confusing tab order or a modal that traps focus wrong. That’s why the manual passes matter.

Where this fits into a real build

Accessibility isn’t a phase you bolt on at the end. When I do custom web development for clients here on Long Island, I bake it into the markup from the first commit: semantic structure, labeled forms, focus styles, and a test pass before anything goes live. Retrofitting it later costs three to four times as much, and it’s usually the reason someone calls me about a demand letter they didn’t see coming.

The technical fixes are the easy part. The hard part is building the habit of testing with a keyboard and a screen reader before you ship. Do that, and most of this becomes automatic.

FAQ

Do I legally have to make my New York website accessible?

New York State and New York City have both moved toward requiring accessibility for government and many public-facing sites, and federal ADA case law treats websites of businesses open to the public as covered. The practical answer is yes: it’s a real legal risk, and the fixes are cheap compared to a lawsuit. Talk to a lawyer about your specific situation, but the technical work is the same either way.

How much does it cost to fix an inaccessible site?

It depends entirely on how the site was built. A clean site with semantic HTML usually needs a few hours of small fixes. A site built with divs, images of text, and custom JavaScript widgets can take much longer. The audit itself is usually the smaller line item. Getting it right during a rebuild is almost always cheaper than patching afterward.

Is WCAG 2.2 the current standard in 2026?

Yes. WCAG 2.2 is the version to build against right now, and it’s backward compatible with 2.1. The new criteria in 2.2 (focus not obscured, dragging movements, target size, accessible authentication, consistent help) are the ones most existing sites miss. If you’re remediating an older site, start by testing those five specifically.