# Website Accessibility Audit for Small Businesses: Scope, Cost Drivers and Fixes

> What a website accessibility audit covers, what drives its cost, why automated scans aren't enough, and how a small Canadian business should fix what the audit finds.

Source: https://npcoding.ca/blog/website-accessibility-audit-small-business-canada/
Last updated: 2026-11-14

By NPCoding Team · Published 2026-11-14 · Web, SEO & Accessibility · 5 min read

A website accessibility audit answers one practical question: can people with disabilities actually use your site to do what your customers do? Can they find your hours, book, pay, or send a message? For a small business that question is easy to put off, because the site "works" when you click through it with a mouse. That's exactly the problem. You are not the person it fails.

This page explains what an audit covers, what moves its price, and how to deal with the findings without rebuilding everything.

## What an audit looks at

A proper audit tests your site against WCAG, the Web Content Accessibility Guidelines, at a stated level (most organizations aim for AA). In practice that means checking:

- **Keyboard use.** Can you reach every link, menu and button with the Tab key, see where you are, and get out of a pop-up again? Broken keyboard traps are among the most common serious faults.
- **Screen reader behaviour.** Do headings describe the page structure, do form fields have real labels, and does a button announce what it does rather than just "button"?
- **Visual presentation.** Colour contrast, text that still works when zoomed, and information that isn't conveyed by colour alone (a red border on an error, with no message).
- **Media.** Captions for video, transcripts for audio, and meaningful alt text on images that carry information.
- **Forms and errors.** Whether someone can tell what went wrong and how to fix it, without guessing.

The deliverable should be a list of issues tied to specific pages or components, each with its WCAG reference, severity, and a suggested fix. If you receive only a score or a generic PDF, you've bought a report that nobody on your team can act on.

## Why a free scan isn't an audit

Browser extensions and online checkers are worth running. They're quick, and they'll find missing form labels and weak contrast in seconds. But they can only detect what can be checked mechanically.

A scan will happily pass an image with the alt text "image1.jpg". It won't notice that your mobile menu opens but focus stays on the page behind it. It can't tell you that the date picker in your booking form is unusable without a mouse. Those are the problems that cost you customers, and they only show up when a person tests them by hand.

We'd run the scan first, because it clears the easy noise. Then we'd spend the real time on manual testing of the flows that matter.

## What drives the price

Anyone quoting a flat number before seeing your site is guessing. The things that actually change the scope:

1. **Page templates, not page count.** A hundred blog posts on one template are mostly one test. Five different layouts are five.
2. **Custom interactions.** Standard text pages are cheap to review. Mega menus, sliders, filters, calendars, chat widgets and checkout flows take much longer.
3. **Third-party embeds.** Booking tools, payment forms and review widgets often carry their own problems. You can't fix their code, but you can choose a different vendor or configure it differently, so they belong in the report.
4. **Target level and detail.** An audit that stops at "here's the list" costs less than one that includes fix guidance for your developers and a re-test.
5. **Retesting.** Ask whether verification after fixes is included or separate. It should happen either way.

Compare quotes by asking what's tested, by whom, with which assistive technologies, and what you get back. The cheapest option is often a scan with a logo on it.

## How to fix what it finds

The first instinct is to treat the list as a to-do list and start at the top. Don't. Triage by what blocks a core task.

**Fix first:** anything that prevents buying, booking, signing in or contacting you. A checkout that a keyboard user can't complete is more urgent than twenty missing alt attributes on decorative photos.

**Fix next:** problems that repeat across the whole site because they live in a template: the header, the navigation, the footer, the form components. One change in a shared component clears dozens of findings at once. This is where the effort pays off most.

**Schedule the rest:** content issues like vague link text ("click here"), heading levels that skip, and old PDFs. Your own team can often handle these once they know the pattern.

Be wary of overlay widgets that promise to fix everything with one line of script. They can't repair broken structure underneath, and some interfere with the assistive technology people already use. If your code is the problem, the code has to change.

