Web accessibility: what the law asks and what to fix first
SearchBlueprint · · 14 min read · scored 92/100

Web accessibility means building your website so people with disabilities can perceive, understand, move through and use it, whether they rely on a screen reader, a keyboard, captions or browser zoom. In practice, that means meeting the Web Content Accessibility Guidelines (WCAG), the standard most accessibility laws point back to.
This guide is for business owners and marketers who look after a company website. It covers who is affected, what US law expects, the barriers that show up on most sites, which fixes you can make yourself, and when a specialist is worth the money.
What web accessibility covers
The W3C, the body that sets web standards, defines web accessibility as websites, tools and technologies built so people with disabilities can use them. That means they can perceive, understand, navigate and interact with the web, and contribute to it too.
Tim Berners-Lee, who invented the web, put the goal plainly: "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." The W3C's Introduction to Web Accessibility opens with that line.

Who depends on an accessible site
WebAIM, which trains developers in accessible design, notes that one in four adults in the United States has a disability. Not every disability affects how someone uses the internet. Still, as WebAIM puts it, few businesses would knowingly turn away a quarter of their potential customers, or even 5 percent of them.
The main groups look like this:
- Visual: blindness, low vision and color blindness. People may use screen readers, which read the page aloud, or screen magnifiers.
- Auditory: deafness and hearing loss. People rely on captions and transcripts.
- Motor: limited fine motor control or no use of a mouse. People may use a keyboard, a mouth wand, eye-tracking software or voice commands.
- Cognitive: learning disabilities, distractibility and trouble holding a lot of information at once. Clear writing and a logical layout matter most here.
The W3C also lists speech and neurological disabilities in its definition.
The benefits reach well past disability
The W3C lists several groups who gain from accessible design without having a disability:
- people on phones and smart TVs, with small screens or different ways to input
- older people whose sight or hearing is changing with age
- people with a temporary disability, such as a broken arm or lost glasses
- people limited by their situation, such as bright sunlight or a place where they can't play sound
- people on a slow or expensive internet connection
That overlap is why accessibility work and usability work pull in the same direction. If you are already working through a plan to improve your site's user experience, many of the same changes count twice.
The WCAG standard in plain terms
WCAG is written by the World Wide Web Consortium (W3C), and according to the W3C, version 2.2 is also an ISO standard, ISO/IEC 40500. WebAIM calls it the basis of most web accessibility laws in the world.

The guidelines rest on four principles, and their first letters spell POUR:
- Perceivable. Users can take in the content with the senses they have, or through assistive technology. Images have text alternatives and videos have captions.
- Operable. Every control works from a keyboard or an assistive device as well as a mouse. Nothing depends on precise mouse movement.
- Understandable. Content is clear and the site behaves in a predictable way.
- Robust. The code is clean enough that many browsers and assistive tools, old and new, can read it.
For interactive widgets built with JavaScript, developers use WAI-ARIA. It is a W3C technology that adds meaning browsers and assistive tools can pass on to users. Mozilla's MDN accessibility docs cover it in depth. MDN also makes a simpler point: a great deal of content becomes accessible just by using the correct HTML element for each job.
Is web accessibility required by law?
Often, yes. The details depend on who you are and where you operate. Read what follows as a summary of public guidance, and ask a lawyer about your own situation.

The ADA and your website
The Americans with Disabilities Act covers state and local governments under Title II. It covers businesses open to the public under Title III. In its guidance on web accessibility and the ADA, dated March 18, 2022, the Department of Justice says it has consistently held that the ADA applies to services and goods offered on the web.
The DOJ's Title III examples include retail stores, banks, hotels, hospitals and medical offices, food and drink businesses, and theaters and sports arenas. If customers can walk into your business, the DOJ's position is that what you offer on your website is covered too.
The same guidance says businesses can choose how they comply, because the DOJ had not set detailed technical standards for them. They must still make what they offer online accessible, and the DOJ points to WCAG and the federal Section 508 Standards as helpful guidance.
State and local governments: the 2024 rule
The ADA.gov page carries its own caveat. The 2022 guidance does not reflect the requirements for state and local governments published in the Federal Register on April 24, 2024. If you run or build websites for a public body, read that rule directly rather than an older summary.
Section 504, Section 508 and other countries
The Rehabilitation Act of 1973 adds Sections 504 and 508. Section 508 sets the standards the federal government uses for its own websites. Outside the US, WebAIM notes that many international laws also address accessibility. The United Nations Convention on the Rights of Persons with Disabilities goes further and treats access to the web as a basic human right.
| Rule or standard | Who it applies to | What it means for a website | Where to read it |
|---|---|---|---|
| ADA Title II | State and local governments | The DOJ treats their online services and programs as covered | ADA.gov, plus the rule published April 24, 2024 |
| ADA Title III | Businesses open to the public, such as shops, banks, hotels and medical offices | The DOJ treats goods and services offered online as covered, with flexibility in how you comply | DOJ guidance dated March 18, 2022 |
| Section 508 of the Rehabilitation Act of 1973 | Federal agencies | Sets the accessibility standards federal websites follow | The Section 508 Standards |
| WCAG from the W3C | Anyone; most accessibility laws are based on it | The technical checklist most teams test against; WCAG 2.2 is also ISO/IEC 40500 | The W3C Web Accessibility Initiative |
| UN Convention on the Rights of Persons with Disabilities | Countries that have ratified it | Treats access to the web as a basic human right | The United Nations |
The accessibility barriers most sites still have
UserWay, a company that sells accessibility software, reports that 96% of the top websites contain easily detectable accessibility issues. It is a vendor's own figure, but it matches WebAIM's view that the web's potential for people with disabilities "remains largely unrealized."

