WCAG

WCAG stands for Web Content Accessibility Guidelines. It is an international technical standard that explains how to design and build websites, online stores, applications, and digital content so that people with disabilities can use them. WCAG is developed by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative.

WCAG is not a single feature, plugin, or visual checklist. It is a structured set of testable requirements covering design, code, content, and interface behavior. These requirements address issues such as color contrast, keyboard navigation, image alternatives, heading structure, accessible forms, visible focus indicators, and compatibility with screen readers.

What does WCAG mean?

The acronym WCAG comes from Web Content Accessibility Guidelines. The standard describes the outcomes a website or application must achieve to make its content and functionality accessible.

WCAG is technology-agnostic. It does not require every website to use the same design or implementation. A success criterion can often be met in several ways, as long as users receive equivalent access to the same information and functionality.

The standard is organized into principles, guidelines, and success criteria. The success criteria are testable requirements used to evaluate whether a website or application conforms to a specific WCAG version and level.

The four WCAG principles

WCAG is built around four foundational principles known by the acronym POUR: Perceivable, Operable, Understandable, and Robust. For a digital experience to be accessible, it must address all four.

1. Perceivable

Information and interface components must be presented in ways users can perceive. A blind user may need a text alternative for a meaningful image, while a Deaf or hard-of-hearing user may need captions for a video. Text needs sufficient contrast, and the layout should remain usable when content is enlarged.

2. Operable

Users must be able to operate the interface with different input methods. This includes complete keyboard access, a logical focus order, visible focus indicators, adequately sized targets, and ways to pause or stop moving and automatically updating content. A user should never become trapped inside a menu, modal, or form component.

3. Understandable

Content and interface behavior should be clear and predictable. Navigation should remain consistent, form fields need descriptive labels, and error messages should explain what went wrong and how to fix it. Clear language, logical information architecture, and correctly identifying the page language also support this principle.

4. Robust

Content must work reliably across browsers, devices, and assistive technologies. Interactive components need accurate programmatic names, roles, values, and states. This allows a screen reader to tell the user whether an element is a button, form field, expanded menu, selected tab, or another type of control.

WCAG conformance levels: A, AA, and AAA

WCAG defines three levels of conformance:

• Level A contains the most fundamental accessibility requirements. Failing these criteria can make a website or feature completely unusable for some people.
• Level AA includes all Level A criteria plus additional requirements that address the most common and significant barriers. It is the target most frequently used in laws, procurement requirements, policies, and commercial accessibility programs.
• Level AAA is the highest level. It includes all criteria at Levels A, AA, and AAA, but full AAA conformance may not be practical or possible for every type of website and content.

When an organization states that a website conforms to WCAG 2.2 Level AA, the claim should mean that all applicable Level A and Level AA success criteria in WCAG 2.2 have been met. Passing a handful of checks, such as contrast and keyboard access, is not enough.

Conformance also applies to complete pages and processes. For example, an online store is not fully accessible if a customer can browse products and add one to the cart but cannot complete checkout, fix a validation error, or choose a payment method.

WCAG 2.0, WCAG 2.1, and WCAG 2.2

WCAG has evolved alongside changes in technology and the ways people access digital services:

• WCAG 2.0 was published in 2008. It introduced the four core principles and technology-independent success criteria that established the foundation of the WCAG 2 family.
• WCAG 2.1 was published in 2018. It added requirements that better address mobile accessibility, low vision, and the needs of people with cognitive and learning disabilities.
• WCAG 2.2 became a W3C Recommendation in 2023. It expanded the standard with criteria related to unobscured keyboard focus, alternatives to dragging, minimum target size, redundant form entry, consistent help, and accessible authentication.

Later WCAG 2 versions retain the requirements from earlier releases and add new success criteria. W3C currently recommends using WCAG 2.2. However, if a law, contract, policy, or procurement specification names WCAG 2.1, the evaluation must still follow the exact version and conformance level stated in that requirement.

WCAG 3 is also under development, but it remains an incomplete draft. It is not currently a replacement for WCAG 2.1 or WCAG 2.2.

Common WCAG requirements in practice

An accessible website should, among other things:

• provide meaningful text alternatives for informative images;
• use a logical structure of headings, lists, tables, landmarks, and other HTML elements;
• allow menus, forms, dialogs, and other features to be operated with a keyboard;
• show a clearly visible focus indicator on links, buttons, and form controls;
• maintain a contrast ratio of at least 4.5:1 for standard text and 3:1 for large text at Level AA;
• avoid communicating meaning through color, position, or shape alone;
• provide clear form labels, instructions, and useful validation messages;
• support zoom and responsive reflow without losing content or functionality;
• include captions and other required alternatives for audio and video;
• avoid dangerous flashing, uncontrolled motion, and unnecessarily short time limits;
• announce important dynamic updates to assistive technologies;
• provide accessible navigation, authentication, and help mechanisms.

Visual accessibility alone does not establish conformance. A site may have excellent color contrast and still be inaccessible because of an illogical focus order, unlabeled controls, keyboard traps, incorrect semantics, or dynamic content that a screen reader cannot detect.

Who benefits from WCAG?

WCAG addresses barriers experienced by people who are blind or have low vision, people who are Deaf or hard of hearing, users with limited mobility, people with cognitive or learning disabilities, and individuals who are sensitive to motion or flashing content.

Accessible design also helps older adults and people dealing with temporary or situational limitations. Captions are useful when a device is muted, strong contrast improves readability in bright sunlight, and keyboard access can become essential for someone recovering from a hand injury.

Accessibility does not require sacrificing visual quality or modern interactions. It works best when it is integrated into UI/UX design, content strategy, and development from the beginning rather than added later as a separate mode for a limited group of users.

Is WCAG required by law?

WCAG is a technical standard, not a law by itself. However, laws, regulations, procurement rules, contracts, and organizational policies frequently use it as a direct or indirect benchmark for digital accessibility.

In the European Union, public-sector websites and mobile applications are subject to specific accessibility requirements. Since June 28, 2025, measures implementing the European Accessibility Act have also applied to certain private-sector products and services, including covered e-commerce services.

This does not mean that every private website has the same legal obligations. The exact requirements depend on the organization, service, jurisdiction, implementation date, and any applicable exemptions. WCAG conformance also does not automatically prove compliance with every accessibility law. WCAG provides the technical criteria, while the legal obligation comes from the relevant legislation.

For a detailed breakdown of the legal scope, see our guide WCAG and the European Accessibility Act: who must comply in the EU?, covering e-commerce, private businesses, public-sector organizations, and key exemptions.

How is WCAG conformance tested?

Automated accessibility tools and browser audits can identify many common issues, including some contrast failures, missing attributes, unlabeled form controls, and structural problems.

An automated scan cannot establish full WCAG conformance. Software cannot reliably determine whether every image description communicates the correct meaning, whether focus order is logical, whether an error message is understandable, or whether an entire customer journey works with assistive technology.

A thorough accessibility review should combine:

• automated testing;
• complete keyboard testing;
• screen reader testing;
• zoom, reflow, and responsive layout testing;
• an evaluation of semantic HTML and ARIA implementation;
• form and validation testing;
• a review of written content, documents, audio, and video;
• testing of complete user journeys and transactions.

An accessibility widget, contrast switcher, or third-party overlay does not automatically repair the underlying code and content. These tools may offer supplemental features, but they cannot replace accessible design, implementation, content practices, and testing.

What does a WCAG audit include?

A WCAG audit evaluates representative pages, components, and user journeys against the success criteria for a defined version and conformance level. A useful audit report should identify the issue, its location, the relevant success criterion, its impact on users, its priority, and a practical remediation recommendation.

Remediation should be followed by another round of testing. Fixing one shared component may remove a barrier across hundreds of pages, while another change may unintentionally create a new problem elsewhere. Accessibility therefore needs to be managed throughout design, development, content production, and ongoing website maintenance.

There is no permanent certificate that keeps a website accessible regardless of future changes. A new form, plugin, integration, template, or content update can introduce new barriers. An audit documents the state of a digital product at a specific point in time, while continued accessibility requires an ongoing process.

Why does WCAG matter?

Implementing WCAG helps organizations reach more users, reduce legal and operational risk, and improve the overall quality of their digital products. Clear structure, understandable forms, accurate semantics, accessible navigation, and predictable interactions often improve usability, code quality, maintainability, and trust for everyone.

In simple terms, WCAG turns the broad idea of digital accessibility into requirements that can be designed, implemented, and tested. It gives teams a shared way to identify barriers, prioritize fixes, and determine whether people using different devices and assistive technologies can complete the same tasks.

If you want to evaluate your current website or make it more accessible, learn more about our WCAG audit and implementation services.