What is web accessibility? A plain-language guide
Web accessibility means building websites, tools and technologies so that people with disabilities can use them. W3C says it covers auditory, cognitive, neurological, physical, speech and visual disabilities, and it also helps older people and anyone facing a situational limit such as bright sunlight. The technical yardstick is WCAG, which many accessibility laws name or build on.
Published . Last reviewed .
Web accessibility is about whether a person can use a website with the tools and abilities they have. A page that works for someone with a mouse and sharp eyesight can be unusable for someone who navigates by keyboard, listens to a screen reader or magnifies the text. This guide explains the idea in plain language, the standard it is measured against, the laws that point to it and a sensible place to start. Terms are defined in our accessibility glossary.
- How W3C defines web accessibility
- Who it helps
- The four principles
- WCAG, the standard
- What barriers look like
- How common the barriers are
- Why it matters
- Where to start
How W3C defines web accessibility
The World Wide Web Consortium (W3C) publishes the Web Content Accessibility Guidelines. In its introduction to web accessibility, W3C says that web accessibility means websites, tools and technologies are "designed and developed so that people with disabilities can use them." More specifically, W3C says people can perceive, understand, navigate and interact with the web, and contribute to it.
W3C adds that web accessibility encompasses all disabilities that affect access to the web, including auditory, cognitive, neurological, physical, speech and visual. It also benefits people without disabilities. W3C's examples are people using phones, smart watches and other small-screen devices, older people whose abilities change with age, people with a temporary disability such as a broken arm or lost glasses, people with situational limitations such as bright sunlight or a place where they cannot listen to audio, and people on slow or expensive connections.
"Web" here is wider than web pages. W3C's overview says WCAG applies to dynamic content, multimedia and the web on mobile, and that it can also be applied to non-web information and communications technology such as native apps, software and documents, as described in WCAG2ICT (W3C, WCAG overview).
Accessibility is not the same thing as usability or inclusion, although the three overlap. In its article Accessibility, Usability, and Inclusion, W3C describes usability as "about designing products to be effective, efficient, and satisfying," and inclusion as "about diversity, and ensuring involvement of everyone to the greatest extent possible." Accessibility keeps its focus on people with disabilities. W3C says the three have goals and approaches that overlap significantly and are most effective addressed together.
Who web accessibility helps
Disability is broader than the pictures most people have in mind. W3C's Diverse Abilities and Barriers pages describe five groups and say their examples are "not a complete list of all disabilities or barriers." The table summarizes what each group can run into on the web. Every row comes from the linked W3C page for that group.
| Group | What it covers | Example barriers W3C lists | What helps |
|---|---|---|---|
| Auditory | Hearing loss from mild or moderate in one or both ears to substantial and uncorrectable in both ears | Audio and video without captions or transcripts; media players with no volume controls | Captions, transcripts, volume and pause controls, and sign language for important information |
| Cognitive and learning | Differences that affect how people store, retrieve or use information; often only some functions are affected | Complex multi-stage forms, inconsistent navigation, time-outs, passwords that rely on memory, moving or blinking content that cannot be stopped | Clearly structured content, consistent labeling, simple words, predictable links and designs that make errors easy to correct |
| Physical | Limits on muscular control or sensation, joint disorders, pain that impedes movement and missing limbs | No full keyboard support; time limits that are too short; controls with images of text and no text alternative | Full keyboard support, enough time, large clickable areas, a visible indicator of the current focus and ways to skip repeated blocks |
| Speech | Difficulty producing speech that other people or speech recognition software can recognize | Services that rely on voice only; a phone number as the only way to contact an organization | Text chat, email and feedback forms as alternatives |
| Visual | Low vision to blindness, plus differences in how colors and brightness are perceived | Images without text alternatives; text that cannot be resized; insufficient contrast; video with no audio description | Text alternatives, resizable text, sufficient contrast, audio description and correctly coded structure such as headings and lists |
W3C's introduction also names neurological disabilities among those that affect access to the web. The same pages note that abilities change: a person may have a temporary impairment after an injury or surgery, a condition that varies from day to day, or a limit set by their surroundings.
The tools people use
People reach the same page in different ways. W3C's overview of tools and techniques describes assistive technologies as software and hardware that people with disabilities use to improve interaction with the web. They include screen readers that read pages aloud, screen magnifiers for some types of low vision, and speech recognition software and selection switches for people who cannot use a keyboard or mouse. W3C's pages also mention refreshable Braille and eye tracking and other hands-free approaches. W3C also describes adaptive strategies that need no special equipment, such as increasing text size, reducing mouse speed and turning on captions.
These tools work from a page's code, not its appearance. W3C says developers should correctly code the structure of a page so that browsers and assistive technologies can process and present it in different ways. That is why a page can look fine and still fail: the name, role and structure that software reads are missing. See the glossary entries for assistive technology, screen reader and accessible name.
How many people have a disability?
The World Health Organization's disability fact sheet, dated March 7, 2023, states: "An estimated 1.3 billion people experience significant disability." WHO describes this as 16% of the world's population, or 1 in 6. In the United States, a CDC release of July 16, 2024 said that more than 1 in 4 adults, over 70 million, reported having a disability in 2022, based on the 2022 Behavioral Risk Factor Surveillance System. Both figures count disability in general, not the number of people who would meet a particular barrier on your site.
The four principles: perceivable, operable, understandable, robust
WCAG organizes its requirements under four principles, often shortened to POUR. Every WCAG success criterion sits under one of them, so the principles are a quick way to think about what can go wrong.
| Principle | W3C's wording in WCAG 2.2 | In plain English |
|---|---|---|
| Perceivable | "Information and user interface components must be presentable to users in ways they can perceive." | Content reaches the senses a person has: text alternatives for images, captions for audio, enough contrast. |
| Operable | "User interface components and navigation must be operable." | Everything works with a keyboard and other input methods, people have enough time, and nothing flashes in a way that risks seizures. |
| Understandable | "Information and the operation of the user interface must be understandable." | Text is readable, pages behave predictably, and forms help people avoid and correct mistakes. |
| Robust | "Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies." | The code gives screen readers and other assistive technology a name and role for each control, so it keeps working across browsers and tools. |
The wording is from the WCAG 2.2 Recommendation; the plain-English column is ours. Our WCAG 2.2 criteria reference lists all 86 success criteria under their principles.
WCAG: the standard accessibility is measured against
The Web Content Accessibility Guidelines (WCAG) are published by W3C, which says in its WCAG overview that the documents "explain how to make web content more accessible to people with disabilities." WCAG 2.0 was published on December 11, 2008 and WCAG 2.1 on June 5, 2018. WCAG 2.2 became a W3C Recommendation on October 5, 2023 and was updated on December 12, 2024. W3C states that the October 2023 version of WCAG 2.2 is exactly the same as the ISO standard ISO/IEC 40500:2025.
W3C describes WCAG 2.0, 2.1 and 2.2 as backwards compatible: content that conforms to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0 (W3C, WCAG overview). The one exception is 4.1.1 Parsing, which WCAG 2.2 removed as obsolete. W3C notes that authors required by policy to meet 2.0 or 2.1 may need to continue to test and report it, and that the working group intends 2.2 to provide an alternate means of conformance for such policies (WCAG 2.2). Check the text of the law that applies to you. Our guide to which WCAG version a law requires shows which version each law names.
WCAG has layers. Four principles sit at the top. Under them are 13 guidelines, which state goals and are not themselves testable. Under the guidelines are success criteria, which are testable statements, and each carries a conformance level.
| Level | Criteria at this level | Note |
|---|---|---|
| A | 31 | The minimum level of conformance |
| AA | 24 (55 together with Level A) | The level most of the laws in our overview name, often for an older WCAG version |
| AAA | 31 | Not recommended as a general policy for entire sites, because some content cannot satisfy every AAA criterion |
The notes on Levels A and AAA paraphrase the conformance section of WCAG 2.2; the note on Level AA reflects the laws in our accessibility laws overview. For what each level asks of you, see WCAG levels A, AA and AAA.
WCAG does not claim to cover everything. Its abstract says following the guidelines "will not address every user need for people with these disabilities." Meeting every criterion is a floor, not a guarantee that every visitor can use the site.
WCAG 3.0 is a W3C Working Draft. W3C says WCAG 3 will not supersede WCAG 2 and that WCAG 2 will not be deprecated for several years after WCAG 3 is finalized, and no law we cover references it. See WCAG 3.0: status and what to do now.
What barriers look like
Five common barriers, each with the WCAG criterion behind it and a guide to the fix:
- An image with no alt text. A screen reader user gets no text for the picture. WCAG 1.1.1 asks for a text alternative that serves the equivalent purpose. See WCAG 1.1.1 Non-text Content and the alt text guide.
- A form field with no label. Assistive technology has no name to announce for the field, and WCAG 4.1.2 Name, Role, Value expects every control to have one. See the most common accessibility errors.
- Pale text on a light background. People with low vision struggle to read it, and so does anyone in bright sunlight. WCAG 1.4.3 sets 4.5:1 for normal text at Level AA. See WCAG 1.4.3 Contrast (Minimum) and the color contrast guide.
- A menu that works only with a mouse. Someone who navigates by keyboard cannot open it, and one with no visible focus outline cannot tell where they are on the page. WCAG 2.1.1 Keyboard and 2.4.7 Focus Visible cover both. Try the 5-minute keyboard test.
- A video with no captions. W3C lists audio and video without captions or transcripts as a barrier for people with auditory disabilities. WCAG 1.2.2 requires captions for prerecorded audio in synchronized media. See WCAG 1.2.2.
How common are the barriers?
WebAIM's WebAIM Million analysis of one million home pages found, in February 2026, that "95.9% of home pages had detected WCAG 2 failures," with an average of 56.1 errors per page. The failures concentrate in a few categories. Low contrast text was found on 83.9% of home pages, missing alternative text on 53.1% and missing form input labels on 51%. WebAIM reports that 96% of all errors it detected fall into six categories.
These counts come from automated detection, which covers only part of WCAG; see what automated testing can and cannot check. The same six categories map to free tools here: the color contrast checker, the alt text checker, the link text checker and the free scan. Our guide to the most common accessibility errors explains each and how to fix it.
Why web accessibility matters: legal and business reasons
The legal reasons
W3C states that "Web accessibility is required by law in many situations." Which law applies depends on where you operate, what kind of organization you are and, sometimes, how large you are. The table shows examples; each links to its primary source.
| Law | Who it covers | Standard and dates | Primary source |
|---|---|---|---|
| US: ADA Title II web rule (28 CFR Part 35, subpart H) | State and local governments, including special district governments | WCAG 2.1 Level AA. Compliance dates are April 26, 2027 (population 50,000 or more) and April 26, 2028 (under 50,000 and special districts) | ADA.gov web rule fact sheet |
| US: ADA Title III | Businesses open to the public | No web regulation. DOJ guidance of March 18, 2022 says the ADA applies to the web offerings of public accommodations and that existing technical standards, including WCAG, provide "helpful guidance" | DOJ web accessibility guidance |
| US: Section 508 | Federal agencies' information and communication technology | WCAG 2.0 Level A and AA. Final rule published January 18, 2017; required from January 18, 2018 | U.S. Access Board ICT standards |
| EU: European Accessibility Act (Directive (EU) 2019/882) | Listed consumer products and services, including e-commerce, wherever the provider is based; service microenterprises are exempt | EN 301 549 v3.2.1 (WCAG 2.1 AA). Applies since June 28, 2025 | EUR-Lex, Directive 2019/882 |
| UK: Equality Act 2010 and PSBAR 2018 | Service providers (Equality Act); public sector bodies (PSBAR) | The Equality Act names no technical standard; GOV.UK guidance for PSBAR names WCAG 2.2 AA | GOV.UK public sector guidance |
| Canada: Accessible Canada Act and Ontario AODA | Federally regulated organizations (the digital rules cover the public sector and private organizations with 100 or more employees); in Ontario, the public sector and businesses and non-profits with 50 or more employees | CAN/ASC-EN 301 549:2024 federally, with dates from December 5, 2027; WCAG 2.0 AA, excluding 1.2.4 and 1.2.5, in Ontario since January 1, 2021 | Government of Canada, Digital Technologies Phase 1; Ontario.ca |
Our accessibility laws overview covers more jurisdictions with a last-verified date for each, and the pages for the United States, European Union, United Kingdom and Canada go further. For the US federal technology rules, see Section 508 and WCAG; for deadlines that moved, see the ADA Title II deadline. The which accessibility laws apply tool asks a few questions and points to the rows that matter.
General information only
This guide is general information, not legal advice. Whether a law applies to you depends on facts such as where you operate, your sector and your size.
Where Title III has no web regulation, much of the enforcement in the United States comes from private lawsuits. Seyfarth Shaw counted 3,117 website accessibility lawsuits it could identify in federal court in 2025 (ADA Title III), up from 2,452 in 2024 (Seyfarth Shaw, March 25, 2026). See ADA website lawsuits and what to do if you receive an ADA website demand letter.
The business reasons
W3C's business case for digital accessibility names four ways accessibility can help an organization: drive innovation, enhance your brand, extend market reach and minimize legal risk. W3C's introduction says there is a strong business case. WCAG's own abstract adds that following the guidelines "will also often make web content more usable to users in general." These are W3C's arguments, not measurements of any one site, so weigh them against your own audience and goals.
What web accessibility is not
- It is not a product you install. The Overlay Fact Sheet, a statement by accessibility practitioners, argues that "full compliance cannot be achieved with an overlay." In April 2025 the FTC issued an order barring accessiBe from claiming that its product can make any website compliant with WCAG, or keep it compliant over time, unless it has competent and reliable evidence (FTC press release). See accessibility overlays and what the FTC found and what to use instead of an overlay.
- It is not something a scanner can certify. W3C says "no tool alone can determine if a site meets accessibility standards" and that knowledgeable human evaluation is required (W3C, Evaluating Web Accessibility). Our methodology page lists what our checks cover and what they cannot see.
- It is not a one-time project. New pages, uploads and releases bring new problems. W3C's planning guidance says to "continue to review and report on content, processes, and resources" (W3C, Planning and Managing Web Accessibility).
- It is not only about blind users. The table above covers five groups, and W3C's examples reach beyond disability altogether, from small screens to bright sunlight.
Where to start
This is a short path to begin with. The full version, with the WCAG criteria and a tool for each step, is how to make a website accessible.
- Pick a target. For most sites the practical target is WCAG 2.2 Level AA. The which accessibility laws apply tool and the which WCAG version guide show what your situation calls for.
- Scan for what a machine can find. The free scan runs 16 rule-based checks on up to three pages with no signup, and each finding names the WCAG success criterion it maps to. The accessibility bookmarklet runs checks on the page open in your own browser, including staging sites and pages behind a login.
- Fix the common failures. Images and alt text: the alt text guide and alt text checker. Contrast: the color contrast guide and contrast checker. Headings: the heading checker. Links: the link text checker. Documents: the PDF accessibility checker.
- Test it yourself. Use the site with only a keyboard, zoom the page, and try a screen reader. The guide to testing website accessibility covers automated and manual checks, and the 5-minute keyboard test is the quickest start.
- Say what you tested, and keep checking. Publish an accessibility statement (the statement generator drafts one), then re-check after each release. Paid plans run a weekly check of every monitored page, and the deep audit opens up to six images per page to check that alt text is true. See pricing.
If you want a person or a team to review a whole site, what a website accessibility audit is and what you get explains the options. If you build on a platform, there are guides for Shopify and WordPress.
Web accessibility questions
What does web accessibility mean in simple terms?
It means people with disabilities can use a website, whatever tools they rely on, such as a keyboard, screen reader, magnifier or voice control. W3C defines it as websites, tools and technologies that are designed and developed so that people with disabilities can use them.
Who benefits from web accessibility?
People with auditory, cognitive, neurological, physical, speech and visual disabilities benefit most directly. W3C also lists older people, people with a temporary disability such as a broken arm, people in bright sunlight or noisy places, and people on small screens or slow connections.
What is WCAG?
WCAG is the Web Content Accessibility Guidelines, W3C's standard for accessible web content. It has four principles, 13 guidelines and testable success criteria at levels A, AA and AAA. WCAG 2.2 has 86 success criteria, and laws that name a level usually name AA. See the WCAG 2.2 criteria reference.
Is web accessibility required by law?
In many situations, yes: W3C states that web accessibility is required by law in many situations. Which law applies depends on where you operate and whether you are a public body or a business. Start with the accessibility laws overview or the which laws apply tool.
Is web accessibility the same as meeting the ADA?
No. Web accessibility is the practice of making sites usable by people with disabilities. The ADA is one US law that can apply to a site. For businesses open to the public there is no Title III web regulation, and DOJ guidance says existing technical standards, including WCAG, provide "helpful guidance." Software cannot certify that a site meets the ADA. See ADA website compliance for businesses.
Can software make my website accessible?
Software can find some problems, but W3C says no tool alone can determine whether a site meets accessibility standards and that knowledgeable human evaluation is required. A script added to a page does not replace fixing the underlying code. See what to use instead of an accessibility overlay.
How do I check whether my website is accessible?
Start with an automated scan for what machines can find, then test manually with a keyboard, a zoomed browser and a screen reader. Our free scan runs 16 rule-based checks on up to three pages, and the testing guide covers the manual part.
See what your own website needs
The free scan runs 16 rule-based checks on up to three pages of your site and shows which WCAG success criterion each issue maps to. It cannot tell you that a site meets WCAG, and no tool can. No signup.
Scan my site for free