Accessible Website Design: A Practical Guide for Small Business Sites in 2026

Most accessibility advice I see for small businesses is either a vague pep talk or a 40-point compliance checklist nobody will ever finish. The truth is simpler: a handful of real fixes cover the vast majority of problems on a typical brochure or service site. Here is what actually matters and how to do it in code.

Start with semantics, not ARIA

The single biggest source of broken accessibility is div soup. If you build a button out of a div, you have to manually re-add keyboard focus, Enter and Space handling, and screen reader role. A real <button> gives you all of that for free. Use the right element and most of your problems disappear before you write a line of CSS.

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

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

Same rule for links vs buttons. A link navigates somewhere. A button does something on the page. Screen reader users (and keyboard users) rely on that distinction to know what to expect. If it goes to a new URL, it is an <a>. If it submits a form or opens a menu, it is a <button>.

Headings are a document outline, not a font size

I still see pages where every section title is an <h3> because it “looked right.” Headings are how screen reader users jump around a page. They should descend in order: one <h1> for the page, <h2> for major sections, <h3> for subsections. If you want a smaller heading, change the size with CSS, don’t change the level.

• One <h1> per page that describes what the page is.
• Never skip levels to get a visual size. Use CSS for that.
• Do not use a heading just to make text bold. Use <strong>.

Color contrast: the fastest win

Low-contrast gray text on white is everywhere, and it is the most common failure I find on small business sites. WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal body text and 3:1 for large text (roughly 24px, or 18.66px bold). Placeholder text inside form fields has to meet the same bar, and it almost never does.

You do not need to guess. Chrome DevTools shows the contrast ratio right in the color picker, and it flags failures. Fix the token once in your design system and it propagates everywhere.

/* Fails at 2.8:1 on white */
.muted { color: #9aa0a6; }

/* Passes at 4.6:1 on white */
.muted { color: #6b7280; }

Focus states are not optional

Plenty of CSS resets still kill the focus outline with outline: none. That makes a site unusable by keyboard. If the default ring clashes with your design, replace it, don’t delete it. Use :focus-visible so mouse users don’t see a ring on every click but keyboard users always do.

a:focus-visible,
button:focus-visible,
input:focus-visible {
 outline: 3px solid #1d4ed8;
 outline-offset: 2px;
 border-radius: 2px;
}

Test it yourself right now: load your homepage and press Tab. If you lose track of where you are, so will everyone else.

Forms: labels, errors, and the things that break

Forms are where accessibility failures cost you real money, because an inaccessible form is an abandoned lead. Three rules cover most of it.

• Every input gets a real <label> tied by for and id. A placeholder is not a label.
• Errors must be announced, not just colored red. Color alone is not enough for anyone who is colorblind.
• Group related inputs with <fieldset> and <legend>, especially radio buttons and checkboxes.

<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 role="alert" makes screen readers announce the message the moment it appears. Pair that with a visible error style and you have covered both audiences.

Images, video, and motion

Every meaningful image needs an alt attribute. Decorative images get an empty one (alt="") so screen readers skip them. Do not stuff keywords into alt text. Describe what the image shows in the context of the page.

For video, captions are the baseline. Auto-playing background video should be muted, and you should honor the user’s motion preference. Some people get genuinely sick from parallax and heavy scroll animation.

@media (prefers-reduced-motion: reduce) {
 *, *::before, *::after {
 animation-duration: 0.01ms !important;
 animation-iteration-count: 1 !important;
 transition-duration: 0.01ms !important;
 scroll-behavior: auto !important;
 }
}

A realistic testing routine

You do not need to be an expert to catch 90 percent of issues. I run this on every site I ship, and it takes about twenty minutes.

• Tab through the whole page. Can you reach and activate everything, and can you always see where you are?
• Run an automated checker. Lighthouse in Chrome, or axe DevTools, catches contrast, missing labels, and landmark issues. It will not catch everything, so treat it as a floor, not a finish line.
• Turn on a screen reader. VoiceOver on Mac (Cmd+F5), NVDA on Windows. Just read one page. It is eye-opening.
• Zoom to 200 percent. Nothing should overlap or get cut off.

Automated tools catch roughly a third of real issues. The manual passes are what separate a site that technically passes a scan from one a person can actually use.

Why this matters for a local business

On Long Island, a meaningful slice of your customers are older, and a lot of them are dealing with declining vision or motor control. Accessible design is not charity, it is just good business on a population that is aging into needing it. If you are weighing a rebuild, the same care that makes a site accessible also tends to make it faster and easier to maintain, which is why I fold it into my Long Island web design work from the first commit rather than bolting it on later.

And there is a legal angle. Courts have consistently held that websites fall under ADA obligations, and demand letters are common. Fixing the basics above is cheap. Defending a complaint is not.

FAQ

Do I need to be WCAG AA compliant?

There is no law that says “WCAG AA or else” for a private small business, but AA is the standard courts and auditors reference. Practically, hitting the items in this article gets you most of the way there. Full AA across a large site is a project, not an afternoon.

Is a WordPress accessibility plugin enough?

No. Plugins can fix some output, but they cannot fix a form with no labels, images with no alt text, or a theme that hides focus outlines. The fixes belong in your content and your theme, and plugins are at best a supplement.

How much does it cost to fix an existing site?

It depends entirely on how the site was built. A clean theme with the issues above might be a day of work. A page-builder site with hundreds of pages and no consistent structure can take much longer, because the problems are scattered across content, not code. An audit first tells you which situation you are in.