The Web Content Accessibility Guidelines (WCAG)

What are the Web Content Accessibility Guidelines (WCAG)?

The Web Content Accessibility Guidelines (WCAG) is an international standard developed by the Web Accessibility Initiative (WAI), a part of the World Wide Web Consortium (W3C). WCAG exists to remove the digital barriers that prevent disabled people from interacting with web content on equal terms with everyone else.

The guidelines provide technical recommendations for building accessible digital content and serve as the reference standard for accessibility legislation around the world, including the Americans with Disabilities Act (ADA) in the US and the European Web Accessibility Directive.

While WCAG itself is not directly enforceable, it underpins mandatory regulations globally. Section 508, AODA, CVAA, and Australia’s DDA are built on WCAG 2.0 Level A and AA success criteria. The EU Web Accessibility Directive requires compliance with WCAG 2.1 Level A and AA.

WCAG versions 2.0, 2.1, 2.2, and 3.0

WCAG has evolved significantly since version 1.0 in 1995. The current active versions are:

• WCAG 2.0 — published December 11, 2008
• WCAG 2.1 — published June 5, 2018; currently the W3C recommended version
• WCAG 2.2 — published October 5, 2023

Each new version adds requirements to address a wider range of users and barriers:

• WCAG 2.0 established 61 success criteria
• WCAG 2.1 added 17 more success criteria, with a focus on mobile accessibility, low vision, and cognitive and learning disabilities
• WCAG 2.2 adds nine new success criteria (plus an update to one existing criterion), further expanding coverage for disabled people with cognitive disabilities and those who rely on touch or pointer-based input

All versions in the 2.x series are backward compatible: content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0.

The four principles (POUR)

WCAG 2.x organizes its requirements around four principles, commonly abbreviated as POUR:

• Perceivable: Information and user interface components must be presented in ways users can find, process, and understand — regardless of how they consume content.
• Operable: All functionality and navigation must be usable, including by people who rely on keyboards, switches, or other assistive input methods.
• Understandable: Information and the operation of the interface must be clear and predictable for users of all abilities.
• Robust: Content must be built to work reliably across a wide range of current and future browsers and assistive technologies.

Each principle contains testable success criteria that define what accessibility looks like in practice.

Understanding WCAG Conformance Levels: A, AA, and AAA

WCAG organizes its success criteria into three conformance levels. It is important to understand that these levels define a floor, not a ceiling. Meeting a conformance level does not mean accessibility work is complete — it means the baseline for that level has been cleared. True accessibility requires continuous attention, testing with real users, and a commitment to ongoing improvement.

Level A: Baseline access

Level A represents the minimum requirements for basic access. Without meeting Level A criteria, some disabled people will be entirely blocked from accessing content. These criteria address fundamental barriers that must be removed for any meaningful use of a website.

Examples of Level A success criteria:

• All non-text content, such as images and video, must have a text alternative that serves an equivalent purpose
• Users can navigate the website effectively using only a keyboard
• Audio that auto-plays for more than three seconds must be controllable: users must be able to pause, stop, or adjust volume
• Time-based media must have a text or audio alternative

Level AA: Industry standard

Level AA is the widely adopted industry standard and the level referenced by most accessibility laws and regulations. Meeting Level AA requires more deliberate design and technical implementation, and results in a site that works for a significantly broader range of users and assistive technologies.

Examples of Level AA success criteria:

• Content does not rely on orientation (portrait or landscape) unless a specific orientation is essential
• Text can be resized up to 200% without assistive technology and without loss of content or functionality
• Headings and labels describe topic or purpose
• Navigation elements that repeat across pages appear in the same relative order
• When errors occur in forms, suggestions for correction are provided

Level AAA: High-access inclusion

Level AAA goes beyond the standard requirements to support a wider range of needs and use cases. While not every site will meet all AAA criteria, organizations that serve diverse or specialized audiences should work toward as many AAA criteria as possible.

Examples of Level AAA success criteria:

• Text and images of text have a contrast ratio of at least 7:1
• All pre-recorded audio content has sign language interpretation
• Users can suppress or postpone interruptions, except emergencies
• A mechanism is available for identifying the meaning of abbreviations, idioms, and jargon

