What is Web Accessibility?

What Web Accessibility Actually Means

Web accessibility is the practice of designing and building websites, applications, and digital content so that people with disabilities can perceive, understand, navigate, and interact with them. The World Wide Web Consortium’s Web Accessibility Initiative (W3C WAI) frames it simply: “Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.”

Practically, that means a blind visitor using a screen reader can read your content aloud. A user with low vision can zoom your text without layout breaking. A person with motor impairments can operate every interactive element with a keyboard. A deaf user can read captions on your videos. Someone with a cognitive disability can follow your navigation without getting lost. Accessibility is not a feature bolted on at the end — it’s a property of how the site is built from the start.

Accessibility overlaps heavily with usability (everyone can use the site effectively) and inclusive design (the design process considers the widest range of users from the outset). When people say “accessibility” in 2026, they usually mean conformance to the Web Content Accessibility Guidelines (WCAG) — the global technical standard we cover in detail below.

A closely related term is digital accessibility, which extends the same principles beyond web pages to mobile apps, PDFs, Microsoft Office and Google Docs files, kiosks, and any software a person with a disability might need to use. The legal and technical frameworks described in this article apply across all of those surfaces, not just traditional HTML pages.

Why Web Accessibility Matters in 2026

Three overlapping reasons, in rough order of importance:

• People. The CDC estimates roughly 61 million U.S. adults — about 1 in 4 — live with a disability. The World Health Organization puts the global figure at 1.3 billion (16% of the world population). Ignoring accessibility excludes a quarter of your potential audience from your site. It also excludes many more users who don’t self-identify as disabled but rely on the same design choices: older users with declining vision, users on phones in bright sunlight, users recovering from surgery, users with a newborn in one arm.
• Law. The legal landscape has sharpened dramatically since 2023. The U.S. Department of Justice’s Title II Final Rule (published April 24, 2024) requires state and local government websites and mobile apps to meet WCAG 2.1 Level AA, with compliance deadlines of April 24, 2026 and April 26, 2027 depending on jurisdiction size. The European Accessibility Act (effective June 28, 2025) extends conformance requirements to most digital products and services sold to EU consumers. ADA Title III web lawsuits in the U.S. run roughly 10,000+ per year, concentrated in California, New York, and Florida, where state laws stack monetary damages on top of federal injunctive relief.
• Business. Accessible sites are faster to load, cleaner to maintain, and consistently outrank inaccessible sites for the same queries. Accessibility practices — semantic HTML, alt text, descriptive links, logical heading order — overlap almost completely with SEO best practices. And an accessible site earns trust from a much larger audience: users over 65, users with temporary injuries, users on slow connections, users with situational limitations.

Legal risk tends to get the most attention, but it’s the weakest of the three reasons. The strongest is simply that accessibility is the right thing to do and produces better websites. Teams that frame accessibility as a compliance checkbox end up with defensive, minimal work that satisfies auditors and frustrates users. Teams that frame it as a quality and reach issue end up with sites that are better, faster, and cheaper to maintain — and, as a side effect, pass the audits.

The SEO overlap is worth pausing on. Many accessibility requirements are literally the same as on-page SEO best practices. Proper heading structure gives screen readers a table of contents and gives Google a content outline. Descriptive link text helps assistive tech and helps Googlebot understand page relationships. Alt text surfaces image content to screen readers and to image search. Fast-loading, mobile-reflowable layouts help low-vision users at 400% zoom and boost Core Web Vitals. Teams often discover that accessibility work improves organic traffic as a side effect — the same signals that make a page usable for a blind visitor also make it legible for a search crawler.

The People Web Accessibility Serves

Accessibility isn’t a niche concern. It’s an umbrella that covers many permanent, temporary, and situational limitations:

