ADA website accessibility: a practical guide for business owners

Website accessibility is about whether people can use your information and complete important tasks. A visitor may navigate with a keyboard, enlarge the page, use a screen reader or need a clear explanation when a form fails. The practical starting point is the task: finding a service, choosing a location, sending an inquiry or completing a purchase.

This guide explains how we organize an accessibility project. Legal applicability depends on the organization and jurisdiction; your legal adviser should resolve that question. The delivery team then needs a defined technical target, a testing scope and responsibility for repairs.

1. Separate legal applicability from the technical target

The ADA is U.S. civil-rights legislation; WCAG is a technical standard. They are related but not interchangeable. The Department of Justice provides guidance for state and local government services and for businesses open to the public. A site's obligations cannot be determined from an automated score alone. Read the DOJ's web-accessibility guidance and confirm the requirements relevant to your organization.

The DOJ Title II web rule applies to state and local governments. Its technical standard is WCAG 2.1 Level AA. Under the April 2026 extension, the compliance dates are April 26, 2027 for entities with a population of at least 50,000, and April 26, 2028 for smaller entities and special district governments. These are not universal deadlines for private businesses. See the current DOJ fact sheet and our deadline explanation.

For delivery, write the agreed standard, version and level into the scope. If your procurement or contract specifies a particular target, preserve that wording in the acceptance plan. An optional improvement target should not silently replace the requirement you have actually committed to meet.

2. Inventory the website and important journeys

A page count alone does not describe the assessment. A website may contain many pages built from a small set of templates, alongside a checkout or portal with distinct behaviour. List the shared components, content types and critical processes. Include navigation, search, forms, authentication where relevant, booking, payments, downloads and embedded services.

For each journey, record the starting point, the desired result and the systems involved. A booking flow might begin on a service page and finish on a third-party scheduler. Assessing only the first page leaves the actual booking experience outside the evidence. The scope should make that boundary clear before the work begins.

Content also matters. A technically sound template can contain an image with an unhelpful description, a confusing heading structure or a document that cannot be used with assistive technology. Include representative content and the people who publish it, rather than treating accessibility as a development-only responsibility.

A starting inventory

• Page templates: homepage, service, location, product, article and contact.
• Shared interactions: menus, dialogs, search, filters and consent controls.
• Complete tasks: inquiry, booking, registration, purchase and account recovery.
• Media and documents: videos, PDFs, presentations and downloadable forms.
• External services: scheduling, payment, chat and other embedded interfaces.

3. Ask for evidence you can act on

An assessment should explain what was tested, how it was tested and what was found. Automated checks are useful for identifying some issues across many pages, but they cannot determine every accessibility requirement. W3C recommends combining appropriate evaluation methods; see its evaluation overview.

We expect a useful finding to identify the affected page or component, the steps to reproduce the problem, the user impact and the relevant criterion. It should also include enough context for the developer or content owner to locate the issue. “Improve accessibility” is a goal; “the menu cannot be closed with the keyboard after it opens” is a repairable observation.

Manual review should follow the tasks in the agreed sample. Check keyboard operation and focus, enlargement and reflow, form instructions and error recovery, and the relevant screen-reader experience. Record the browser and assistive technology used so the result can be reproduced. A sampled assessment must identify what the sample represents and what remains outside it.

Example finding format

Task: send an inquiry. Observed problem: after submission fails, an error appears visually but focus and the announced status do not help the user locate it. Repair: connect the error to the affected field, preserve entered information and provide understandable feedback. Retest: repeat the failure and successful submission using the agreed input methods.

This is an illustrative reporting format, not a finding about your website. The purpose is to show the level of specificity that lets a team move from an audit to a completed fix.

4. Prioritize repairs by the task they block

Start with barriers that prevent an important task, then consider how widely the affected component is used. A shared navigation defect may affect the whole site. A checkout problem may affect a narrower group of pages but stop a purchase entirely. The repair plan should explain both the impact and the implementation dependency.

