Website Accessibility Checklist for Small Business Owners
Web accessibility means building a site so that people with a wide range of abilities can perceive it, understand it and use it. The W3C describes the group as including people with visual, auditory, physical, speech, cognitive and neurological disabilities. It also covers older people whose abilities change with age, people with a broken arm or misplaced glasses, and anyone reading a phone screen in bright sunlight.
For a small business that is a practical question: can a customer find your phone number, read your prices and submit your enquiry form? This guide uses the W3C Web Content Accessibility Guidelines (WCAG) 2.2 as the yardstick. It lists eight checks you can run yourself in under an hour, a short test routine, and the fixes to pass to a developer. Laws on accessibility differ from country to country.
What accessibility looks like in practice
Think of the real people behind the guidelines. Someone using a screen reader hears your page read aloud, so they depend on image descriptions, headings and form labels. Someone who cannot use a mouse moves through the page with the Tab key, or a switch device that behaves like a keyboard. Someone with low vision zooms in, and someone with colour blindness may miss a red error message if colour is the only clue.
Then there are the everyday cases: an older customer who finds grey text on white hard to read, a person with a tremor who keeps tapping the wrong tiny link, a shopper on a small phone outdoors at noon.
Eight checks you can do without a developer
1. Text contrast. WCAG 2.2 level AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Buttons, form field borders and icons need at least 3:1 against what sits next to them. Paste your brand colours into any free contrast checker and note the failures. Pale grey body text and white text on a light brand colour fail most often. 2. Alternatives for images and video. Every image that carries information needs a text alternative that serves the same purpose, so a product photo is described by what the buyer needs to know. Prerecorded video with sound needs captions (level A). 3. Heading structure. Headings should describe the topic beneath them, and the page structure should be real headings rather than bold text that only looks like one. Skim the page: do the headings alone read like a sensible outline? 4. Keyboard use and visible focus. Everything that works with a mouse must work from the keyboard (level A), and you must be able to see where you are while tabbing (level AA). WCAG 2.2 adds that the focused item must not be entirely hidden by something you added, such as a sticky banner or a cookie bar. 5. Form labels and error messages. Every field needs a visible label or instruction (level A). When a mistake is detected, the field in error must be identified and the problem described in text (level A). A red border alone does not count. 6. Link text. The purpose of a link should be clear from its text, so avoid repeated links reading click here or read more. Try Contact our service team or Download the 2026 price list instead. 7. Touch target size. WCAG 2.2 level AA asks for tap targets of at least 24 by 24 CSS pixels, with exceptions such as enough spacing around a smaller target, links inside a sentence, and controls sized by the browser. Notice what you mis-tap on your own phone. 8. Zoom and reflow. Text must be resizable up to 200 percent without losing content or function (level AA). At 320 CSS pixels wide, content should not need scrolling in two directions (level AA). Zoom your browser and see whether menus, buttons and forms still work.
A five-minute test routine
Start with the keyboard pass. Put your mouse aside, load your home page and press Tab repeatedly. You should see a clear marker moving through links, buttons and fields in a logical order. Open the menu, fill the enquiry form and submit it using only the keyboard. If you get stuck, or you lose sight of the marker, note the spot.
Next, zoom the browser to 200 percent and repeat the main task, then shrink the window to phone width. Run a free automated checker on your key pages and write down what it flags. Finally, spend two minutes with a screen reader: VoiceOver on Mac and iPhone, TalkBack on Android and NVDA on Windows are free. Listen to the first screen. If the headings, links and form fields make sense with your eyes closed, that is a good sign.
What to ask a developer to fix
Some problems sit in the code or the theme, not the content. Hand these over with your notes from the test: brand colours that fail contrast, a focus marker removed by the stylesheet, menus and pop-ups that cannot be reached or closed by keyboard, fields with no programmatic label, error messages that appear only as colour, and tap targets that are too small. Ask also for the page language to be set in the code, because screen readers use it to pick the right voice.
Give the developer the criterion you are citing, for example 2.4.7 Focus Visible or 2.5.8 Target Size (Minimum), and the page address.
What automated tools cannot catch
The W3C is plain about this: tools cannot check all accessibility aspects automatically, and human judgement is required. An automated checker can see that an image has no description. It cannot judge whether the description is useful, whether a heading is accurate, or whether captions match what is spoken. It can also give false or misleading results, so treat its report as a prompt to look, not a verdict.
The keyboard pass, the zoom test and the two minutes with a screen reader fill that gap. The best check is a real person with a disability trying to complete a task on your site, if you can arrange it. Repeat the routine after any redesign.
Sources and further reading
Frequently asked questions
Which WCAG level should a small business aim for?
Level AA is the usual target, and it is the level the checks in this guide mostly refer to. It includes the 4.5:1 text contrast ratio, visible keyboard focus, 200 percent text resize and the 24 by 24 CSS pixel target size. Level A items, such as keyboard access, captions and form labels, are the starting point.
Can a free automated checker tell me if my site is accessible?
No. Automated tools are good at flagging missing descriptions or low contrast, but the W3C notes they cannot check every aspect and need human judgement. Use them to find quick wins, then run the keyboard, zoom and screen reader tests.
Do I need to rebuild my website to fix accessibility problems?
Usually not. Many fixes are content edits, such as image descriptions, link wording, captions and heading order. Others are small code or theme changes, like contrast, focus styling and button size. A rebuild is only needed if the structure itself blocks keyboard or screen reader use.
Does accessibility only help people with disabilities?
No. The W3C notes it also helps older people, people on small screens, people in bright sunlight or places where they cannot play audio, and people with slow connections. Clear labels, readable text and large tap targets help every visitor.
Have something worth building?
Tell us what you're trying to make happen. We'll reply with a plan, not a brochure.
Start a project