Small-Business Website Accessibility: Which Standard to Meet and How to Test It
What accessibility standard should a small-business website meet, and how should conformance be tested?
Use WCAG Level AA as the working standard for a small-business website. Prefer WCAG 2.2 AA for new work, while retaining WCAG 2.1 AA where an existing system or contract uses it. Review important customer journeys with automated checks and a bounded manual protocol: inspect content, use only a keyboard, review enlarged text and a narrow viewport, exercise forms and errors, and check required media or documents. Record evidence and retest fixes. Use a suitably competent accessibility specialist for screen-reader testing when internal skill is insufficient, custom controls, complex transactions, uncertain findings or formal conformance claims. This process supports improvement but is not certification or a universal legal determination.
- Accessible.org recommends WCAG 2.1 AA conformance, or 2.2, together with an accessibility statement containing contact information for support.
- ADA Website Compliance Guide: Accessibility and the Law | Accessible.org · As of 2026-11-14
- Brown Fox characterises WCAG and Section 508 standards as guides for website compliance and says courts handling website accessibility suits often refer to WCAG.
- Small Businesses and Website Accessibility under the ADA | Brown Fox · As of 2024-11-06
- The Hanover Insurance Group recommends evaluating a website’s current accessibility state and determining what can be done to increase accessibility and bring it into compliance.
- Website accessibility guidelines and what they mean for your small business | The Hanover Insurance Group · As of 2026-11-14
- Accessible.org says accessibility changes can be slight in appearance, such as updating colour contrast, and that an accessible website does not have to look a particular way.
- ADA Website Compliance Guide: Accessibility and the Law | Accessible.org · As of 2026-11-14
- United States ADA.gov guidance says a state or local government that hires an outside web developer must ensure the developer’s design meets the applicable web content and mobile-app accessibility requirements.
- Accessibility of Web Content and Mobile Apps Provided by State and Local Government Entities: A Small Entity Compliance Guide | ADA.gov · As of 2024-05-22
Use WCAG Level AA as the practical benchmark
Accessible.org recommends WCAG 2.1 AA conformance, or 2.2, together with an accessibility statement containing contact information for support. For a small business, use WCAG Level AA as the working technical benchmark, prefer WCAG 2.2 AA for new work and retain WCAG 2.1 AA where an existing platform, scope or contract already uses it.
Sources: ADA Website Compliance Guide: Accessibility and the Law | Accessible.org.
Write the chosen version and level into website briefs, design acceptance criteria, supplier requests and remediation records so everyone assesses the same target. The benchmark should guide decisions about content, templates, forms and customer journeys, but choosing it does not establish that the website conforms.
- Set WCAG Level AA as the operational target.
- Prefer WCAG 2.2 AA for new designs and builds.
- Name the chosen version in briefs, supplier work and review records.
Separate the technical target from the legal question
Brown Fox characterises WCAG and Section 508 standards as guides for website compliance and says courts handling website accessibility suits often refer to WCAG. WCAG is a credible operational target, but this secondary legal commentary does not establish that meeting it automatically resolves every legal obligation for every private small business.
Sources: Small Businesses and Website Accessibility under the ADA | Brown Fox.
Use a website governance framework to give one person authority to approve public wording about accessibility, claimed conformance and any need for local legal review. Describe the work plainly by naming the benchmark, checks performed and known limitations rather than claiming that a scan, badge or statement proves compliance.
Seek appropriate local legal advice when assessing a specific statutory obligation, demand, complaint or dispute; a technical review should not be presented as a legal opinion.
- Use WCAG as a technical reference point.
- Avoid claiming that a technical target settles every legal issue.
- Require approval before publishing accessibility claims.
Review the current website through important customer tasks
The Hanover Insurance Group recommends evaluating a website’s current accessibility state and determining what can be done to increase accessibility and bring it into compliance. Turn that broad recommendation into a bounded inventory of important customer tasks, including finding essential information, making contact, submitting a form, accessing a document and completing any booking or transaction.
Use a website task-allocation guide to decide which checks staff can perform, which supplied components need vendor attention and which work should go to a technical care provider or accessibility specialist. For each task, record its entry page, expected outcome, pages and components involved, owner and any third-party service so the review has a usable scope.
Choose representative journeys rather than claiming that a sample covers the entire website, and add a separate journey whenever a materially different template, form, document type or interactive component is required.
- Start with the tasks customers need to complete.
- Include pages, forms, documents and supplied components.
- Record the current state before prioritising remediation.
Apply a bounded manual protocol, then fix and retest
Accessible.org says accessibility changes can be slight in appearance, such as updating colour contrast, and that an accessible website does not have to look a particular way. Test the operation of each selected journey rather than judging accessibility from its visual style or relying on one automated result.
Sources: ADA Website Compliance Guide: Accessibility and the Law | Accessible.org.
Inspect headings, labels, instructions, link purpose, image alternatives and required content; record anything missing, unclear or dependent on appearance alone. Complete the journey using only the keyboard, observing whether interactive elements can be reached and operated, focus remains visible and logically ordered, and no component traps the user.
Review the journey with enlarged text and in a narrow viewport, noting lost content, overlap, unreadable text or controls that cannot be reached without impractical movement. Submit forms with valid, missing and mistaken information, then record whether labels, instructions, validation messages and recovery steps make the result understandable.
Where the journey requires audio, video or a document, check that the necessary alternative content is present and usable; refer unfamiliar document formats or media requirements to a competent reviewer. Screen-reader testing should be performed by someone who can use the selected assistive technology competently, because an inexperienced pass can create false confidence.
A website launch-validation process provides a related pattern for defining checks, assigning unresolved issues and preventing unreviewed changes from being approved for release. Record the check method, expected outcome, observed result, exact barrier, affected step, evidence reference, impact, owner and remediation decision, then repeat the affected checks before closing the item.
Stop and obtain a qualified accessibility assessment when the journey uses custom interactive controls, authentication, payment or another complex transaction; when assistive-technology competence is unavailable; when results remain uncertain; or when the business intends to make a formal conformance claim. The bounded protocol is an original practical review method, not a complete criterion-by-criterion WCAG evaluation, certification or proof that every user can access every part of the website.
- Use automated results only as one input to the review.
- Apply content, keyboard, display, form, media and document checks to each relevant journey.
- Escalate specialist-dependent checks and retest after remediation.
Retain ownership and keep accessibility current
United States ADA.gov guidance says a state or local government that hires an outside web developer must ensure the developer’s design meets the applicable web content and mobile-app accessibility requirements. That requirement directly concerns United States state and local governments, but a private small business can adopt the practical governance principle of retaining ownership of its benchmark when suppliers or third-party components are involved.
Ask suppliers to explain which benchmark and assessment method they will use, what evidence they will return, which components remain outside their scope and how unresolved limitations will be handled. Keep responsibility for accepting or escalating limitations with a named person inside the business rather than treating supplier involvement as a transfer of accountability.
Publish an accessibility statement with a working support contact, log reported barriers proportionately and repeat relevant checks after material changes to templates, navigation, forms, documents, customer journeys or supplied components.
- Retain ownership when a supplier builds or maintains the website.
- Publish a statement and working support route.
- Repeat relevant checks after material website changes.
Bounded accessibility test matrix for customer journeys
Apply each relevant row to every selected customer journey. These checks are Hallermann Consulting’s bounded operating protocol for finding and managing barriers; they are not a complete WCAG conformance methodology, certification or legal opinion.
| Review area | Practical check | Evidence to record | Specialist stop condition |
|---|---|---|---|
| Content and structure | Inspect headings, labels, instructions, link purpose, image alternatives and information conveyed through appearance. | Page or component, item inspected, expected meaning, observed result and exact barrier. | Escalate unfamiliar content formats or uncertainty about the applicable WCAG requirement. |
| Keyboard operation | Complete the journey without a mouse; observe reachability, operation, visible focus, focus order and keyboard traps. | Journey step, control, keys used, expected action, observed result and exact barrier. | Escalate custom widgets, complex menus or controls whose keyboard behaviour cannot be assessed confidently. |
| Enlarged text and narrow viewport | Review the complete journey with enlarged text and a narrow viewport; look for lost, overlapping or unreachable content and controls. | Display setup, affected page or component, expected outcome, observed result and exact barrier. | Escalate persistent reflow problems or uncertainty about the relevant technical requirement. |
| Forms and errors | Submit valid, missing and mistaken information; inspect labels, instructions, validation messages and recovery steps. | Input tested, expected outcome, observed message or behaviour, affected step and exact barrier. | Escalate authentication, payment, identity, health or other consequential and complex transactions. |
| Media and documents | Check that required audio, video and documents have usable alternatives and can be reached within the journey. | Asset, format, required alternative, observed result, affected task and exact barrier. | Escalate unfamiliar document or media formats and any check beyond the team’s competence. |
| Assistive technology and conformance | Use a competent reviewer for relevant screen-reader testing and for any criterion-by-criterion conformance assessment. | Technology and version used, reviewer, scope, method, findings, exclusions and unresolved uncertainty. | Stop if competent assistive-technology testing is unavailable or the business intends to claim formal conformance. |
Escalate whenever the team cannot perform a check competently or interpret the result confidently. A formal conformance claim requires a suitably qualified, criterion-by-criterion assessment rather than this bounded review alone.
When this is not the right approach: Do not use this bounded review as a substitute for a formal conformance assessment, specialist evaluation or advice about a specific legal obligation, complaint or dispute. Escalate when the website, customer risk or technical environment exceeds the team’s competence.
Related guidance
Another perspective
An automated scan, accessibility badge or published statement may support accessibility work, but none proves that every applicable WCAG requirement is met or that every important customer journey is accessible.
What follow-up questions matter most?
- Which WCAG standard should a small business use?
- Use WCAG Level AA as the practical technical target. WCAG 2.2 AA is a sensible choice for new work, while WCAG 2.1 AA can remain a workable reference for an existing website, platform or contract. Record the chosen version so staff and suppliers assess the same benchmark.
- Does meeting WCAG AA prove legal compliance?
- No. WCAG supplies a technical benchmark, but the available evidence does not establish one universal legal requirement for every private small business. Obtain appropriate local legal advice when assessing a specific obligation, claim or dispute.
- Which manual accessibility checks should a small business perform?
- Choose an important customer journey and inspect its content, complete it using only a keyboard, review it with enlarged text and a narrow viewport, exercise its forms and error messages, and check any media or documents it requires. Record the method and result for each check. Use a competent specialist for screen-reader testing, custom controls, complex transactions or a formal conformance assessment.
- Can an automated scan prove WCAG conformance?
- Automated tools can identify some possible issues, but they do not establish that every applicable requirement is met or that a person can complete a customer journey. Treat their results as inputs to manual review and remediation rather than as certification.
- What belongs in an accessibility statement?
- A useful statement names the benchmark the business is working towards, describes known limitations honestly, provides a working support contact and gives users a practical way to report a barrier. The statement supports communication but does not prove accessibility or legal compliance.
What steps does this workflow follow?
How to choose and review a practical accessibility benchmark
- Choose a working benchmark: Set WCAG Level AA as the operating target. Specify WCAG 2.2 AA for new work, or retain WCAG 2.1 AA where an existing system, platform or contract makes that reference necessary.
- Record the legal boundary: Describe WCAG as a technical and operational benchmark. Do not present the chosen version as a universal legal finding for every private business.
- Scope important customer journeys: List the pages, forms, documents and interactions customers need to complete, including each component and third-party service involved in the journey.
- Apply the bounded manual checks: Inspect content and structure, complete each journey with only a keyboard, review enlarged text and a narrow viewport, exercise forms and errors, and check required media and documents. Record the method, expected outcome, observed result and exact barrier.
- Escalate beyond team competence: Obtain qualified accessibility review for screen-reader testing when the team lacks that skill, custom interactive controls, complex transactions, persistent uncertainty or any formal claim of conformance. Obtain appropriate legal advice for a specific obligation, demand or dispute.
- Remediate and retest: Prioritise barriers that block important tasks, retain deferred issues in a visible backlog and repeat the original checks on the affected journey before recording a fix as complete.
- Publish support and maintain the work: Provide an accessibility statement with working contact details, route reports to an owner and repeat relevant checks after material changes to templates, content, forms, documents or supplied components.