You do not need a consultant to find most of what is broken on a small business site. A useful website accessibility audit is five passes you can run yourself in an afternoon with a keyboard, a browser, and a color picker. What follows is the sequence, the thresholds to measure against, worked examples of the failures you will actually hit, and a rule for sorting findings into fix-now and fix-later.
Scope it before you start. Pick five to eight pages: your home page, your top service or product page, pricing, the contact form, one blog post, and the booking or checkout flow if you have one. Auditing every page is how this project dies in week two. Fix patterns on representative pages and the fixes usually propagate, because most of a site is the same header, footer, and template repeated.
Set Up Your Website Accessibility Audit in Ten Minutes
Open a spreadsheet with these columns: page URL, what is wrong, where on the page, which pass found it, severity, owner, status, date retested. Every finding gets one row. If a finding is not written down with a location specific enough for someone else to reproduce it, it will not get fixed.
Then run one automated scan per page with a browser checker such as Lighthouse, WAVE, or axe DevTools. Treat the output as a starting inventory, not a verdict. Automated tools reliably catch a narrow band of problems: missing alt attributes, missing form labels, empty buttons, and contrast on plain text. They cannot tell you whether alt text is meaningful, whether tab order makes sense, or whether an error message explains what to do. That judgment is the manual passes below.
One warning about clean scans. A page can pass an automated check and still be unusable with a keyboard. Do not stop at the green score.
Pass One: Navigate With the Keyboard Only
Push the mouse out of reach. Click once in the browser address bar, then press Tab repeatedly through the whole page. You are checking five things.
- Reach. Can you land on every link, button, form field, menu toggle, slider control, and modal close button?
- Visibility. Can you always see where you are? If focus vanishes for several presses, something is either hidden behind a sticky header or has had its outline removed in CSS.
- Order. Does focus move in the order things appear on screen? Flex and grid layouts often reorder visually while the DOM order stays the same.
- Activation. Does Enter follow links and do Enter and Space press buttons? Does Escape close menus, dropdowns, and dialogs?
- Escape. Can you always get back out? Tab into an embedded video or a chat widget and try to tab out again. If you cannot, that is a keyboard trap and it is a blocker.
The most common failure on small business sites is a mobile menu toggle built as a div with a click handler. It looks like a button, but it never receives keyboard focus, so keyboard users cannot open the navigation at all. The fix is a real button element. Retest immediately after.
The second most common failure is a newsletter dialog that appears on load. Check that focus moves into it when it opens, stays inside while it is open, closes on Escape, and returns to the element that triggered it.
Pass Two: Measure Contrast Instead of Judging It
Contrast is the one part of this you should never eyeball. Use the eyedropper in your browser’s color picker, which reports the ratio directly. The WCAG 2.1 AA thresholds are:
- 4.5:1 for normal body text.
- 3:1 for large text, meaning about 24px regular or about 19px bold.
- 3:1 for meaningful non-text elements: icons that carry information, input borders, and focus indicators.
Check placeholder text, footer text, secondary buttons, link text inside colored callouts, text sitting on hero images, and the focus ring itself. Light gray on white and white on a brand yellow or orange are the usual offenders.
When the failing color is your brand color, you do not have to rebrand. Add one darker variant of that hue to your palette and use it only where the color meets text or a button background. Keep the original for logos and large display headlines. Logos are exempt from the contrast requirement, and headlines above 24px only need 3:1.
Text over photos is the other hard case. A gradient scrim or a solid color overlay behind the text block is more reliable than a text shadow, because the shadow does not change the measured ratio.
Pass Three: Alt Text That Actually Says Something
Alt text is not a description contest. It should give a non-visual reader the same information the image gives everyone else, and nothing more.
- Decorative image — dividers, background textures, stock photos beside text that already says everything: use alt=““. An empty alt is correct and intentional. A missing alt attribute is not; screen readers may fall back to reading the filename.
- Informative image — describe what matters. Not „team photo“ but „Three technicians in branded uniforms beside a service van.“
- Image used as a link or button — describe the destination or action, not the picture. A logo linking home should read „Riverside Plumbing, home.“
- Text inside an image — repeat the text verbatim.
- Chart or infographic — state the takeaway in the alt, and put the underlying numbers in nearby HTML text or a table.
Keep most alt text under roughly 125 characters. If you need more than that, the content belongs in the page, not in an attribute. And never keyword-stuff alt text; it reads as noise out loud and helps nobody.
Pass Four: Forms, Labels, and Error Messages
Forms are where accessibility failures cost you money directly, because a blocked form is a lost inquiry.
Every input needs a visible label element tied to it with matching for and id values. A placeholder is not a label: it disappears the moment someone types, it is usually below contrast minimums, and it is not reliably announced. Group related radio buttons or checkboxes inside a fieldset with a legend so the question is announced with the options.
Mark required fields in text, such as „Email (required),“ rather than relying on a red asterisk alone. Add autocomplete attributes to name, email, phone, and address fields so browsers can fill them in.
Then test the failure path, which almost nobody does. Submit the form empty using only the keyboard and answer three questions: Does the page tell you in words which fields failed and why? Does focus move to that message or to the first bad field? Would you still understand the errors if you could not see color at all? A red border with no text fails all three.
If you use a captcha, make sure there is a non-visual alternative. If the form times out, warn the user and let them extend it.
Triage: What to Fix Now and What to Schedule
You will finish with more findings than you can fix this week. Score each row as a blocker, a major issue, or a minor one. A blocker means a task cannot be completed at all: a keyboard trap, an unreachable navigation toggle, an unlabeled checkout field. A major issue means the task is possible but painful, like poor focus visibility. A minor issue is inconsistent or cosmetic.
Then apply one rule. Fix now: every blocker anywhere on a path that leads to contact, booking, or payment, plus every cheap fix regardless of severity — alt text, labels, a darker color token, restoring focus outlines. Fix later: component rewrites, third-party widgets, legacy PDFs, and anything needing a developer sprint. Give each later item a date and an owner, or „later“ becomes „never.“
For third-party chat, booking, or review widgets you cannot edit, log the vendor, open a support ticket, record their reply, and publish a plain fallback such as a phone number and email address next to the widget.
Retest every fix with the same pass that found it and date the row. If you want the columns, severity scale, and per-page checklists already built, the Website Accessibility QA & Remediation Tracker pairs a 12-page QA guide with a 9-sheet Excel tracker and supporting checklists so you are not designing the spreadsheet while you audit.
One last caution. If you use an AI tool to draft alt text or suggest ARIA attributes, review every line before it ships — incorrectly applied ARIA is worse than none at all. The same habits in this checklist for evaluating AI output apply here: check the claim, check the context, then ship.
Run these five passes once, fix the blockers, and put the keyboard pass into your release checklist so new pages get checked before they go live. If you would rather work from prepared checklists and a tracker than build your own, the accessibility tracker above and the rest of the Cursiqa workbook shop are a reasonable next step.