Website Accessibility Checklist for a Small-Business Build
By Parker Gawryletz · Local Cochrane Web Design · Last updated: · 8 min read
A small business website accessibility checklist covers eight areas: semantic structure, keyboard access, colour contrast, text alternatives for images and media, clear forms and errors, responsive zoom and touch targets, manual testing, and a written scope line. Use WCAG 2.2 Level AA, the W3C-published reference, as the technical standard to build against.
Accessibility is often treated as a compliance chore bolted on at the end. Built in from the start, it is simply good design: more people can read, navigate, and buy from your website. This small business website accessibility checklist gives you the items to confirm before and during a build.
It is written for owners procuring custom web design in Cochrane and anywhere else — practical checks rather than legal analysis, so you can hold any provider to a clear, testable standard.
The short answer
- Build to WCAG 2.2 Level AA, the W3C-published technical reference.
- Every page must work by keyboard alone, with a visible focus indicator.
- Contrast, alt text, labelled forms, and clear errors are non-negotiable basics.
- Automated tools catch some issues; keyboard and zoom tests are manual.
- Name accessibility in the written scope so it is testable at launch.
Accessibility is usability and risk reduction
An accessible website works for more of your customers: people using keyboards, screen readers, zoomed text, or a phone in bright sun. That widens your audience and reduces the risk of complaints and rework. Legal obligations vary by jurisdiction, so treat accessibility as good practice first and confirm obligations separately.
For a small business, the practical case is simple: the same choices that help a screen-reader user — clear headings, labelled forms, readable contrast — help every hurried visitor on a small screen. When you shortlist providers, ask each one how they handle accessibility; the Cochrane web design companies compared guide covers the other questions worth asking side by side.
Use WCAG 2.2 as the technical reference
WCAG 2.2 is the W3C-published Web Content Accessibility Guidelines, organised around four principles: content must be perceivable, operable, understandable, and robust. Level AA is the widely used target for business websites. Naming "WCAG 2.2 Level AA" in your scope gives both sides one testable standard.
The guidelines read as technical criteria, but each one maps to a plain question about a real visitor. The checklist below groups the essentials under the four principles.
Perceivable
- ☐ Text contrast meets AA ratios against its background
- ☐ Every meaningful image has alt text; decorative images are marked decorative
- ☐ Information is never conveyed by colour alone
Operable
- ☐ Every feature works by keyboard alone, in a logical order
- ☐ Focus is always visible as you tab through the page
- ☐ Touch targets are large enough to tap without precision
Understandable
- ☐ Headings and labels describe what follows
- ☐ Forms give clear instructions and name errors in plain language
- ☐ Navigation stays consistent from page to page
Robust
- ☐ Pages use valid, semantic HTML that assistive technology can parse
- ☐ Custom controls expose their name, role, and state
- ☐ The site works across current browsers and screen readers
Semantic structure and heading order
Every page needs one H1, headings that step down in order without skipping levels, and native HTML elements — real buttons, real links, real lists. Screen readers navigate by structure, so a page styled to look organised but built from generic containers is unreadable to the people who rely on it.
Structure is also free SEO: the same heading order that guides a screen reader tells search engines what the page covers. Ask your designer to show you the heading outline of a finished page — it should read like a table of contents.
Keyboard access and visible focus
Every action on the site — menus, forms, sliders, popups — must work with a keyboard alone, in a logical tab order, with a visible outline showing where you are. Removing the focus outline for aesthetics is a common defect; a build should style the focus state, never delete it.
Keyboard access is the fastest health check you can run yourself. Press Tab through a page: you should see where you are at every step, reach every control, and never get trapped inside a widget with no way out.
Color contrast and non-color cues
Text needs enough contrast against its background to stay readable — WCAG's AA criteria set the ratios — and no information should depend on colour alone. An error shown only by a red border fails; an error shown with a border, an icon, and a written message works for everyone.
Contrast is where brand palettes and accessibility most often collide. Resolve it at the design stage: a slightly darker grey chosen in the mockup costs nothing, while a contrast fix after launch touches every page. Free contrast checkers make each colour pairing a thirty-second test.
Images, icons, audio and video alternatives
Every meaningful image needs alt text that describes its purpose, decorative images should be marked so screen readers skip them, icon-only buttons need accessible names, and video needs captions with a transcript where practical. The test is simple: does the page still make sense with the media removed?
Alt text describes function, not just appearance. For a photo of your storefront, name the business and place; for a linked icon, say where the link goes. Whoever writes your content should own this line — and the scope should say who that is.
Forms, errors and instructions
Every form field needs a visible label that stays on screen, instructions placed before the field rather than hidden in placeholder text, and error messages that name the field and explain the fix in plain language. Your contact form is the conversion point — it should be the most accessible thing on the site.
Test the failure path, not just the happy path. Submit the form empty: errors should appear as text, near the fields, and be announced to assistive technology — never as a silent red outline. A form that fails politely earns enquiries an inaccessible form quietly loses.
Responsive zoom and touch targets
The site should stay usable when text is zoomed to 200 percent, without content overlapping or disappearing, and interactive targets should be comfortably tappable on a phone. Nothing should require horizontal scrolling on a mobile screen, and pinch-zoom should never be disabled in the page settings.
Zoom, touch, and speed are one experience on a phone. A slow page magnifies every other barrier, which is why performance belongs beside accessibility in the same scope — the numbers to ask for are in website performance requirements.
Manual tests automated tools miss
Automated scanners catch code-level issues like missing alt attributes and low contrast, but they cannot judge whether alt text makes sense, whether the tab order is logical, or whether error messages actually help. A launch checklist needs manual tests: keyboard-only navigation, zoom, and a screen-reader pass on key pages.
- ☐ Tab through every page: visible focus, logical order, no traps
- ☐ Zoom text to 200 percent and confirm nothing overlaps or disappears
- ☐ Read key pages with a screen reader, or watch your provider do it
- ☐ Submit each form empty and check the errors are clear and announced
- ☐ Read every alt text aloud and ask whether it describes the purpose
How to document accessibility in the scope
Put accessibility in the written scope as a named, testable line: the standard targeted (WCAG 2.2 Level AA), what will be tested and how, and who fixes issues found after launch. A scope line makes accessibility a deliverable you can verify, instead of a good intention that quietly disappears.
One sentence in the agreement does most of the work: "The site targets WCAG 2.2 Level AA, verified by keyboard, zoom, and contrast checks on real devices before launch." Verification on real devices before launch is a standard our own written guarantee commits to, and a fair one to ask of any provider. Where that line sits among the other line items is covered in what a web design quote should include.
Frequently asked questions
Does my small business website need to be accessible?
As general information: an accessible website reaches more customers, works better on every device, and reduces the risk of complaints and expensive rework. Whether a legal obligation applies depends on your jurisdiction and business type, so confirm that with a lawyer — but the usability case applies to every business.
What is WCAG 2.2?
WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, published by the W3C. It organises accessibility into four principles — perceivable, operable, understandable, robust — with testable success criteria at levels A, AA, and AAA. It is the standard reference for accessible website builds.
What accessibility level should I target?
WCAG 2.2 Level AA is the widely used target for business websites. Level A alone leaves significant barriers in place, while AAA is difficult to meet across an entire site. Name Level AA in your written scope so the build has one clear, testable standard from the start.
How do I test keyboard navigation?
Put the mouse aside and press Tab through each page. You should see a visible focus indicator at every step, reach every link, button, menu, and form field in a logical order, activate controls with Enter or Space, and close any popup with Escape without getting trapped.
What should alt text describe?
Alt text should describe the purpose of the image in its context — what a visitor loses if the image does not load. For a linked image, describe the destination. Decorative images should carry empty alt text so screen readers skip them. Keep it specific, natural, and brief.
Are automated accessibility tools enough?
No. Automated scanners catch a share of issues — missing alt attributes, low contrast, unlabelled fields — but they cannot judge meaning, logical order, or whether errors actually help a person recover. Pair automated checks with manual keyboard, zoom, and screen-reader tests on your most important pages.
Sources
Request an accessibility-ready scope — a custom build scoped in writing to WCAG 2.2 Level AA, with keyboard, zoom, and contrast checks verified on real devices before launch.