• Visual disabilities — blindness, low vision, color blindness, light sensitivity. Users may depend on screen readers, magnification software, high-contrast modes, dark modes, or custom style sheets. Color blindness alone affects roughly 8% of men and 0.5% of women, so using color as the only signal for status information is a bad choice for a meaningful slice of every audience.
• Auditory disabilities — deafness, hearing loss. Users rely on captions, transcripts, and visual alternatives to audio content. Captions also benefit people in loud environments, people who speak English as a second language, and everyone who now watches social video with the sound off.
• Motor disabilities — limited fine-motor control, tremors, paralysis, limb difference, repetitive strain injuries. Users may navigate with keyboard only, switch devices, eye tracking, or voice control — rarely a standard mouse. Any site that locks functionality behind hover, right-click, or complex gestures leaves these users stranded.
• Cognitive and learning disabilities — dyslexia, ADHD, autism, memory impairments, intellectual disabilities, anxiety disorders. Users benefit from plain language, consistent layouts, clear navigation, predictable behavior, and the absence of unexpected changes. Cognitive accessibility is the least-mature area of the field; WCAG 2.2’s new dragging-movement and consistent-help criteria are steps toward covering it better.
• Seizure and vestibular disorders — photosensitive epilepsy, migraine, motion sensitivity. Users can be harmed by flashing content or aggressive parallax and auto-play animation. Respecting the prefers-reduced-motion media query is the cheapest safety measure in this category.
• Speech disabilities — relevant when sites depend on voice input or phone contact without text alternatives.
• Age-related changes — declining vision, hearing, and dexterity affect most users eventually. Populations are aging in most developed countries, which makes this the fastest-growing slice of the accessibility audience.
• Situational limitations — bright sunlight, noisy environments, a broken arm, a baby in one hand, a slow or metered connection, public-computer use at a library. Situational users outnumber permanent ones by orders of magnitude and benefit from the same design choices.

A single accessible design choice — captioning a video, making a button reachable by keyboard, ensuring good color contrast, using descriptive link text — typically helps many of these groups at once. The reverse is also true: a single hostile design choice (tiny touch targets, hover-only menus, color-only error states) hurts many of them at once.

The curb-cut effect captures this well. Sidewalk curb cuts were originally required for wheelchair users, but they also help parents pushing strollers, delivery workers with carts, travelers with luggage, cyclists, and anyone who trips on a stray lip in the pavement. Web accessibility works the same way. Captions were originally required for deaf users; everyone benefits when they can watch autoplay video with the sound off. Keyboard accessibility was originally required for motor-disabled users; power users who prefer keyboard shortcuts benefit daily. Plain language was originally prioritized for cognitive disabilities; it helps every reader who is tired, distracted, or reading in a second language.

Assistive Technology in 2026

Assistive technology (AT) is hardware and software that helps people with disabilities interact with computers. Your site has to be built so AT can actually do its job. The main categories in 2026:

• Screen readers — software that reads the page aloud and exposes structure through keyboard navigation. Dominant tools: JAWS (commercial, Windows, still dominant in enterprise), NVDA (free, open-source, Windows — the most popular screen reader in the WebAIM Screen Reader User Survey since 2019), VoiceOver (built into macOS and iOS; the default on iPhone), Narrator (built into Windows), and TalkBack (built into Android). Window-Eyes, mentioned in many older accessibility articles, was discontinued on September 30, 2017 after Freedom Scientific’s parent company acquired its maker and retired the product. Screen readers depend on semantic HTML and ARIA roles to understand what a page means — they read what the browser exposes to the accessibility tree, not what is visually styled on screen.
• Screen magnification — built-in OS zoom (macOS Accessibility > Zoom, Windows Magnifier), browser zoom (Ctrl/Cmd + and up to 400% with reflow), and standalone tools like ZoomText (Windows) and SuperNova (Windows). Sites that reflow gracefully at 400% zoom and meet WCAG 1.4.10 (Reflow) and 1.4.12 (Text Spacing) work well with magnification.
• Speech recognition and voice control — Dragon NaturallySpeaking, Apple Voice Control, Windows Voice Access, Google Voice Access. Users navigate and dictate by voice; sites need accessible names on interactive elements for voice commands to target them. A button that says “Submit” in its accessible name can be activated by saying “Submit”; a button labeled only with an icon can’t.
• Switch access — users press one or more physical switches (buttons, sip-and-puff devices, head switches) to navigate; often combined with on-screen scanning that highlights each focusable item in turn. Requires logical tab order, no time-sensitive interactions, and no keyboard traps.
• Eye tracking — hardware like Tobii tracks gaze direction to move the cursor or select items. Users dwell on a target to click; some systems combine gaze with a switch or voice cue.
• Refreshable braille displays — hardware that translates screen reader output into tactile braille in real time, typically 14, 20, 40, or 80 cells at a time. Essential for deafblind users.
• Alternative keyboards and pointing devices — larger-key keyboards, one-handed keyboards, sip-and-puff controllers, head-tracking mice, joystick mice, trackball mice. For most of these, “keyboard-accessible site” is the practical test: if every function works from the keyboard, most alternative inputs work too.
• Captions, subtitles, audio descriptions, and transcripts — closed captions (built into video players, user-toggleable), open captions (burned into video, always on), audio descriptions (narration of visual content for blind users), and full transcripts (text alternatives for audio or video, essential for deafblind users and useful for everyone searching).
• Cognitive support tools — reader modes (Safari Reader, Firefox Reader View), text-to-speech add-ons (Read Aloud, NaturalReader), and focus-assistance extensions that strip clutter from pages. Sites that over-rely on JavaScript or pop-ups often break these tools.