Sometimes the honest answer is that the theme or page builder is the root cause and patching it will cost more than replacing the part. That's a decision about your platform, and our piece on [building a business website](https://npcoding.ca/blog/building-a-business-website/) covers what to look for if you're starting over.

## Legal context, briefly

If you operate in Ontario, the AODA sets website requirements for some organizations, depending on their size and sector. Our article on [AODA website accessibility in Ontario](https://npcoding.ca/blog/aoda-website-accessibility-ontario/) explains who is covered. Other provinces and federal rules differ, so confirm what applies to you with a qualified adviser rather than assuming either way. Legal duty is one reason to audit. It isn't the only one: people who can't use your site simply leave, and most will never tell you why. For the broader argument, see [why site accessibility matters](https://npcoding.ca/blog/site-accessibility-and-why-is-it-important/).

## When we would not start with an audit

If your site is about to be rebuilt, an audit of the old one is mostly wasted money. Put accessibility requirements into the new build brief instead, and test the new site before launch. Likewise, if the site is a single page with a contact form, a careful manual check by someone competent may be all you need.

Audits make the most sense when you have a live site that earns money, has grown over several years, and has never been tested by anyone using a keyboard or a screen reader.

## Making it part of normal testing

An audit is a snapshot. Next month someone adds a pop-up promotion or a new form plugin and you're partly back where you began. The fix is to fold accessibility checks into how you already test changes: keyboard pass, a quick screen reader pass on any new component, contrast checked in design. Our guide to [testing web applications effectively](https://npcoding.ca/blog/how-to-test-web-applications-effectively/) shows where those checks fit, and the same thinking sits behind our [QA testing service](https://npcoding.ca/services/qa-testing/).

Track it alongside your other site health measures too. If you're already watching the basics in [six numbers every business website should track](https://npcoding.ca/blog/business-website-six-numbers/), add a simple question next to them: did the last release break anything for keyboard users?

## Frequently asked questions

### What is a website accessibility audit?

It's a structured review of your site against a recognized standard, usually WCAG, combining automated scans with manual testing using a keyboard, a screen reader and zoom. The output is a list of specific problems, where they occur, why they matter and how to fix them, ordered by how badly they block people.

### Is a free automated accessibility scan enough?

No. Automated tools catch only a portion of issues, mostly the mechanical ones like missing alt attributes or low contrast. They can't tell you whether alt text is meaningful, whether the focus order makes sense or whether a checkout can be completed with a keyboard. Use a scan as a starting point, not a verdict.

### What drives the cost of an accessibility audit?

The number of distinct page templates, how much custom interaction the site has (forms, menus, checkout, booking widgets), the standard and level you're testing against, and how detailed you want the remediation guidance. A small brochure site and a store with accounts and payments are very different jobs. Ask any provider to scope by templates and flows, not by page count.

### Do we have to fix everything the audit finds right away?

Not necessarily at once, but you should triage. Fix whatever stops someone from completing a core task, such as buying, booking or contacting you, first. Lower-impact items can be scheduled. If you have legal obligations, for instance under AODA in Ontario, confirm with a qualified adviser what applies to your organization.

## Put this guide into practice

- [QA & Release Assurance](https://npcoding.ca/services/qa-testing/): AI-assisted test automation, independent validation, exploratory testing, AI-product evaluation and release confidence.
- [Web & Mobile App Development](https://npcoding.ca/services/application-development/): Web apps, mobile apps and customer portals built around the way your business actually works.
- [Application Security](https://npcoding.ca/services/application-security/): Security built into every sprint: threat modeling, secure code, testing and privacy-by-design.

Start a project: https://npcoding.ca/contact/?topic=build&service=qa&from=%2Fblog%2Fwebsite-accessibility-audit-small-business-canada%2F&type=article&id=website-accessibility-audit-small-business-canada&cta=article#enquiry

---

NPCoding · AI-powered software & app development · Toronto, Canada · support@npcoding.com · https://npcoding.ca/contact/