WCAG 2.1 in depth

WCAG 2.1, published in 2018, introduced 17 additional success criteria to address gaps in coverage for mobile users, disabled people with low vision, and disabled people with cognitive or learning disabilities.

Level A additions

• Captions are required for pre-recorded audio content
• When content sequence is essential to its meaning, that sequence must be programmatically defined
• Color must not be the only visual means of conveying information or prompting an action
• If a keyboard interface allows focus to move to a component, the user must also be able to move focus away from it using only the keyboard

Level AA additions

• Content display is not restricted to portrait or landscape unless a specific orientation is essential
• Text can be resized up to 200% without loss of content or functionality
• Headings and labels describe topic or purpose
• Repeated navigation elements appear in the same relative order across pages

Level AAA additions

• All pre-recorded audio has sign language interpretation
• Users can suppress or postpone interruptions, except for emergencies
• Mechanisms are available for identifying abbreviations and unusual use of language

WCAG 2.2 in depth

WCAG 2.2, published in October 2023, is increasingly being adopted by organizations and referenced in updated regulatory guidance. It adds nine new success criteria (and updates one) with a particular focus on disabled people with cognitive disabilities and those navigating via touch or pointer devices.

Key additions in WCAG 2.2 include:

Focus appearance (Level AA)

Keyboard focus indicators must meet minimum size and contrast requirements, making it clearer for users which element is currently active.

Dragging movements (Level AA)

Any functionality that uses dragging must also be achievable through a single-pointer action, such as a tap or click, ensuring disabled people who cannot drag due to motor impairments or device limitations are not excluded.

Target size (Level AA)

Interactive targets, such as buttons and links, must meet a minimum size requirement (at least 24 x 24 CSS pixels) so they are reliably usable for disabled people with motor disabilities or on touch screens.

Accessible authentication (Level AA)

Authentication processes must not require users to solve puzzles or transcribe characters unless an alternative method is available. This addresses significant barriers for disabled people with cognitive disabilities.

Consistent help (Level A)

Help mechanisms, such as contact information or support chat, must appear in the same location across pages, reducing cognitive load for disabled people who rely on predictable interfaces.

Redundant entry (Level A)

Information that users have already entered in a multi-step process should not be required again, reducing the effort and potential for error for disabled people with cognitive or motor disabilities.

Organizations currently working toward WCAG 2.1 compliance are well-positioned to address the 2.2 additions, as the new criteria are incremental rather than structural changes.

What is WCAG 3.0?

WCAG 3.0 is not simply another incremental update. It represents a fundamental rethinking of how accessibility guidelines are structured. It is currently being developed under the name W3C Accessibility Guidelines (WCAG 3) and incorporates a holistic, outcomes-based approach that evaluates accessibility through user-centric testing, rather than relying solely on technical success criteria.

Where WCAG 2.x asks whether specific technical conditions are met, WCAG 3 will also ask whether disabled people can accomplish tasks effectively and equitably. This marks a meaningful shift toward centering disabled people’s experiences in the evaluation of accessibility, not just the underlying code.

WCAG 3 is still in active development and is not expected to be finalized for several years. It is not yet suitable for use as a compliance target.

Who is responsible for accessibility?

WCAG was originally intended as a guideline for web content developers, authoring tool developers, and accessibility evaluation tool developers.

In practice, accessibility is the responsibility of any organization with an online presence. This includes product teams, marketers, content creators, designers, policymakers, and business leaders. An inaccessible website excludes a significant portion of the global population from information and services. That is not a niche concern or an edge case — it is a failure to meet a basic standard of inclusion and equity.

Most international legislation references WCAG 2.0 Level AA as the minimum requirement, making compliance a legal baseline in many jurisdictions. But meeting a specific conformance level is not the same as being truly accessible. Legal minimums are starting points.

Why accessibility matters: inclusion, equity, and good business

The primary reason to invest in accessibility is straightforward: disabled people deserve equal access to information, products, and services. The website is the barrier, not the user. When digital content is inaccessible, organizations are actively excluding people, not the other way around.

