Accessible Website Development: A Practical Guide for 2026

Most accessibility advice stops at “add alt text and use good contrast.” That is the easy 10%. The hard part is everything you have to get right before a site actually works for someone using a screen reader, a keyboard, or a switch device. I have been building sites for years, mostly for small businesses around Commack and the rest of Long Island, and the accessibility problems I find are almost never about effort. They are about not knowing where the real traps are.

Here is what actually matters, in the order I would fix it.

Start with semantic HTML, not ARIA

The single biggest accessibility win is also the cheapest: use the right element for the job. A <button> is focusable, clickable with Enter and Space, and announced as a button. A <div> with a click handler is none of those things unless you rebuild all of it by hand. Most of the time people reach for ARIA, they should have reached for a native element instead.

The first rule of ARIA is that you do not use ARIA if a native HTML element will do the job. This is not a style preference. Screen readers, browser focus behavior, and mobile assistive tech all key off the native semantics. When you fake it with roles, you inherit the job of maintaining that behavior forever.

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

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

Same idea for landmarks. Wrap your main content in <main>, your navigation in <nav>, and your footer in <footer>. A screen reader user can then jump straight to the main content instead of tabbing through your entire header on every page load.

Keyboard access is non-negotiable

Unplug your mouse and try to use your own site. If you cannot reach a link, open a menu, or close a modal, you have a keyboard trap or a focus problem. This is the failure I see most often, and it is usually caused by one of three things:

• A custom dropdown that only responds to mouse events
• A modal that does not move focus into itself or return focus when it closes
• A tabindex value greater than zero, which scrambles the natural tab order

Fix the modal focus with a small amount of JavaScript. Trap focus inside the dialog while it is open, and send it back to the trigger when it closes:

const dialog = document.querySelector('#my-dialog');
const trigger = document.querySelector('#open-dialog');

function openDialog() {
 dialog.showModal(); // native modal, handles focus + Esc
 trigger.setAttribute('aria-expanded', 'true');
}

function closeDialog() {
 dialog.close();
 trigger.setAttribute('aria-expanded', 'false');
 trigger.focus(); // return focus where it came from
}

The <dialog> element with showModal() gives you focus trapping and Escape-to-close for free in every current browser. There is no reason to hand-roll a modal in 2026.

Contrast and text sizing

WCAG 2.2 requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt, or 14pt bold). That is the floor, not the goal. Thin gray text on white looks stylish in a mockup and is unreadable for a lot of people. Test it with a real contrast checker before you ship, not by eyeballing it.

Two things people forget:

• Never disable zoom. The old user-scalable=no meta tag breaks pinch-to-zoom on mobile and fails accessibility guidelines outright.
• Respect the user’s font-size settings. If you set font-size in pixels on the root and never use relative units, you override the browser preference a low-vision user set on purpose. Use rem for text.

html { font-size: 100%; } /* respects browser default */
body { font-size: 1rem; } /* scales with user settings */
h1 { font-size: 2rem; } /* relative, not fixed px */

Forms are where accessibility quietly breaks

A form field without a properly associated label is invisible to a screen reader. Placeholder text is not a label. It disappears the moment someone starts typing, and it is often low contrast by design.

<!-- Associate the label with the input -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">

<!-- When there's a validation error, announce it -->
<p id="email-error" role="alert">Please enter a valid email.</p>
<input type="email" id="email" aria-describedby="email-error">

The role="alert" on the error message tells assistive tech to announce it the moment it appears. Without it, a screen reader user submits the form, nothing seems to happen, and they have no idea what went wrong.

Test with real tools, not vibes

Automated tools catch roughly a third of accessibility issues. They are useful for the mechanical stuff (missing alt attributes, contrast, duplicate IDs) but they cannot tell you whether your alt text actually describes the image or whether your tab order makes sense. Use both:

• Automated: axe DevTools, Lighthouse’s accessibility audit, Pa11y in your CI pipeline
• Manual: work through the whole site with keyboard only, then run it through a screen reader (VoiceOver on Mac, NVDA on Windows, both free)

If you want a second set of eyes, the WAVE browser extension is the fastest way to spot structural problems on a live page without touching code.

Why this matters for a small business site

Accessibility is often framed as a legal checkbox, and in New York it increasingly is one, since courts have been consistent that ADA rules apply to business websites. But the practical case is simpler. Roughly one in four adults lives with some form of disability. If your site is hard to use, those are customers who leave. A clean, accessible site is also a faster, better-structured site, which helps your search rankings at the same time.

If you are weighing whether to fix an existing site or rebuild, that is a conversation worth having early. I do a lot of that work as a Long Island web design project, and the honest answer is usually that fixing the structure is cheaper than a full rebuild unless the underlying code is a mess.

FAQ

Do I need ARIA to make my site accessible?

Almost never. Native HTML elements already carry the semantics and behavior assistive tech needs. Reach for ARIA only when no native element fits, and never to patch a problem you could fix by using the right tag.

How much contrast do I actually need?

WCAG 2.2 sets the minimum at 4.5:1 for normal text and 3:1 for large text. Treat those as a floor. Body text at 4.5:1 is readable but not comfortable, so aim higher for anything people read in long stretches.

Will making my site accessible hurt the design?

No. Good contrast, real focus states, and semantic markup do not conflict with a clean look. They conflict with low-effort shortcuts. Every accessible site I have built looks the same or better than the version before it.