A Practical Accessibility Checklist for Small Business Sites

18 February 2026 Accessibility

Full WCAG conformance is a genuine undertaking, and most small business sites don't need to start there. What they do need is to stop excluding visitors over fixable, well-understood problems. Here's a realistic starting list — the sort of thing worth checking on any site before worrying about the more exhaustive stuff.

This isn't only about avoiding a legal complaint, though that risk is real and growing. It's that a meaningful share of visitors — people using screen readers, keyboard-only navigation, screen magnification, or simply an older phone with a cracked screen in bright sunlight — will quietly leave and go to a competitor's site the moment yours fights them. Most of the fixes below take an afternoon, not a redesign.

Colour & contrast

• Body text should meet at least a 4.5:1 contrast ratio against its background.
• Don't use colour as the only way to convey information — a red error message also needs an icon or text label.
• Check contrast in both light and dark themes if you offer both — they don't automatically inherit each other's contrast.

Keyboard access

• Every interactive element — links, buttons, form fields, custom widgets — needs to be reachable and operable with Tab and Enter/Space alone.
• Focus states need to be visible. Removing the default outline without replacing it is one of the most common accessibility regressions.
• Modals and menus should trap focus while open and return it to the trigger element when closed.

Images & media

• Meaningful images need descriptive alt text; purely decorative images should have empty alt attributes so screen readers skip them.
• Don't embed important text inside images — it can't be read by assistive tech, translated, or resized.
• Alt text should describe the image's purpose in context, not just its literal contents — "Golden retriever being groomed at our Truro salon" beats "dog" every time.
• Video content needs captions, and any autoplaying video needs an easy, obvious way to pause it.

Forms

• Every input needs a properly associated label, not just a placeholder. Placeholder text disappears the moment someone starts typing, and isn't reliably announced by every screen reader in the first place.
• Error messages should be programmatically linked to their field and announced, not just shown visually in red.
• Required fields should be indicated in a way that isn't purely visual (colour or asterisk alone).
• Group related fields (like a set of radio buttons) with a <fieldset> and <legend> so the relationship is announced, not just visually implied.

Motion & animation

Animation can make an interface feel polished, but for some visitors — particularly those with vestibular disorders — large-scale motion can trigger genuine physical discomfort, not just mild annoyance.

• Wrap non-essential motion in a @media (prefers-reduced-motion: reduce) query and either remove it or scale it right down for visitors who've set that preference at the OS level.
• Avoid auto-playing carousels and looping background video as a default — if you use them, give visitors an obvious way to pause.
• Flashing content is a hard no — anything that flashes more than three times a second is a seizure risk, not just a design choice.

ARIA: use sparingly, not liberally

ARIA attributes are powerful, but the first rule of ARIA is genuinely "don't use ARIA if a native HTML element already does the job." A <button> is keyboard-accessible, focusable and announced correctly by default — a <div role="button"> needs you to manually replicate all of that, and it's easy to miss a piece.

• Reach for semantic HTML first; add ARIA only to fill gaps native HTML genuinely can't cover (a custom tab panel, a live region for dynamic status updates).
• An incorrect aria-* attribute is often worse than none at all — it tells assistive tech something confidently wrong rather than letting it fall back to sensible defaults.
• If you find yourself adding several ARIA attributes to a plain div, stop and check whether a native element would get you there with less code and less risk.

Structure

• Use real heading levels (h1–h6) in logical order — don't skip levels just to get a font size.
• Use semantic HTML elements (nav, button, main) instead of styled divs wherever the native element already does the job.
• Give the page a single, accurate <h1>, and make sure the <title> and heading actually describe the page they're on.

Testing without expensive tools

A proper audit uses specialist software and real assistive-tech users, but a surprising amount can be caught with tools already on your machine:

• Unplug the mouse. Tab through the entire page. If you can't reach something, or can't tell where focus currently is, that's a real bug a real visitor will hit.
• Turn on a screen reader for ten minutes. VoiceOver (built into macOS/iOS) and NVDA (free, on Windows) are both free to try. Listen to how your homepage and your main form actually get read out.
• Zoom the browser to 200%. If content overlaps, gets cut off, or becomes unusable, that's a real problem for visitors with low vision who browse zoomed in as standard.
• Run an automated scanner like Lighthouse or axe DevTools as a baseline — it won't catch everything, but it catches the obvious stuff instantly and for free.

None of this requires a specialist audit to start on. Working through a list like this catches a large share of the accessibility issues that quietly turn visitors away — and it usually improves usability for everyone else too.

← Back to the blog