Group repeated findings by their underlying component where possible. Fixing the source template is easier to maintain than applying separate patches to every exported page. Content issues may need a different owner and an authoring checklist. Third-party issues require a named vendor contact or an alternative path while the business evaluates a longer-term solution.

Retesting is part of the work. After a change, repeat the original reproduction steps and the surrounding journey. A repair can resolve one barrier while introducing another, such as moving focus unexpectedly or hiding a required instruction. Record the verified result and any remaining limitation against the actual revision reviewed.

Track a small set of useful states

A practical backlog can distinguish findings awaiting a decision, repairs in progress, changes ready for retest and verified closures. Keep the original evidence alongside the resolution. A ticket being marked complete is not, by itself, proof that the user can finish the task.

5. Compare proposals on scope and ownership

Two accessibility proposals may use similar language while offering different work. One may provide a scan, another a manual assessment, and another include implementation and retesting. Ask for a sample deliverable and compare the actual responsibilities, rather than choosing from a score or a general compliance promise.

• Which standard and level are included?
• Which templates, journeys, documents and third-party systems are in the sample?
• Who carries out manual and assistive-technology checks?
• Does the engagement include repairs, or only findings?
• How many retest rounds are included, and what happens to unresolved issues?
• What documentation and training will your team receive?

A tool or overlay does not replace a clear assessment and repair scope. If a provider proposes one, ask which barriers it addresses, what it changes for users and how the result will be verified. The business still needs to understand the experience of the site as a whole.

For a rebuild, include accessibility in content planning, design and component review. Discovering a structural problem only at the final launch check can create avoidable rework. Early review makes it easier to agree the intended behaviour before it is repeated across the site.

6. Keep accessibility in ordinary publishing

Accessibility changes as the website changes. New campaigns, forms, images, documents and third-party widgets can introduce barriers. Assign an owner for routine content checks and a route for escalating issues that need development work. The maintenance agreement should say which changes receive review and when.

Publish a useful feedback route. Ask the person reporting a barrier for the page address, the task and the technology they used, without requesting unnecessary personal information. Decide who receives the report, who can offer an alternative and how the issue enters the repair backlog.

An accessibility statement should describe the actual scope and status of your work. It can name the target standard, the review method, known limitations and contact route. Avoid implying whole-site conformance from a sample or an automated score. Update the statement when the evidence changes.

A first action for your team

Choose one important journey and write down every step from arrival to completion. Identify the systems and owners at each step. That short exercise creates a concrete starting point for a diagnostic and helps you ask better questions of a prospective provider.

7. Practical checks for the people building and editing the site

The checks below help turn an assessment into specific conversations with a designer, developer or editor. They are a working checklist, not a complete conformance evaluation. Apply the agreed WCAG version and level to the actual interface, including its error states. A page that looks simple before interaction may expose its hardest barriers only after someone opens a menu, changes a filter or submits incomplete information.

Keyboard navigation and a visible place on the page

Start at the top of a page and follow a real task without using a mouse. Can you reach the navigation, open the relevant section, choose a service and send the inquiry? Note where focus moves, whether you can see it and whether the order makes sense. A control that responds only when clicked may leave the keyboard journey unfinished. W3C's keyboard explanation describes the requirement and its limited exception for functions that depend on a movement path.

For a location finder, a useful test is more specific than pressing Tab until the footer. Select a location, change the selection, open its details, follow the booking link, then return. If a dialog opens, check that the user can understand it and dismiss it without getting stuck. Record where focus lands after closing it. A video showing only successful mouse interaction does not answer these questions.

Keep focus visible against the interface. Sticky banners, floating chat controls and headers can cover the focused item. WCAG 2.2 adds a Level AA requirement that an item receiving keyboard focus is not entirely hidden by content the author created. Its Focus Not Obscured explanation is distinct from the more detailed Level AAA Focus Appearance criterion. Avoid treating every newer focus criterion as an AA requirement.