Designers don’t have to test with every piece of AT, but they do have to build against standards (semantic HTML, ARIA, WCAG) so that AT can interpret the site correctly. The practical test bench is: NVDA or JAWS on Windows/Firefox, VoiceOver on macOS/Safari and iOS/Safari, keyboard-only navigation, and 400% zoom. That covers the majority of real-world AT use.

WCAG: The Global Standard

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the reference standard for web accessibility. They’re cited in accessibility law across the U.S., EU, Canada, UK, Japan, Australia, and dozens of other countries.

WCAG is organized around four principles — known as POUR:

• Perceivable. Information and interface components must be presentable in ways users can perceive. Covers text alternatives for non-text content, captions and audio descriptions for media, adaptable layouts, and distinguishability (color contrast, audio control, resizable text).
• Operable. Interface components must be operable. Covers keyboard accessibility, enough time to read and use content, no seizure-triggering flashes, navigable and findable content, and input modalities beyond the keyboard.
• Understandable. Content and operation must be understandable. Covers readable text, predictable behavior (things don’t change unexpectedly), and input assistance (errors are identified and explained).
• Robust. Content must be robust enough to work with current and future user agents, including assistive technology. In practice this means valid, well-formed markup and correct use of roles and states.

WCAG defines three conformance levels:

• Level A — the minimum. Removes the most severe barriers but still lets many through. Rarely a target level on its own.
• Level AA — the standard target for virtually all laws and regulations. The right baseline for most organizations.
• Level AAA — the strictest level. Not achievable site-wide for most dynamic content and not required by any major law. Individual AAA criteria are worth adopting selectively (for example, reading-level guidance for public-facing content).

Published versions:

• WCAG 1.0 (May 1999) — the original. Largely historical at this point; still referenced by a handful of older national laws.
• WCAG 2.0 (December 2008) — introduced the POUR principles and 61 success criteria. Still the baseline for U.S. Section 508 (refreshed 2018). ISO/IEC 40500:2012 is the ISO-standard version.
• WCAG 2.1 (June 5, 2018) — added 17 success criteria covering mobile, low vision, and cognitive needs. Additions include Orientation (1.3.4), Identify Input Purpose (1.3.5), Reflow (1.4.10), Non-Text Contrast (1.4.11), Text Spacing (1.4.12), Content on Hover or Focus (1.4.13), Character Key Shortcuts (2.1.4), Pointer Gestures (2.5.1), Label in Name (2.5.3), and Target Size (2.5.5). The current regulatory baseline in the DOJ Title II Final Rule and the EU’s EN 301 549.
• WCAG 2.2 (October 5, 2023) — added 9 further success criteria: Focus Not Obscured (2.4.11 AA and 2.4.12 AAA), Focus Appearance (2.4.13 AAA), Dragging Movements (2.5.7 AA), Target Size Minimum (2.5.8 AA, 24×24 CSS pixels), Consistent Help (3.2.6 A), Redundant Entry (3.3.7 A), Accessible Authentication (3.3.8 AA and 3.3.9 AAA). Backwards-compatible with 2.1, so most organizations now aim for 2.2 AA as the forward-compatible target.

WCAG 3.0 (sometimes called the W3C Accessibility Guidelines, or “Silver”) is in development as a more flexible scoring model with a new structure that covers a wider range of disabilities and emerging technologies. It is still at Working Draft stage in 2026 and not yet citable in policy or procurement. Don’t plan around 3.0 yet; build to 2.2 AA.

Practical WCAG examples by principle

Translating POUR into day-to-day work:

• Perceivable. Alt text on images (SC 1.1.1). Captions on pre-recorded video (1.2.2). Enough color contrast between text and background (1.4.3). Content that works in any orientation (1.3.4). Responsive layouts that reflow at 320 pixels (1.4.10).
• Operable. All functionality available from the keyboard (2.1.1). No keyboard traps (2.1.2). No flashing more than three times per second (2.3.1). Skip links or landmarks that let users bypass repeated blocks (2.4.1). Visible focus indicators (2.4.7). Target sizes at least 24×24 CSS pixels (2.5.8, WCAG 2.2).
• Understandable. The language of the page is set (3.1.1). Navigation is consistent across pages (3.2.3). Components that behave the same are identified consistently (3.2.4). Form errors are identified and labeled clearly (3.3.1, 3.3.3). Consistent help location across pages (3.2.6, WCAG 2.2).
• Robust. Markup is well-formed and parses cleanly (4.1.1 — obsoleted in 2.2 but still best practice). Name, role, and value of interactive components are programmatically determinable (4.1.2). Status messages are announced to assistive tech (4.1.3).

