What is WCAG 2?

By Ikius Team

April 24th, 2026

Accessibility is (or at least should be) a fundamental part of building modern web applications. The web is used by people with a wide range of abilities, devices, and assistive technologies, which means digital experiences should be designed and implemented in ways that allow everyone to interact with content effectively. Accessibility also improves usability for people with temporary impairments, situational limitations, or different interaction preferences. When accessibility is treated as a foundational part of development rather than a late-stage adjustment, websites and applications become more resilient, usable, and inclusive.

What is WCAG?

Development teams need clear standards that help ensure digital experiences remain usable for everyone. One of the most important frameworks guiding this work is Web Content Accessibility Guidelines (WCAG) 2 which is a technical specification that defines how web content can be made more accessible to people with different kinds of disabilities. Different versions of WCAG 2 have been published: 2.0, 2.1 and 2.2. They all are existing standards, but 2.2 is the recommened one to follow. In this article I’ll be talking about the guidelines generally in and will keep mentioning just “WCAG 2”. The presumption should be that it means the 2.2 version though there isn't anything too specific about any of the versions in this article.

WCAG 2 was developed by the World Wide Web Consortium through the Web Accessibility Initiative as part of an effort to standardize accessibility practices across the web. Before its introduction accessibility recommendations were often fragmented or difficult to evaluate in practice. WCAG 2 addressed this problem by introducing testable success criteria and an approach which isn't tied to specific technologies that works across different platforms, programming languages, and web frameworks.

Core Principles

The specification is built around four core principles that describe the characteristics accessible content should have. These principles state that content must be perceivable, operable, understandable, and robust. Perceivability means the idea that information and user interface components must be presented in ways that users can detect. This includes providing text alternatives for non-text content like images, ensuring sufficient color contrast between items, and making videos and other media accessible through captions or transcripts.

Operability focuses on interaction and navigation. Users must be able to operate the interface using different input methods such as a mouse or keyboard-only navigation. This requirement is particularly important for users who rely on assistive technologies or who cannot use a traditional mouse. Interactive elements such as menus and forms should therefore be designed so that focus order, keyboard controls and interactive states are predictable and accessible.

Understandability addresses the clarity and consistency of both content and interface behavior. Interfaces should be structured in ways that help users anticipate how components behave. Things shouldn’t come as a surprise to users and actions they do should have the outcomes that they could usually expect them to have. Examples of things that support this principle would be meaningful form labels and clear feedback from actions, be it errors with the website or errors with the user’s input on forms for example.

Robustness in this case means that the site should be compatible with a wide variety of different user agents and assistive technologies. Web content should be implemented with proper markup so that tools such as screen readers can reliably interpret the structure and meaning of the page.

Conformance levels

WCAG 2 defines three levels of conformance: A, AA, AAA. Each level has its own success criteria with level A having the lowest level of requirements, that the next levels expand upon.

Level A addresses the most fundamental accessibility needs. Level AA is generally seen as the appropriate target for most websites and applications in production, striking a balance between usability and the feasibility of implementing it. A site is often required to meet at least level AA to comply with some laws and regulations, at least for governmental and public administration websites. Level AAA offers the most comprehensive accessibility support, though it can be challenging, if not sometimes impossible, to meet consistently across all types of content and interfaces.

For Development Teams

From a development standpoint, WCAG 2 promotes addressing accessibility from the outset of design and implementation, rather than leaving it down the line or as a post-release check. Choices such as component structure, semantic HTML, focus handling, and color design all affect how well a project meets accessibility standards and they are easier to address from the start rather than once everything else is already built. Accessibility testing should be a part of the development process and different technologies, like screen readers, should be a part of regular testing at the very least for the most important parts of the project.

For development teams, WCAG 2 offers a clear framework for assessing accessibility and informing implementation decisions. By aligning frontend architecture, design and testing approaches with the guidelines, teams can build applications that serve a wider range of users and different assistive technologies. Following the guidelines also support long-term maintainability and make it easier to comply with possible future requirements.