If you are about to pay someone to make your business website “ADA compliant” or “WCAG compliant,” do not start with the badge, widget or score they are selling.
Start with a simpler question:
Can a real customer with a disability complete the important things your website exists to help them do?
For a clinic, that may mean finding a service and requesting an appointment. For a hotel, checking rooms and starting a booking. For a consultant, understanding the offer and submitting an enquiry. For an online store, finding a product and completing checkout.
That is the useful way to approach a website accessibility audit: test barriers around real customer journeys, use automated tools where they are strong, and use human testing where judgement is required.
This is technical and product guidance, not legal advice. Accessibility laws differ by country and business context.
First, understand what an accessibility scan can and cannot tell you
Automated scanners are useful. They can quickly surface machine-detectable problems such as some missing accessible names, contrast failures, invalid markup patterns and form-label issues.
But a clean scanner result does not prove that a website is accessible.
The W3C Web Accessibility Initiative is explicit that evaluation tools cannot check every accessibility aspect automatically and that human judgement is required.
That distinction matters commercially.
A button can technically have a name and still be confusing. A menu can pass several automated checks and still be painful to operate by keyboard. A form can contain labels but provide useless error feedback. A booking flow can look fine page by page while trapping a user halfway through the journey.
Use the scanner as one layer of evidence, not as the verdict.
Use WCAG as the technical framework, not a marketing badge
The Web Content Accessibility Guidelines are the main international technical standard for web accessibility. W3C currently encourages teams to use the latest WCAG version, and WCAG 2.2 organizes its guidance around four principles: content should be perceivable, operable, understandable and robust.
See the official W3C WCAG overview and WCAG 2.2 recommendation.
For a business owner, you do not need to memorize every success criterion before you can ask better questions. You do need to know whether the person auditing your site can connect a technical finding to a real user barrier and a testable fix.
Audit the money path first
Do not begin by scanning 300 pages with equal priority.
Choose the journeys that matter most to the business. Usually that means:
- Homepage or important landing page.
- Main service or product page.
- Contact, booking, application or checkout flow.
- Login or account flow if customers use one.
- Any high-value document, menu or form customers must access.
Then test those journeys end to end.
This is the same systems principle I use when reviewing forms, payments and product flows: a component can work in isolation while the transaction still fails at the next boundary.
Test keyboard access without touching the mouse
Open the page and try to complete the important journey with the keyboard.
Check whether you can:
- reach every interactive control;
- see where keyboard focus currently is;
- open and close menus and dialogs;
- operate buttons, links and form controls;
- move through the page in a sensible order;
- escape overlays or popups;
- complete the main action without getting trapped.
Do not treat “I can press Tab” as the whole test. The question is whether the journey remains understandable and usable as focus moves.
If the visual focus indicator disappears, jumps unpredictably or lands behind a sticky interface element, record the exact step where it happens.
Test forms as transactions, not decorations
Forms deserve special attention because an inaccessible form can directly block an enquiry, appointment, application or purchase.
Check whether:
- each field has a meaningful label;
- required fields are communicated without relying only on colour;
- instructions are understandable before submission;
- validation errors explain what went wrong;
- the error is associated with the relevant field;
- focus moves sensibly after a failed submission;
- success is clearly communicated;
- the form still works with keyboard navigation and zoom.
If your business depends on enquiries, also test whether a successful submission is actually stored and delivered. My guide to contact forms that submit but never deliver the enquiry covers that separate failure layer.
Check images and non-text content in context
“Every image needs alt text” is too crude a rule.
The real question is what information the image contributes.
A meaningful product image, chart, diagram or photograph may need a useful text alternative. A decorative shape may need to be ignored by assistive technology rather than described. An icon-only control needs an accessible purpose even though it is not a normal content image.
Review the important pages and ask what a user loses if the visual cannot be seen.
Check contrast, zoom and responsive behaviour
Low-contrast text can make an otherwise good page unreadable. So can layouts that break when text is enlarged.
Test the site at increased browser zoom and on a narrow viewport. Look for:
- text clipped out of containers;
- buttons overlapping content;
- horizontal scrolling that blocks normal reading;
- navigation that becomes inaccessible;
- form fields or error messages disappearing;
- fixed elements covering the active control.
Accessibility and responsive QA overlap more than many redesign scopes acknowledge. If you are already planning a rebuild, include these acceptance tests in the project rather than paying to retrofit them later. My website redesign cost guide explains why scope matters more than raw page count when comparing redesign quotes.
Do not confuse an overlay with an audit
A script that adds an accessibility toolbar is not the same thing as finding and fixing barriers in the underlying website.
That is not an argument that every accessibility tool is useless. Tools can be valuable for discovery, monitoring and regression testing.
The distinction is that the tool should support the remediation process, not replace it.
W3C’s evaluation guidance makes the same underlying point: automated tools assist accessibility evaluation; they cannot determine accessibility on their own.
If a vendor’s entire proposal is “install this widget and you are compliant,” ask how they tested the actual booking, checkout, enquiry or account journey and what happens when the underlying markup changes.
For US businesses, be careful with legal claims
The US Department of Justice says the ADA applies to services, goods and activities offered online by businesses open to the public. Its guidance gives examples including retail stores, banks, hotels, hospitals, medical offices and food establishments.
Read the current DOJ guidance on web accessibility and the ADA rather than relying on a sales page that tells every private business it has the same compliance deadline.
There is an important distinction between Title II, which covers state and local governments and now has specific web rules, and Title III, which covers businesses open to the public. DOJ’s private-business guidance does not establish one universal federal WCAG deadline for every Title III website.
If legal exposure is a material concern for your business, combine technical remediation with advice from a qualified lawyer in the relevant jurisdiction.
What a useful accessibility remediation quote should contain
After the audit, a quote should be specific enough that you can tell when the work is finished.
I would expect it to identify:
- which pages and user journeys were tested;
- the barriers found and their priority;
- the technical standard being used;
- what will be fixed in code or content;
- what requires design changes;
- what cannot be solved automatically;
- how fixes will be retested;
- whether new content or future changes are covered;
- who owns the code, reports and accounts after the work;
- what counts as acceptance.
That is much more useful than a promise to make the site “100% compliant.”
The same principle applies when commissioning the original build. A good web design proposal should define testing and acceptance criteria before money changes hands.
A practical audit order for a small business
If you need a starting sequence, use this:
- Identify the three to five customer journeys that matter most.
- Run an automated accessibility scan on representative pages.
- Test those journeys with keyboard only.
- Review focus order and visible focus.
- Test forms, validation and success states.
- Review meaningful images and non-text controls.
- Check contrast and information conveyed by colour.
- Test zoom, narrow screens and responsive states.
- Review headings, page titles and structural landmarks.
- Manually investigate every high-impact issue before approving a remediation plan.
- Retest the complete customer journey after fixes.
- Add regression checks to future website maintenance.
The goal is not to produce the largest possible PDF. It is to remove barriers that stop people from understanding, navigating and completing the actions the website exists to support.
Accessibility is part of product quality
A business website is an interface between a customer and a business process.
If some customers cannot use that interface, the problem is not merely a compliance checkbox. It is a product-quality problem.
That is why I would rather see a business fix five serious barriers in its booking or enquiry journey than celebrate a superficial score while the important transaction remains difficult to complete.
If you are planning a new site or redesign and want accessibility, mobile behaviour, forms and conversion flows treated as part of the build rather than as after-launch patches, see my web design service or contact me.