Most WCAG failures in real audits cluster around a handful of these: missing or bad alt text, low contrast, keyboard inaccessibility, missing labels on form inputs, and bad focus management. Fix those five patterns systemically and most sites jump from failing to passing AA.

Other W3C Accessibility Standards

WCAG isn’t the whole story. The W3C also publishes:

• WAI-ARIA (Accessible Rich Internet Applications) — a specification for adding semantic meaning to dynamic HTML widgets like tabs, modals, tree views, comboboxes, and live regions. WAI-ARIA defines roles (what something is), states (current condition), and properties (fixed attributes). The current version is WAI-ARIA 1.2, a W3C Recommendation since June 6, 2023. Use ARIA only when native HTML can’t express the semantics you need — the first rule of ARIA is “don’t use ARIA if you can use HTML.” A plain <button> beats <div role="button" tabindex="0"> every time.
• ATAG 2.0 (Authoring Tool Accessibility Guidelines) — a W3C Recommendation since September 24, 2015. Applies to tools that produce web content (CMS platforms, rich-text editors, site builders, WYSIWYG tools). ATAG asks two things: that the tool itself be accessible to authors with disabilities, and that it helps authors produce accessible output (e.g., prompting for alt text on image upload).
• UAAG (User Agent Accessibility Guidelines) — UAAG 1.0 became a W3C Recommendation in December 2002. UAAG 2.0 has not been finalized as a Recommendation; it remains a Working Group Note (published December 15, 2015). UAAG applies to browsers, media players, and other user agents. Older articles sometimes claim UAAG 2.0 was “approved in 2008” — that’s incorrect.
• ARIA Authoring Practices Guide (APG) — not a Recommendation but an actively maintained W3C document that provides concrete patterns for common UI widgets (disclosure, accordion, tabs, menu button, combobox, dialog, etc.). When building a dynamic widget, start here rather than inventing your own ARIA pattern.

For most teams, the practical hierarchy is: WCAG first, WAI-ARIA (guided by APG) where needed for dynamic widgets, ATAG if you build authoring tools, UAAG if you build browsers or media players.

U.S. Accessibility Law

The United States regulates web accessibility through several overlapping legal frameworks. For a deeper legal overview see our guide to the Americans with Disabilities Act and our explainer on U.S. web accessibility laws.

• Americans with Disabilities Act (ADA), 1990. The broadest U.S. disability-rights statute. Title I covers employment, Title II covers state and local government, Title III covers public accommodations (most private businesses), Title IV covers telecommunications, and Title V covers miscellaneous provisions. Courts have increasingly held that Title III applies to websites of public accommodations — most notably in Robles v. Domino’s Pizza (Ninth Circuit, January 2019; Supreme Court denied certiorari October 2019). The ADA was amended by the ADAAA in 2008, effective January 2009, which broadened the definition of disability.
• DOJ Title II Final Rule (April 24, 2024). The single biggest web accessibility regulatory development in U.S. history. State and local government websites, mobile apps, and third-party content they post or link to must meet WCAG 2.1 AA. Compliance deadlines: April 24, 2026 for jurisdictions serving 50,000 or more residents; April 26, 2027 for smaller entities and special-purpose districts.
• Section 508 of the Rehabilitation Act, 1998. Applies to federal agencies and federal contractors, covering the electronic and information technology they develop, procure, maintain, or use. Refreshed in January 2017 (effective January 2018) to conform to WCAG 2.0 AA and to harmonize with EN 301 549.
• 21st Century Communications and Video Accessibility Act (CVAA), 2010. Governs captioning, audio description, and accessibility of modern communications (IP-based video, mobile, advanced communications services). Enforced by the FCC.
• Section 504 of the Rehabilitation Act, 1973. Prohibits discrimination on the basis of disability in programs receiving federal financial assistance. Applies to public schools, universities, and federally funded programs; increasingly applied to their digital materials.
• Individuals with Disabilities Education Act (IDEA). Requires accessible educational materials for students with disabilities in K-12. Drives a large share of accessibility work in the education sector.
• State laws. California (Unruh Civil Rights Act), New York (state human-rights law), and several other states allow monetary damages for accessibility violations on top of federal injunctive relief. That’s why the bulk of ADA web lawsuits file in those states. Colorado’s HB21-1110 (effective July 2024) requires state government sites to meet WCAG 2.1 AA.