The same handful of barriers comes up again and again in the DOJ's guidance, so here they are with the fix and a straight answer on whether you can do it yourself.
| Barrier | Who it blocks | The fix | Can you fix it yourself? |
|---|---|---|---|
| Images with no alt text | Blind users on screen readers | Add short alt text that says what the image is for | Yes, in most content management systems |
| Low color contrast | People with low vision or color blindness | Darken the text or lighten the background until text stands out clearly | Usually, though brand color changes may need a designer |
| Color as the only signal | Color-blind users and screen reader users | Add a text cue, such as the word "required" beside a red form field | Yes |
| Videos without captions | People who are deaf or hard of hearing | Add accurate, synchronized captions that identify speakers | Yes, or with a captioning service |
| Audio with no transcript | People who are deaf or hard of hearing | Publish a text transcript with the audio | Yes; the W3C calls transcripts easy and relatively inexpensive |
| Form fields with no labels or vague errors | Screen reader users and people with cognitive disabilities | Label every field, give clear instructions and explain each error and its fix | Partly; often needs a developer |
| Menus and buttons that need a mouse | People who can't use a mouse, including voice-control users | Make every function work from the keyboard | Usually needs a developer |
| Headings picked for their font size | Screen reader users who jump between headings | Use real heading tags in a logical order | Yes |
| Links that say "click here" | Screen reader users who scan a list of links | Write link text that makes sense on its own | Yes |
Images, video and audio
Alt text should describe the purpose of an image. The DOJ says that to be useful, it should be short and descriptive. A product photo needs the product name. A chart needs the point the chart makes.
For video, the DOJ asks for synchronized captions that are accurate and identify who is speaking. For archived audio, such as a past podcast episode, WebAIM says a transcript may be enough.
Forms and keyboard use
Forms are where accessibility problems cost you money most directly. A customer who can't submit a booking or checkout form simply leaves. Each field needs a label a screen reader can announce, such as "credit card number" on the card box. When someone makes a mistake, the page should tell them right away, say what went wrong and explain how to fix it. A date typed in the wrong format is the DOJ's own example.
Keyboard access is the other half. Some people can't use a mouse at all, and many older users with limited fine motor control are in that group. When every menu and form works from the keyboard, people who use speech input and other tools that act like a keyboard can use your site too. Text size matters as well: people with low vision need to zoom in with the browser without the page falling apart.
Structure: headings, links, tables and documents
Screen reader users often move through a page by its headings, or listen to its links alone. So headings need to be real heading elements in a sensible order, and every link needs to make sense out of context. You can see a page's heading outline, along with its title tag, in a free heading and meta tag checker.
Data tables need header cells so a screen reader can tie each value to its row and column. PDFs and Word files need the same care. WebAIM recommends tagged PDFs, or an HTML version when a document can't be made accessible. A "Skip to main content" link at the top of each page lets keyboard users jump past the menu that repeats on every page.
How web accessibility and SEO overlap
A lot of what makes a page accessible also makes it easier for search engines to read. The W3C points out that search engines can't see images either. They read the alt text, just as a screen reader does, and a transcript turns audio into text they can read.
The overlap goes further than media:
- Headings give screen reader users a map of the page. They give crawlers a clear outline of what the page is about.
- Descriptive link text tells a screen reader user and a search engine what the next page covers. "Office cleaning prices" beats "click here" for both.
- Clean HTML pays off too. WebAIM notes that accessible code is usually lighter and more efficient, and that valid HTML and CSS make code sturdier.
- Many barriers that trip up people with disabilities also frustrate phone users on small screens.
Be realistic about what this means. Accessibility work will not rank a page by itself, and the reason to fix a barrier is that people can't use your site otherwise. The search benefit comes from clearer structure and better content. For more on how structure, content and technical fixes fit together, browse the SearchBlueprint blog.
How to check your site for accessibility yourself
You can find a lot in an afternoon with no special software. The W3C publishes a guide called "Easy Checks," a first review of web accessibility, built on exactly this idea: simple steps such as changing browser settings show you where the obvious problems are.
Quick checks you can run today
- Put the mouse aside and press Tab through your homepage and your most important form. Can you always see where you are, and can you reach every link and submit the form?
- Push your browser zoom well past normal size and check whether the text stays readable or starts to overlap and get cut off.
- Check your images. Look at the alt text on your key pages. Is it missing, or stuffed with keywords instead of describing the image?
- Read your headings in order. Do they form a logical outline, or jump from H1 to H4 because someone liked the font size?
- Play a video with the sound off. Are there captions, and are they accurate?
- Break a form on purpose. Leave a required field empty and submit. Does the error explain the problem in words, or only turn a box red?
- Run an automated checker. Free tools flag missing alt text and low contrast in minutes.
If you want a wider list to work through at the same time, this website audit checklist of 25 free checks covers the technical and on-page basics.
Why automated tools and overlays only go so far
Automated checkers are useful. They also miss a lot. The W3C is direct about it: no tool alone can determine whether a site meets accessibility guidelines, and knowledgeable human evaluation is required. The DOJ compares automated checkers and overlays to spelling and grammar checkers, which help only when you use them with care, and it warns that a "clean" report does not necessarily mean the site is accessible.
That caution applies to overlays, the widgets that add an accessibility toolbar and promise to fix common issues as each page loads. Vendors such as UserWay sell them alongside manual audits and monitoring. A widget can't know whether your alt text describes the right thing, or whether your form errors make sense. Treat one as an extra layer on top of fixing your pages.
When to bring in a professional
Doing it yourself works well for content fixes: alt text, captions, headings, link text and plain writing. Get expert help when:
- you run custom JavaScript parts, such as date pickers or carousels, that need ARIA and keyboard handling
- your checkout, booking or application forms are complex
- you are planning a redesign, since the W3C says it is most efficient to build accessibility in from the start instead of redoing work later
- you need a formal audit, for example because a buyer's procurement process or a legal letter asks for one
The learning curve is shorter than many people expect. WebAIM says a developer can learn the basics of web accessibility in a few days, though it often takes months to make the mindset and techniques second nature. If you want to start learning yourself, the W3C offers a 4-minute introductory video and a free online course, Digital Accessibility Foundations.
Make accessibility part of how you publish
One-off fixes decay. A new blog post goes up without alt text, a new video ships without captions, and a redesign drops the skip link. WebAIM's advice for organizations is to build awareness, get leadership behind the work and back it with a written policy, so accessibility becomes part of the daily routine.
For a small team, that can be a few lines added to every content brief:
- every image gets alt text that says what it shows or does
- every video gets captions before it goes live
- headings follow a logical order
- link text says where the link goes
- forms are tested with a keyboard before launch
Then re-run your checks after each release, the same way you would re-audit anything else that drifts over time. You can see that habit in practice in our case study, where we audited our own site.
FAQs
Is web accessibility a legal requirement for small businesses?
In the US, the DOJ's position is that the ADA covers businesses open to the public, and that the goods and services they offer online are covered too. The DOJ gives businesses flexibility in how they comply but expects the result to be accessible. Other countries have their own laws, so check the rules where you operate.
What is WCAG, and which version should I follow?
WCAG, the Web Content Accessibility Guidelines, is the W3C's international standard for accessible web content. The W3C notes that WCAG 2.2 is also published as the ISO standard ISO/IEC 40500, which makes it the natural version to test against.
Will an accessibility overlay make my site compliant?
Not on its own. The DOJ says automated checkers and overlays can help but need careful use, and a clean report does not necessarily mean the site is accessible. The W3C adds that human evaluation is required to confirm a site meets the guidelines.
Does web accessibility help SEO?
Indirectly. Alt text, transcripts, logical headings and descriptive links help search engines understand a page, as well as people using assistive technology. Treat the search benefit as a bonus.
How long does it take to make a website accessible?
It depends. Content fixes such as alt text and captions can start this week, while code issues such as keyboard access take developer time and depend on how the site was built. WebAIM says a developer can learn the basics in a few days. Building accessibility in from the start, the W3C notes, is more efficient than going back to redo work.
Tab through your most important page this week
Pick the page that brings in the most business and put the mouse aside. Try to finish its main task with the keyboard alone, and write down each place you get stuck. That list is where your web accessibility work starts. To see how a full site review lays out problems and fixes, look through our sample SEO audit report, then talk to the team about what a review of your own site would cover.
Resources / References
- Introduction to Web Accessibility
- WebAIM
- MDN accessibility docs
- guidance on web accessibility and the ADA
Sources
About the author
SearchBlueprint researched, wrote and scored this article with the content pipeline our customers run on their own sites. The score in the byline is what our content engine gave this page before it published. Nothing here is reviewed by hand, which is the point: it is the product's output, published where anyone can check it.