Readable contrast in the states people actually encounter

For WCAG AA, ordinary text generally needs a contrast ratio of at least 4.5:1 against its background; large text has a 3:1 threshold. Large text means at least 18 point, or 14 point bold, rather than 18 CSS pixels. Exceptions and definitions matter, so use the W3C contrast guidance when evaluating an edge case. Check the actual foreground and background combination, including gradients or photographs behind text.

Prepare a small list of reusable colour pairs for editors. Include body copy, secondary text, buttons and messages. That is easier to maintain than asking every author to judge a new colour by eye. Review hover and selected states too: a card may be readable until a visitor selects it. If the business needs a light brand colour, it can remain an accent without becoming the colour used for small explanatory text.

Images that communicate the right information

Describe the information an image contributes in its context. A decorative flourish needs different treatment from a chart, product detail or linked logo. W3C's images tutorial explains those categories. For complex information, nearby text or an accessible data table may provide a better explanation than a very long alternative-text field. Avoid repeating a caption word for word unless the repetition serves a clear purpose.

Imagine a venue page with a room photograph and a floor plan. The photograph might help someone understand the atmosphere; the plan communicates entrances, room relationships and facilities. Those are different editorial tasks. Ask the person supplying the image what a visitor needs to learn from it. If the answer is essential to choosing the venue, make that information available in the page content as well.

Headings, landmarks and meaningful links

A page should have a structure readers can follow without depending on font size or colour. Use headings to group ideas and label sections, and use the appropriate page regions for navigation and main content. W3C's page-structure tutorial provides implementation guidance. A heading should describe the content that follows; making a sentence bold does not give it the same structural meaning.

Read the headings on a service page in isolation. Do they explain the service, who it suits, what is included and how to proceed? Then read its links in context. Several identical “learn more” links may be hard to distinguish when each leads to a different service. “Explore commercial maintenance” gives a visitor more useful information. A skip link can also make it easier to move past repeated navigation to the main content.

Forms with instructions that remain available

Give fields clear labels, explain required information before submission and connect instructions to the relevant control. Placeholder text that disappears during typing should not be the only label. Group related choices so their purpose is understandable. W3C's forms tutorial covers labels, instructions, grouping and feedback. Review both what appears on screen and how the controls are presented to assistive technology.

For a project inquiry, decide whether you really need every field. An unexplained requirement to upload a document can stop someone who only wants an initial conversation. If a field has a special format, show an example before the user makes a mistake. If a budget range is optional, label it honestly. Clear instructions help the person provide useful information and help the receiving team understand the request.

Errors, confirmation and recovery

Test an incomplete submission, an invalid value and a service failure, as well as success. A useful error explains the problem and the next action. Preserve information already entered where it is safe to do so. Ensure someone using a keyboard or screen reader can locate and understand the feedback. W3C's form-notification guidance describes approaches for making errors and success messages available.

Distinguish receipt from completion. If an inquiry has been accepted, the message can say it was received and explain the expected next step. It should not announce a confirmed appointment when a staff member still has to arrange one. If the connection fails, offer a way to retry without creating duplicate requests. Include that recovery path in testing so the team can see what happens when the ideal sequence breaks.

Text enlargement and reflow

WCAG's Resize Text criterion addresses enlarging text to 200 percent without losing content or functionality, with stated exceptions. Reflow addresses a different problem: reading content without scrolling in two directions at narrow equivalent viewport dimensions, with exceptions for content that needs a two-dimensional layout. Do not substitute a single mobile screenshot for both checks.

Inspect the navigation, cards, form labels, validation text and footer when content is enlarged. Look for clipped words, overlapping controls and messages hidden in fixed-height boxes. A pricing table may need a different small-screen presentation, while an individual diagram may legitimately need more space. The point is to preserve the information and task, not to force every kind of content into the same layout.