European Accessibility Law

The EU framework has two major legislative pieces plus the technical standard that underpins both:

• Web Accessibility Directive (Directive 2016/2102). In force since December 22, 2016; transposed by EU member states between September 2018 and June 2020. Requires public-sector body websites and mobile apps to meet accessibility requirements, publish an accessibility statement, provide a feedback mechanism, and undergo periodic monitoring.
• European Accessibility Act (EAA), Directive (EU) 2019/882. Effective June 28, 2025. Extends conformance obligations to a wide range of private-sector products and services, including e-commerce, consumer banking, e-books, transport, ATMs, ticketing machines, telecommunications services, and consumer communications equipment. Applies to any business offering covered products or services to EU consumers, regardless of where the business is based. Small and micro-enterprises have limited exemptions.
• EN 301 549. The EU’s harmonized technical standard for ICT accessibility, maintained by CEN, CENELEC, and ETSI. Incorporates WCAG 2.1 AA and adds requirements for software, hardware, and documentation. Both the Web Accessibility Directive and the EAA reference EN 301 549 as their technical baseline, which is what makes WCAG 2.1 AA the practical compliance target across Europe.

An organization serving EU consumers from outside the EU (common for U.S. e-commerce and SaaS) is now directly exposed to EAA enforcement. Compliance should be treated as a market-access requirement, not an optional gesture.

Accessibility Law Around the World

Coverage varies widely, but the trend is consistent: laws align on WCAG 2.0 or 2.1 AA and extend to both public and private sectors over time.

• United Kingdom. Equality Act 2010 prohibits discrimination in services, including online. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require WCAG 2.1 AA for UK public-sector sites. The Equality and Human Rights Commission (EHRC) enforces.
• Canada. Accessible Canada Act (June 2019) requires federally regulated entities to publish accessibility plans and progress reports. The Accessible Canada Regulations reference WCAG 2.1 AA. Provincial laws — AODA in Ontario, AMA in Manitoba, and similar statutes in Nova Scotia, British Columbia, and Newfoundland and Labrador — impose separate obligations with their own timelines.
• Australia. Disability Discrimination Act 1992 covers digital services. The landmark 2000 case Maguire v. Sydney Organising Committee for the Olympic Games established that inaccessible websites can be discriminatory. The Australian Government Digital Service Standard references WCAG 2.1 AA.
• Japan. JIS X 8341-3:2016 aligns with WCAG 2.0 and is referenced in government procurement and by major enterprises.
• Brazil. The Brazilian Inclusion Law (Lei Brasileira de Inclusão, LBI, 2015) requires accessibility for websites providing public information. eMAG, the Brazilian government accessibility model, aligns with WCAG 2.1 AA. Enforcement has tightened under Brazil’s general data and consumer protection agencies.
• Ireland. Disability Act 2005 requires accessibility of electronic communications. Also subject to the EU Web Accessibility Directive and the European Accessibility Act.
• Italy. Legge Stanca (2004), updated through the Agency for Digital Italy (AgID), references EN 301 549 / WCAG 2.1 AA and covers both public and private sectors.
• Norway. The Norwegian Equality and Anti-Discrimination Ombud enforces accessibility regulations that reference WCAG 2.1 AA across public and most private digital services. Norway is one of the few European countries to have applied EU-style accessibility rules to the private sector before the EAA.
• Israel. IS 5568 aligns with WCAG 2.0 AA; enforced by the Commission for Equal Rights of Persons with Disabilities.
• India. The Rights of Persons with Disabilities Act 2016 and the Guidelines for Indian Government Websites (GIGW) reference WCAG 2.0 / 2.1 AA for government sites.

Even in countries without formal legislation, major organizations typically adopt WCAG as their internal standard because it’s the reference point for everyone else. If you’re building for a global audience, designing to WCAG 2.1 AA (with 2.2 AA on deck) is the simplest way to stay aligned with every major regime at once.

What Developers Build In

Most accessibility work happens in the build. A short list of what matters most:

• Semantic HTML. Use the right element for the job — <button> for actions, <a> for navigation, <h1>–<h6> for structure, <label> for form inputs, <nav>/<main>/<aside>/<header>/<footer> for landmarks, <table> with <th>/<scope> for tabular data. Semantic HTML is free accessibility; divs-and-classes on everything is where most accessibility bugs start.
• Keyboard support. Every interactive element reachable and operable with Tab, Shift+Tab, Enter, Space, and arrow keys (for composite widgets). Visible focus indicators on every focusable element (WCAG 2.4.7). No keyboard traps. Modals trap focus while open and restore focus to the trigger on close.
• Color contrast. WCAG 2.1 AA requires 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt+ bold), and 3:1 for non-text UI components and graphical objects. WCAG 2.2 adds additional contrast considerations for focus indicators.
• Alt text on images. Descriptive alt for images that convey information, empty alt (alt="") for purely decorative images, and treat CSS background images as decorative by default. Icons that function as buttons need accessible names — either visible text or aria-label.
• ARIA — sparingly. Use native HTML whenever it covers the pattern. Reach for ARIA only when building widgets (comboboxes, tabs, dialogs, tree views) that native HTML can’t express. Bad ARIA is worse than no ARIA — an incorrectly applied role can hide content from assistive tech entirely.
• Responsive, reflowable layouts. Content must reflow at 320 CSS pixels wide (WCAG 1.4.10), and zoom to 400% without loss of functionality. Horizontal scrolling for main content is an accessibility failure.
• Motion and animation. Respect the prefers-reduced-motion media query. Avoid content flashing more than three times per second (WCAG 2.3.1). Provide pause/stop controls on any auto-playing content (WCAG 2.2.2).
• Forms. Every input has a visible label (WCAG 3.3.2) associated via <label for> or nested <label>. Errors are announced to assistive tech through ARIA live regions or form validation APIs, not just shown in red (WCAG 3.3.1). Autocomplete attributes (autocomplete="name", autocomplete="email", etc.) help users with cognitive and motor disabilities (WCAG 1.3.5).
• Page title and language. Every page has a unique, descriptive <title> (WCAG 2.4.2) and sets the primary language on the <html> element (WCAG 3.1.1) so screen readers pronounce content correctly.

What Content Authors Write For

Content people own as much of accessibility as engineers do:

• Meaningful headings. One H1 per page, logical H2/H3 nesting, descriptive text (not “Section 2”). Screen reader users commonly navigate by heading — a well-structured outline is their table of contents.
• Meaningful link text. “Read the 2024 rule” beats “click here” or “learn more.” Screen reader users often skim a page by listing all its links out of context; vague anchors are useless in that mode.
• Plain language. Short sentences, concrete words, active voice. WCAG 3.1.5 (AAA) asks that content be readable at a lower-secondary education reading level; most general-audience content should aim there even if AAA isn’t a target. Tools like Hemingway Editor and Flesch-Kincaid readability checks help.
• Alt text that says what the image means. For a chart, describe the takeaway, not the shape. For a decorative image, use empty alt. For a purely visual brand element (a background photo), empty alt. For a complex infographic, provide a long description nearby or via aria-describedby.
• Captions, transcripts, and audio descriptions. Captions for pre-recorded video (WCAG 1.2.2). Transcripts for audio-only content. Audio descriptions when the video conveys essential visual information not already in the audio (WCAG 1.2.3 A, 1.2.5 AA).
• Consistent navigation and terminology. The same link goes to the same place (WCAG 3.2.3 and 3.2.4). The same component is called the same thing in every context.
• Abbreviations and unfamiliar terms. Expand acronyms on first use. Provide definitions for jargon, especially in technical, legal, or medical content.
• PDF and Office-document accessibility. Set heading levels, alt text on images, table headers, reading order, document language, and a descriptive title. An inaccessible PDF posted on an accessible site is still an accessibility failure.

Testing Your Site

Accessibility testing has three layers, and all three matter:

• Automated testing — tools that scan HTML for issues. Useful catches: missing alt, empty labels, low-contrast combinations, invalid ARIA, duplicate IDs, missing language attributes, broken heading structure. Common tools: axe DevTools (browser extension plus CI integration), WAVE (browser extension by WebAIM), Google Lighthouse (built into Chrome DevTools), Pa11y (command-line, CI-friendly), axe-core (the open-source library powering many of these), IBM Equal Access, accessibility-insights.io (Microsoft). Automated testing catches roughly 30–40% of WCAG issues — valuable, but not sufficient on its own.
• Manual testing — a human runs through the site without a mouse, then with a screen reader, then at 400% zoom, then with the OS in high-contrast mode, then with Windows Forced Colors or macOS Increase Contrast enabled. Manual testing catches the 60%+ of issues automation can’t see: meaningful keyboard order, sensible announcement of dynamic content, logical focus management after modals open or remove, descriptive link text in context, whether alt text actually describes the image rather than merely exists.
• User testing with people with disabilities — the gold standard. Real users catch usability problems no checklist finds and produce the specific stories that move accessibility work up the backlog. Fable, Applause, Knowbility, and Deque all offer user-testing services; in-house employee resource groups (ERGs) can also participate in informal testing.