Beyond the fundamental ethical case, accessibility is also sound business practice:

Reaching your full audience

An estimated 1.3 billion people globally — about 16% of the world’s population — experience significant disability. An inaccessible website is not a website for everyone. Organizations that fail to address accessibility are voluntarily limiting their audience and excluding potential customers, constituents, or community members.

Better experience for all users

Accessible design improves the experience for every user — a principle sometimes called the curb-cut effect. Features designed to remove barriers for disabled people, such as high contrast text, clear navigation, keyboard operability, and well-labeled controls, consistently benefit people with situational limitations, aging users, and anyone in a challenging environment. Accessibility and usability are not separate goals.

Search visibility

A website that is fully accessible to assistive technologies is also more readable by search engine crawlers. Clear structure, descriptive headings, proper use of alt text, and logical content hierarchy all contribute to better search visibility. Accessibility and SEO reinforce each other.

Legal risk reduction

Compliance with WCAG is widely referenced by accessibility regulations worldwide. Building to WCAG standards is a meaningful step toward meeting those legal obligations, though organizations should consult legal counsel for jurisdiction-specific guidance.

How to test and improve your website’s accessibility

Meaningful accessibility cannot be achieved through automated tools alone. Automated testing tools typically identify 30 to 40 percent of accessibility barriers. They are valuable for continuous monitoring and catching common programmatic errors at scale. But they cannot evaluate whether disabled people can actually accomplish tasks on your website.

A complete accessibility testing practice includes three layers:

1. Automated scanning

Automated tools can audit your site against machine-testable WCAG criteria and flag issues such as missing alt text, insufficient color contrast, and improper form labeling. These tools help teams identify and track issues horizontally across large sites. Acquia Web Governance’s Web Accessibility Module does this, providing dashboards, compliance reporting, and recommendations based on WCAG 2.0, 2.1, and 2.2 criteria.

Where issues can be addressed through automated guidance, Acquia Web Governance goes further: AI-powered fix suggestions are delivered right in your browser, page-specific and routed by role. Designers see design fixes. Content authors see content fixes. Developers see code fixes. These are recommendations for your team to review and implement, not automated changes applied without human oversight. The goal is to take your team from identified to resolved without the guesswork, while keeping humans in control of every fix.

Automated scanning and AI-assisted guidance are the starting point, not the complete solution.

2. Manual testing with assistive technologies

Manual testing is essential for catching barriers that automation cannot detect, such as confusing navigation patterns, unclear error messages, or interactions that technically pass criteria but fail in practice. Testers should use screen readers (such as NVDA, JAWS, and VoiceOver), keyboard-only navigation, and other assistive technologies to evaluate the experience directly.

3. Testing with disabled people

The only way to validate that a website is truly accessible is to test it with disabled people who use assistive technologies as part of their daily lives. Their lived expertise will surface barriers that automated tools and manual checklists cannot catch. This kind of testing should be an ongoing part of your accessibility practice, not a one-time audit.

Acquia Web Governance supports automated scanning and AI-assisted guidance as part of this broader practice. We advocate for teams to pair these tools with manual review and direct testing with disabled people to build a genuinely inclusive digital experience.

How Acquia Web Governance supports your accessibility program

Acquia Web Governance’s Web Accessibility Module audits your entire site against WCAG 2.0, 2.1, and 2.2 criteria. Each audit scans for machine-testable issues, provides detailed reports, offers targeted remediation guidance, and shows compliance by level A, AA, and AAA. Progress can be tracked over time through the History Center.

AI-powered fix suggestions, available in the browser extension, give your team page-specific, role-appropriate guidance the moment an issue is surfaced — so the right fix reaches the right person without coordination overhead. Every suggestion is a recommendation for your team to review and act on, keeping humans accountable for every change.

We also offer accessibility training and support for customers as part of our service, covering both automated and manual remediation approaches.

Acquia Web Governance also provides complementary tools including a color contrast checker for web teams, and an accessibility statement generator to help you publish a transparent, public commitment to accessibility.

Learn more about how Acquia Web Governance helps websites anticipate and comply with accessibility guidelines.