Targets, dragging and touch interaction

Small neighbouring controls can be difficult to select. WCAG 2.2 Level AA introduces Target Size (Minimum), with a 24 by 24 CSS-pixel threshold or qualifying spacing and other exceptions. It is not a universal instruction that every link must be a large rectangular button. Evaluate the criterion in context, including inline links and equivalent controls.

For a booking calendar, test choosing a date, moving to the next month and correcting the selection. A decorative arrow can look attractive while presenting a tiny usable target. Consider whether the interface offers a straightforward alternative to dragging or a precise gesture. Describe these interactions in the component specification, so mobile and desktop versions preserve the same task instead of receiving unrelated fixes late in delivery.

Video, audio and essential visual information

Plan media accessibility before recording and editing. Captions, transcripts and descriptions serve different needs; the requirements depend on whether the media is live or prerecorded and on the information it contains. W3C's audio and video guidance explains these distinctions. Review automated captions before relying on them, especially for names, technical terms and instructions.

A product demonstration can often become clearer when the speaker explains the action while performing it. “Select delivery, then choose the pickup location” communicates more than “click here.” If an essential result appears only on screen, include it in the appropriate accessible alternative. Keep the transcript beside the video and assign responsibility for updating both when the product changes. An old transcript attached to a newly edited video can mislead every reader.

Documents and downloadable forms

Put frequently used information in an accessible web page when that format suits the task. When a document is necessary, check its structure, reading order, meaningful links, images and form fields. A scanned picture of text needs more work than a document created with proper headings. The Section508.gov document resources offer practical authoring and testing guidance; using them does not establish that Section 508 applies to every organization.

Make a document inventory alongside the page inventory. Record the owner, current purpose, source file and whether people still need it to obtain a service. An application form used every day deserves a different delivery plan from a historical report kept for reference. Do not assume that renaming a folder “archive” changes the legal status of everything inside it. Refer applicability decisions to the person responsible for the relevant requirements.

Dynamic content, loading states and interruptions

When an interface updates without loading a new page, decide what the user needs to know. A changed search-result count, saved preference or failed upload should not rely solely on a visual change. W3C's Status Messages explanation covers relevant notifications. Announcing every background event can overwhelm the experience, so match the feedback to the task rather than adding announcements everywhere.

Review an ordinary sequence: search, wait, receive results, change a filter and clear it. Can the person tell whether the system is busy, finished or unsuccessful? Can they keep their place when results update? Consent controls, chat prompts and promotional dialogs also need attention. Test them together on the real page; each component can work in isolation while their combined overlays make the page difficult to use.

8. Run a useful assessment workshop

Before booking an assessment, bring the people who know the service into one conversation. A developer understands the templates, a content owner knows the documents, and the operations team knows where customers get stuck. Ask each person to identify one important journey and one recent problem. This creates a practical scope without pretending that a meeting can replace the assessment itself.

Use a representative task as a rehearsal. For a multi-location business, start from a search result, select the relevant branch, confirm its services and send an inquiry. Write down every domain and system encountered. A branch page, embedded booking tool and payment confirmation may have different owners. The workshop should reveal those boundaries early enough to include them in the proposal and schedule.

Choose a sample for a reason

A useful sample includes different templates, content types, interaction states and critical processes. Record why each item is there. The homepage may represent the global header, while a long service page represents expandable sections and a product page represents variants. Include less polished content as well as the showcase pages. If your team publishes documents independently, the sample should reflect that workflow.

Sampling makes an assessment manageable, but it creates limits that the report must describe. A repaired shared component may improve many pages, while an individual image description applies only to that instance. Ask the assessor to distinguish those cases. When new findings suggest a wider pattern, agree whether to expand the sample or add a targeted investigation instead of silently assuming the original sample covered it.

Make findings usable by the receiving team