Enterprise teams often add full-site crawlers — Siteimprove, Monsido, Deque Axe Auditor, Silktide, and Dyno Mapper’s accessibility testing — to catch regressions across thousands of pages. Integrate at least automated checks into CI so new issues fail the build, and schedule manual and user testing for critical flows before every major release.

Document what you test and when. The DOJ Title II rule, the European Accessibility Act, and most other regulatory regimes expect organizations to be able to show a documented accessibility testing program — not just a one-time audit.

Organizational Practices

Accessibility holds up when it’s an operating practice, not a project. Most mature programs have:

• A written accessibility policy — a public accessibility statement plus an internal operating policy. The public statement declares the standard (e.g., WCAG 2.1 AA), current conformance, how to report issues, and how long the organization takes to respond. The internal policy covers roles, development standards, procurement, testing, training, and escalation. For a step-by-step guide see how to develop organizational policies on web accessibility.
• Training — onboarding for new designers, developers, content authors, QA, and product managers; role-specific deep dives; annual refreshers that cover standards updates (WCAG 2.2 criteria, for example) and lessons from the year’s audits.
• Procurement requirements — vendor tools and third-party components must provide a VPAT / Accessibility Conformance Report (ACR) documenting WCAG conformance before purchase. This is now the baseline for federal and most state/local government procurement in the U.S., EU public-sector procurement, and increasingly common in the private sector.
• A testing and audit cadence — automated scans on every pull request, manual testing before release for critical flows, quarterly full-site audits, annual third-party audits. Auditors rarely catch everything, but a rotating cadence surfaces regressions that internal teams become blind to.
• An incident path — how a reported accessibility issue gets triaged, assigned, remediated, and communicated back to the reporter. A 10-business-day acknowledgement and a remediation timeline tied to severity is typical.
• Accessibility in design systems. The cheapest way to scale accessibility is to bake it into the shared component library: every button, form, modal, dialog, and table in the design system is accessible by construction, so teams that use it inherit accessibility by default. Conversely, accessibility bugs in a design system ripple across every product that consumes it.

Common Misconceptions and Pitfalls

A handful of patterns trip up otherwise well-intentioned teams:

• Accessibility overlay widgets. Third-party scripts promising to “instantly make your site accessible” (AccessiBe and similar products) are broadly considered ineffective by the accessibility community and have been the subject of their own lawsuit wave. They don’t fix underlying markup, they often interfere with users’ own assistive technology, and they can’t address cognitive or usability issues at all. They may create liability rather than reduce it.
• “We have an accessibility statement, so we’re covered.” A statement without underlying conformance is an invitation to a lawsuit. Publish the standard you actually meet, and then meet it.
• Inflated conformance claims. Claiming WCAG AAA or 2.2 AA when the site is actually at 2.0 A is worse than claiming nothing. Conformance claims have been central to several high-profile ADA settlements.
• Retrofitting at the end. Adding accessibility after a site is built typically costs 10 to 20 times what it would cost to build it in from the start. Push accessibility into design systems, component libraries, templates, and the definition of done for every feature.
• Treating accessibility as a developer problem. Content authors, product managers, designers, and procurement all have significant ownership. If it’s “an engineering ticket,” it won’t hold up past the first quarter.
• Testing only with automation. Automation catches 30–40% of issues. A site that passes an automated scan is not an accessible site; it is a site that has no detectable automated failures.
• Confusing accessibility with disability-specific features. A “high-contrast mode toggle” in the site footer is not the same as meeting the contrast success criteria for everyone. A separate “accessibility page” or “text-only version” is usually a sign that the main site isn’t accessible.
• Ignoring mobile. WCAG applies equally to mobile sites and native apps. Small target sizes, gesture-dependent controls, and modal pop-ups that trap focus are common mobile accessibility failures.

Frequently Asked Questions

What’s the difference between WCAG 2.0, 2.1, and 2.2?

