How far to take accessibility
Three paths: meet the law, make it easy to use, or lead your field. What each one takes, what you can show for it, and how to choose.
Three paths, one standard
After this guide you'll be able to choose how far to take accessibility, say what that choice involves, and ask for the right work. It picks up where our plain-English introduction leaves off: once you know what accessibility is, the next question is how far to go. You don't need to know the standard to follow it.
Two businesses can both say their website is accessible and mean different things. One fixed its checkout so that it works with a keyboard and a screen reader. The other tested every step with customers who use screen readers and magnifiers and measured how it went. Both did real work. Neither is wrong. They chose different paths.
Without a name for those paths, teams tend to stop too early or aim at everything and stall. So we describe three. Each one is a reasonable place to aim, and each one builds on the one before it.
- Path 1: Meet the law. Remove the barriers that stop people, meet the standard the law points to, and keep a record.
- Path 2: Make it easy to use. Test with people with disabilities, make tasks as quick and sure for them as for anyone, and tell customers what you did.
- Path 3: Lead your field. Build accessibility into how you work, publish what you learn, and become the example others point to.
All three rest on the same standard, the Web Content Accessibility Guidelines (WCAG), at its Level AA. This guide covers what each path adds, what you can show for it, and how to choose.
| Path | What a customer notices | What you can show | What it takes |
|---|---|---|---|
| Path 1 | They can finish the main tasks with a keyboard, a screen reader, and the screen zoomed in. Nothing blocks them. | An independent evaluation, the fixes made, and an accessibility statement, each dated | A first look, an evaluation, a fix list worked in order, and one owner |
| Path 2 | Tasks take about as long, and feel about as sure, as they do for anyone else. Text is plain. Media has captions and transcripts. | Results from testing with people with disabilities, a statement kept up to date, a contact who answers | Research with customers with disabilities, accessible defaults in the design system, clear content |
| Path 3 | New features arrive accessible and stay that way. A fixed barrier does not come back. | A public record kept over years, measured results, and what you learned written up for others | Accessibility in roles, budgets, purchasing, hiring, and release checks, reported to leadership |
The paths add up. You cannot be on Path 2 with a checkout that fails on the keyboard, and Path 3 is Path 2 made permanent.
Path 1: Meet the law
Most businesses start here, and for many it is the right place to stay for a while. The goal is plain: nobody is stopped from using what you offer, and you can show what you did about it.
What it means for a customer
A customer who is blind can find a product, read its description, add it to the cart, and pay, with a screen reader. A customer who cannot use a mouse can do the same with a keyboard alone and can always see where they are on the page. A customer with low vision can zoom the page to twice its size without losing anything. Forms say what went wrong and how to fix it. Images that carry meaning have a description. Videos have captions.
Those are the barriers that most complaints describe. The lawsuits in our database rarely cite anything unusual. They cite ordinary tasks that failed: a menu that will not open from the keyboard, a checkout that hides its errors, a form with unlabeled fields. Path 1 removes those barriers.
What the law points to
The version and scope depend on the law or contract. The U.S. Title II web rule names WCAG 2.1 AA, while Ontario's website rule names WCAG 2.0 AA with exceptions. UK public sector guidance expects WCAG 2.2 AA. The European Accessibility Act has requirements beyond web content. A WCAG result alone does not show that you meet it.
Use our law summaries to find the official sources and confirm your obligations. WCAG 2.2 AA is a useful target for new work, but a review also needs to cover the particular standard, scope, and other duties that apply to you.
What it takes
Path 1 starts with a defined review and continues with fixes, retesting, and checks when the product changes.
- A first look. Someone who did not build the product tries the main tasks with a keyboard and a screen reader and runs an automated check. The W3C’s Easy Checks cover a first review and explain its limits.
- An evaluation with an agreed scope, standard, version, and level, including relevant documents and video. It produces a list of barriers and explains their impact. A review of a sample needs to say what was and was not checked.
- The fixes, in order of severity. A barrier that stops a task comes before one that slows it down.
- An accessibility statement: a public page that says which standard you aim for, what is not yet right, and how to report a barrier. The W3C’s guidance on statements lists what to include.
- Checks after relevant changes, with a review schedule based on how the product changes and which tasks people rely on.
In a small team, begin with the main customer task and put findings in your existing task list. In a larger organization, agree on representative pages and processes across teams, assign the fixes, and include supplier responsibilities. The scope and sample need to be explicit in either case.
What you can show
A dated evaluation, the list of what was found and fixed, and a published statement. If you sell to governments, universities, hospitals, or large companies, add a conformance report, usually called an ACR. It is written on the VPAT template that the Information Technology Industry Council maintains, and buyers ask for it.
This record is evidence of your effort. It is not protection. It will not stop a demand letter from arriving, but it changes the conversation from “did you ever look” to “here is what we found and fixed, and when”.
What it does not do
A product can meet the standard and still be tiring. Every field has a label, but the form has forty of them. The video has captions, but the words on screen are small and the page times out. Meeting the standard removes barriers. It does not, by itself, make the product good to use. That is the next path.
Path 2: Make it easy to use
Some businesses want more than the absence of complaints. Many of their customers enlarge text or use a screen reader. Their brand is built on care, or on design. They want customers to notice the difference, and they want to say what they did without stretching the truth. Path 2 is for them.
What it means for a customer
The difference is measured in time and confidence. A person using a screen reader finishes a purchase in about the time anyone else does. A person with a tremor hits every button on the first try because the targets are large. A person who reads slowly understands the pricing page on one pass because it is written plainly. Nobody is timed out of a form. The page works on a six-year-old phone on a slow connection.
Some of this comes from the parts of WCAG that the law does not require. The standard has a third level, AAA, which the W3C does not recommend requiring for a whole site. A few of its requirements matter a great deal for particular audiences: reading level, larger targets, stronger contrast, no time limits, and richer descriptions for media. Path 2 picks the ones your customers need.
Most of it comes from one practice: watching people with disabilities use your product. The W3C’s guidance on involving users in evaluation describes usability testing with people with disabilities as the way to find what a standards check cannot. A product can pass every criterion and still confuse the person in front of it. Testing shows you where.
What it takes
Everything in Path 1, then:
- Testing with people with disabilities on the tasks that matter most, at least once a year and before a redesign. The W3C’s guidance on involving users in web projects explains how to find a range of participants and how to work with them. Pay them for their time.
- A design system with accessible defaults, so the button, the field, the colors, and the spacing are right once and right everywhere.
- Content reviewed for plain language. The U.S. government’s plain language guide is a practical start.
- Captions and transcripts on every piece of media, written by a person or checked by one.
- Performance on old devices and slow connections treated as an accessibility matter, because it is one for people who cannot afford new hardware.
Small team: one round of testing with three to five people on your main task, a checklist for content, and accessible defaults built into whatever component library you already use. Enterprise: a research budget line for participants with disabilities, accessibility in the design system’s acceptance criteria, and an editor who owns plain language.
What you can show
Here is where Path 2 pays back. You can say, in your statement and on your site, what you did and when. A sentence like “In March 2027 we tested the checkout with eight customers who use screen readers, magnification, and voice control, and fixed the twelve problems they found” is worth more than any badge, because a customer or a buyer can check it.
Say what you did, not what you are. “Fully accessible” is a claim no one can stand behind, because a product changes every week. The specific sentence earns trust. The vague claim loses it.
An accessibility statement that is kept up to date does the same work. Update it when something changes, name a person or a mailbox that answers, and answer. The reports that come in are user research you did not have to arrange.
If you’re not sure where to start, tell us about your website and we’ll suggest a first step.
Talk to us about a first stepPath 3: Lead your field
A few organizations want to be the example others point to, in their industry and among the people who work on accessibility for a living. Path 3 is the long game. It is less about the product on any given day and more about how the organization works and what it shares.
What it looks like from inside
Accessibility stops being a project and becomes part of the job.
- Someone owns it, with a budget and a seat in planning.
- A feature is not finished until it works with a keyboard and a screen reader, and the release check says so.
- Every purchase asks the vendor for a conformance report before the contract is signed.
- New staff get training, and designers and developers have used a screen reader on their own product.
- Automated checks run on every release, a human review runs on a schedule, and a number goes to leadership: barriers open by severity, and how long they take to close.
- People with disabilities are in the research, and in the hiring.
The W3C describes this ground in its Accessibility Maturity Model, a Group Note published on November 4, 2025. It rates an organization across dimensions such as communications, procurement, personnel, and support, on four levels from “Inactive” to “Optimize”, where accessibility is incorporated into the whole organization and consistently evaluated. It is written for large organizations and is thorough. Path 3 is the plain-language, product-sized version.
What it looks like from outside
The accessibility community notices specifics, and it is hard to impress. What it respects:
- An accessibility statement that tells the truth, including what is still wrong, and has been updated for years.
- Results. How many people you tested with, what you found, what you changed, and what happened to task success afterward.
- A case study written with the people who did the testing, not about them.
- Things others can use: a component library with its accessibility work documented, a pattern you solved and wrote up, a talk at a conference, a fix contributed to an open-source project.
- Hiring people with disabilities, and not only to test.
What it does not respect: a badge, a certificate from a vendor, a press release that says “fully accessible”, or an overlay. Those claims are the first thing an expert tests.
We cannot promise recognition. Nobody can. It comes from doing the work for long enough, measuring it, and sharing what you learned in a form others can check. The organizations that get cited as examples got there that way.
What it takes
Path 3 needs continuing ownership and resources. A small team can document its checks, listen to customers, and share what it learns. A larger organization also needs clear roles, a budget, supplier requirements, and reporting that shows unresolved barriers as well as progress. The time involved depends on the product and the work already done.
Which path fits your business
Start from what the law or your buyers expect, then from what you want the work to do for you.
- A public body: confirm the accessibility duties in your jurisdiction, then plan a standards review and testing of the services people rely on.
- A business that sells to governments, universities, hospitals, banks, or large companies: Path 1, with a conformance report, because procurement asks for it.
- A business selling to consumers in the European Union, from anywhere: Path 1, because the European Accessibility Act has applied to covered products and services since June 28, 2025.
- A U.S. business open to the public: review the ADA Title III requirements and agree on the scope of an evaluation.
- A business whose customers often enlarge text or use a screen reader, or a health, finance, or utility service: Path 2, because the difference between “works” and “works well” is where you keep those customers.
- A brand built on care, design, or community: Path 2 at least, because a gap between the brand and the checkout shows.
- An organization that wants to be the example in its field: Path 3, and the patience to get there.
Four questions help, whatever the list says:
- Has anyone asked you for accessibility documentation: a buyer, a customer, or a lawyer? If yes, start with Path 1 now.
- Do you know how a customer with a disability experiences your main task today? If no, a first look is the next step, before any path.
- Would you be comfortable publishing what you did, with dates? If yes, Path 2 is within reach.
- Do you want to be known for this? If yes, Path 3, and plan in years.
You can change paths. Starting on Path 1 because a buyer or a letter asked is common, and once the first fixes are done, the next path is easier to plan. Pick the path you can commit to this year, write it down, and tell the team.
What to do this month
Choose a scope you can explain: the website or app, the tasks to review, and the standard and version you need to evaluate against. Check any legal or contractual requirements before setting the schedule. Our practical guide to finding and fixing barriers gives you a starting point for the review.
Give the work an owner
Name the person who will keep track of findings and decisions. Each fix also needs an owner, whether that is a content editor, developer, designer, or supplier. In a small team, one person may coordinate the work alongside their usual role. In a larger organization, give shared components and purchased services clear owners across teams.
Fix and retest important tasks
Prioritize barriers that prevent people from completing essential tasks. Record the page, the steps to reproduce the problem, and the expected result. Test the fix in the same task before closing the finding. A shared component may need checking wherever it appears.
Include people with disabilities in the review and pay them for their time. Their feedback can reveal difficulties a standards check does not explain. W3C's guidance on involving people in evaluation describes how to combine that feedback with a conformance review.
Keep the work part of each release
Add accessibility to content reviews, design decisions, and release checks. Recheck affected tasks when a component, template, document, or supplier service changes. Agree on a review schedule that reflects how often your product changes and the consequences of a barrier.
Keep a dated record of findings and retests. Update your accessibility statement when your target, known limitations, or contact process changes. W3C's planning guidance can help you assign responsibilities and follow progress.
If you need an independent review, our solutions page describes the work we offer. Start the conversation with the task you need people to complete and the questions your team needs answered.
Keep learning
- A plain-English guide to digital accessibility: our introduction to who accessibility helps, what the law expects, and the words you will hear.
- How to find and fix common accessibility barriers: checks you can use to begin a review and verify a fix.
- Planning and Managing Web Accessibility: the W3C’s guide to building accessibility into how an organization works.
- The Business Case for Digital Accessibility: the W3C’s summary of the reasons and the evidence.
- Accessibility Maturity Model: the full framework, for organizations on Path 3.
Terms used in this guide
Sources
- Easy Checks – A First Review of Web Accessibility
- Developing an Accessibility Statement
- VPAT
- Overlay Fact Sheet
- FTC Approves Final Order Requiring accessiBe to pay $1 Million
- Involving Users in Evaluating Web Accessibility
- Involving Users in Web Projects for Better, Easier Accessibility
- Plain language guide series
- Accessibility Maturity Model
- Planning and Managing Web Accessibility
- The Business Case for Digital Accessibility
Get help with every step.
We can work with organizations of every size and industry, from a startup serving its first customers to a bank. We find where you stand, help your team fix what matters, and keep checking as your product changes. That work is evidence of your effort, not a legal guarantee.