Agree the reporting format before work begins. Developers need reproduction steps and component references; editors need the content location and the reason a change matters; managers need impact, ownership and dependencies. One well-structured issue can serve all three audiences. Avoid several disconnected spreadsheets that describe the same problem differently and leave the team arguing about which status is current.

For each finding, preserve the original observation, the proposed repair and the retest result. Record the environment and reviewed revision. If a finding cannot be reproduced, keep the investigation visible rather than deleting the issue. A browser difference, login state or missing test data may explain the discrepancy. The purpose of the record is to help the next person continue the work accurately.

Include people with relevant lived experience

Where the project includes usability research with disabled participants, define the research questions, support needs and consent arrangements. Give participants a realistic task and avoid coaching them through a broken interface. Their observations can reveal friction that a technical checklist does not explain. Technical evaluation and user research answer related questions, and the scope should identify which work is being commissioned.

Budget for participants' time and any agreed accommodations. Use test accounts and fictional information when possible, and avoid putting personal details into public issue trackers. Discuss findings respectfully as barriers created by the service. The question is what the interface needs to do differently, not whether a participant used it in the way the team expected.

9. Build a repair plan your team can finish

Start with the shortest complete journey you can improve meaningfully. That might be finding the right service and sending a request, rather than redesigning every page at once. Map its findings to the shared components and content owners involved. This helps reveal whether the first step is a template repair, a content update, a vendor conversation or a change to the underlying process.

Separate immediate barriers from structural work

A missing label may be a small repair. A booking flow built around an inaccessible third-party interaction may require procurement and a migration. Both belong in the plan, but they need different owners and schedules. Keep an alternative assistance route available while a longer repair is being evaluated, and have the appropriate adviser assess whether that alternative meets the organization's obligations.

For structural changes, define an intermediate checkpoint that demonstrates the approach. Repair one representative component, test it in context and then roll it through the relevant templates. This reduces the risk of repeating an untested pattern across the site. It also gives the content team a concrete example to follow when they update related pages.

Agree what acceptance means

An acceptance plan should say what will be delivered and how it will be reviewed. It might require completed reproduction steps, an updated component, a retest record and operating notes for the client team. It should also explain what happens if the assessor finds a new issue while retesting. A fixed number of review rounds is a commercial boundary, not evidence that every possible barrier has disappeared.

Keep the technical acceptance decision separate from business approval to launch. A business may need a decision about an unresolved vendor dependency, and that decision should name the limitation. Do not change a failed check to a passed check to make the launch paperwork look tidy. Record the actual status, the responsible owner and the next action.

Make the handover usable after the agency leaves

A useful handover includes the scope, tested pages and processes, finding history, release reference and maintenance responsibilities. Give editors examples of accessible content in their own publishing system. Explain which changes they can make independently and which should trigger a technical review. A general presentation is less useful than instructions tied to the buttons and fields the team uses every week.

Store the records where the client can retrieve them, with appropriate access controls. Name the person responsible for updating the backlog and statement. If the hosting provider, booking system or theme changes, review the affected evidence instead of carrying the old acceptance record forward unchanged. Accessibility work becomes easier to maintain when the records follow the operating system rather than an individual person's inbox.

10. Questions business owners ask

Will a perfect automated score prove that the site is accessible?

No. Automated checks can identify particular technical patterns, but a score does not describe every task or requirement. Ask what the tool tested, what it did not test and which manual checks accompanied it. A useful report connects findings to the user experience and the agreed standard. Keep the tool output as one part of the evidence rather than replacing the assessment with a single number.

Should we buy an overlay or repair the website?

Evaluate the actual product and proposed changes. Ask for a demonstration of the barriers it addresses and a retest of the complete journey with the relevant assistive technologies. Some tools offer individual preferences or assistance; that does not establish whole-site conformance. Your plan still needs to account for source templates, content, documents, external services and the people responsible for maintaining them.

Does a redesign mean we should postpone repairs?