WCAG 2.0 (December 2008) defined the four POUR principles and 61 success criteria. WCAG 2.1 (June 2018) added 17 more criteria, mostly for mobile and low-vision users. WCAG 2.2 (October 2023) added 9 more, including minimum target size, focus appearance, and dragging-movement alternatives. Each version is backwards-compatible — any site meeting 2.2 AA also meets 2.1 AA and 2.0 AA.

Which WCAG conformance level should we target?

WCAG 2.1 AA at minimum, with 2.2 AA as the forward-compatible target. AA is the level cited by virtually every major law and regulation, including the DOJ Title II Final Rule and the EU’s EN 301 549. Level AAA is rarely achievable site-wide for dynamic content and isn’t required by any law.

Does the ADA apply to my website?

If you’re a state or local government or agency, the DOJ Title II Final Rule (April 2024) directly applies and requires WCAG 2.1 AA by April 2026 or 2027. If you’re a business covered by ADA Title III (“places of public accommodation,” which courts have increasingly read to include e-commerce), you’re exposed to ADA-based lawsuits even without a specific technical standard named in the statute. The conservative answer is yes — build to WCAG 2.1 AA and publish an accessibility statement.

Are accessibility overlays a real fix?

No. Overlay widgets that promise to make a site accessible by injecting a script are broadly rejected by the accessibility community and have generated their own wave of ADA lawsuits. They don’t fix underlying markup, they often interfere with users’ own assistive technology, and they can’t address cognitive or usability issues at all. Real accessibility is built into the site.

How much of accessibility can we catch with automated tools?

Roughly 30–40% of WCAG issues. Automated tools are good at detecting missing alt text, empty labels, low contrast, invalid ARIA, and duplicate IDs. They can’t evaluate whether alt text actually describes the image, whether keyboard tab order is logical, whether link text is meaningful in context, or whether a dynamic widget announces state changes to screen readers. Combine automated scans with manual testing (keyboard, screen reader, zoom) and, when possible, user testing with people with disabilities.

Where to Start if You Haven’t Yet

A first-pass accessibility program for an existing site, in rough order of impact:

• Run an automated baseline. Point axe DevTools, WAVE, and Lighthouse at your top 20 pages. Capture the errors. That’s your starting backlog and your reference for measuring progress.
• Fix the five biggest-category issues first. Missing alt text, low contrast, missing form labels, keyboard inaccessibility, and bad focus indicators. These are typically responsible for most of the failures that automated tools detect, and they’re usually systemic — a single fix in a component library can resolve hundreds of page-level instances.
• Add keyboard and screen-reader testing to your release process. Even a 15-minute keyboard walk-through before each release catches a surprising amount.
• Write an accessibility statement. Declare the standard you aim to meet, your current conformance status, and how users can report problems. Publish it at a predictable URL (usually /accessibility or linked from the footer).
• Put accessibility into your design system. The components used across your product should be accessible by construction — accessible buttons, inputs, modals, menus, tables. This is where scaled accessibility lives.
• Add procurement requirements. Require VPATs or ACRs for any new vendor tool or component before purchase. You inherit the accessibility of every third-party thing you embed.
• Schedule a full audit. Internal or third-party, against WCAG 2.1 AA, covering a representative sample of templates and user journeys. Use the results to set a measurable remediation plan with owners and dates.

None of these steps require a large team or a dedicated budget line at first. Most organizations start with one or two motivated engineers, a product manager who owns the policy, and a tool subscription — then scale from there as the work proves its value.

Expect the work to be uneven. Early wins tend to be cheap (semantic HTML fixes, alt text backfills, contrast adjustments). Later work often involves refactoring complex widgets, rebuilding modal and menu patterns from the design system outward, and replacing legacy components that resist accessibility retrofits. Plan capacity for those projects before they’re urgent, because they are almost always the pieces that trip up external audits and lawsuits. The organizations that stay ahead of accessibility treat it as a permanent line in the engineering roadmap, not an occasional remediation sprint.

Bottom Line

Web accessibility is the practice of building sites people with disabilities can actually use. The technical reference standard is WCAG — target 2.1 AA today, with 2.2 AA as the forward-compatible goal. U.S. state and local government sites are now legally bound to WCAG 2.1 AA under the DOJ Title II Final Rule (compliance by April 2026 or 2027 depending on size). The European Accessibility Act extends private-sector conformance to EU-sold digital products and services as of June 28, 2025. Build semantic HTML, test with automation and real assistive technology, publish a policy, train your teams, and treat accessibility as an operating practice rather than a compliance box. Done well, it makes your site better for everyone, not just the 1 in 4 users who most need it.