Review the current barriers and the redesign schedule together. A small repair may help people now and provide a tested pattern for the new site. Other changes may be best handled in the rebuild. Make those choices explicitly with the service owner, especially where a task is blocked. A future launch date should not cause current feedback to disappear into an unowned list.

How much should an assessment cost?

The useful comparison is the work included: systems, templates, journeys, documents, manual methods, reporting and retesting. Ask providers to price the same scope and identify assumptions. A scan-only quote and a project that includes implementation are different purchases. If the inventory is uncertain, a defined discovery stage can establish the information needed for a more reliable proposal.

Can the same technical work help a Canadian and U.S. business?

Shared components and accessible content can serve users across markets, but legal requirements still need to be identified for the relevant entity and jurisdiction. Do not use the U.S. Title II dates as a Canadian deadline or assume a particular WCAG version settles every obligation. Give the delivery team the requirements confirmed by your adviser, then map the technical work to them.

Does an accessible site automatically rank better?

A clearer, more usable site can serve customers better, and some implementation work overlaps with ordinary website quality. That is not a measured ranking uplift or a promise of more traffic. Evaluate accessibility against the agreed user tasks and technical standard. Evaluate search performance separately with its own sources, dates and limitations, rather than assigning the same improvement to every business outcome.

What should we do with an accessibility complaint?

Make sure it reaches a responsible person promptly. Preserve the reported page, task and relevant details, offer appropriate assistance and investigate the barrier. Avoid requesting unnecessary medical information. If the message raises a legal claim, involve your legal adviser through your established process. Continue documenting technical findings accurately without treating a repair as proof that every legal question has been resolved.

What is a useful first step if we have no programme yet?

Name an owner and choose one important customer or service journey. Inventory the pages, documents and systems involved, then commission a defined assessment and repair plan. Use the result to establish publishing guidance and a feedback route. The goal of that first project is a working process your team can repeat, with evidence of what changed and clarity about what still needs attention.

11. Review a vendor demonstration against your own task

A supplier's demonstration is most useful when it follows a journey your organization actually provides. Send a short task in advance and ask to see the relevant configuration, rather than only the vendor's preferred example. For a booking service, include choosing a location, finding an available time, entering the required information and correcting a mistake. Ask which parts of the experience your own team can configure.

During the demonstration, record observations and unanswered questions separately. A presenter may know a shortcut that an ordinary visitor would not discover. Ask how the same task works with the agreed input methods and assistive technologies. If the vendor cannot demonstrate a particular state, make it a follow-up item with an owner. Do not convert an unanswered question into either a passed check or a confirmed defect.

Check the evidence against the version you will use

Ask when the vendor's assessment was performed and which product version, features and configuration it covered. Find out whether it included manual testing and complete processes. If your implementation adds a custom theme, additional fields or a separate payment provider, identify what further checks are needed. The vendor's general documentation can inform procurement, while the implemented service still needs its own acceptance evidence.

Discuss the support path for accessibility issues. Who receives a reproducible report, how are changes communicated and what happens when a fix affects your configuration? Keep the answer in the project record. If the business depends on the product for a critical service, an unclear support path is a decision to resolve before committing to the implementation.

Plan an ordinary update as part of handover

Ask the receiving team to perform a small, realistic update using the supplied instructions. They might change a location's hours, replace an image or edit a form instruction. Review the result together. This exercise can reveal missing access, unclear ownership or publishing steps that were obvious to the developer but absent from the documentation.

Then agree what will trigger another review. A text correction may fit the editorial checklist, while a new calendar, checkout flow or navigation component needs technical testing. Record those examples in language the team uses. The handover is stronger when people understand both what they can maintain independently and when to bring an unfamiliar change back for assessment.

Explore our accessibility assessment and remediation service, website-review templates or discuss your scope. For broader educational material, What Is ADA is a Grow Wild-operated resource; ADA Compliant Web Design is our provider-discovery property. Both are owned resources, rather than independent endorsements of the agency.