What are the Web Content Ac­cess­ib­il­ity Guidelines (WCAG)?

The Web Content Ac­cess­ib­il­ity Guidelines (WCAG) outline key criteria for creating ac­cess­ible websites. In par­tic­u­lar, people with dis­ab­il­it­ies often rely on such specially designed web content to perceive and un­der­stand in­form­a­tion.

What are the WCAG?

The Web Content Ac­cess­ib­il­ity Guidelines (WCAG) are in­ter­na­tion­al standards for making websites ac­cess­ible. They outline how web content should be designed and im­ple­men­ted—both tech­nic­ally and visually—to ensure it is usable by people with dis­ab­il­it­ies, re­gard­less of lim­it­a­tions such as visual, auditory, or cognitive impair­ments.

WCAG is developed by the Web Ac­cess­ib­il­ity Ini­ti­at­ive (WAI) of the World Wide Web Con­sor­ti­um (W3C) and serves as the found­a­tion for many legal ac­cess­ib­il­ity re­quire­ments around the world, including in European digital ac­cess­ib­il­ity le­gis­la­tion.

The most current version is WCAG 2.2, of­fi­cially released on October 5, 2023. It builds upon WCAG 2.1 by in­tro­du­cing nine new success criteria, spe­cific­ally aimed at improving ac­cess­ib­il­ity for users with cognitive impair­ments, limited fine motor skills, or low vision.

Purpose and sig­ni­fic­ance of WCAG

WCAG defines technical and design re­quire­ments for web content to ensure that digital services are ac­cess­ible to as many people as possible—re­gard­less of in­di­vidu­al impair­ments or the tech­no­lo­gies used (e.g., screen readers, Braille displays, keyboard nav­ig­a­tion).

Versions 2.1 (2018) and 2.2 (2023) build upon WCAG 2.0 (2008) by expanding ac­cess­ib­il­ity criteria to include support for mobile devices, touch in­ter­ac­tion, and cognitive as­sist­ance. All three versions are backward-com­pat­ible, meaning that websites con­form­ing to WCAG 2.2 also meet the re­quire­ments of the earlier versions.

The next major version—WCAG 3.0—is currently under de­vel­op­ment. It is not expected to become an official standard before 2027 and aims to introduce a new con­form­ance model and more com­pre­hens­ive eval­u­ation methods.

What are the dif­fer­ences between WCAG 1.0 and WCAG 2.1?

The goal of W3C is to provide website operators with an in­ter­na­tion­al standard for ac­cess­ib­il­ity in web projects. The WCAG seek to meet the needs of in­di­vidu­als as well as those of or­gan­isa­tions and gov­ern­ment in­sti­tu­tions.

Compared to the previous standard and versions, WCAG 2.1 features a tech­no­logy-in­de­pend­ent approach. This means that the guidelines are for­mu­lated in such a way that current tech­no­lo­gic­al standards as well as future de­vel­op­ments are accounted for.

One sig­ni­fic­ant dif­fer­ence between WCAG 1.0 and WCAG 2.x is the structure of the criteria list:

• Structure of WCAG 1.0: The Web Content Ac­cess­ib­il­ity Guidelines Version 1.0 is separated into 14 prin­ciples, each con­tain­ing 1 to 10 check­points of pri­or­it­ies 1, 2 and 3. Each check­point is assigned an example, which refers to the basic web standards HTML and XML.
• Structure of WCAG 2.x: The Web Content Ac­cess­ib­il­ity Guidelines Version 2.x provides a system that is sub­divided into the 4 basic design prin­ciples of per­cept­ib­il­ity, usability, in­tel­li­gib­il­ity, and ro­bust­ness. For each guideline, WCAG 2.x provides a set of veri­fi­able success criteria for the A, AA, and AAA con­form­ance levels (see below).

Website operators may not be able to find examples for the current standard but detailed de­scrip­tions and advice for technical im­ple­ment­a­tion have been placed on the in­form­a­tion pages ‘Un­der­stand­ing WCAG 2.0’ and ‘Tech­niques for WCAG 2.0’. The pages also include links to the cor­res­pond­ing success criteria.

Despite the dif­fer­ences in the or­gan­isa­tion of re­quire­ments and design criteria, WCAG 2.x remains backward com­pat­ible. With it, a website can fulfill the re­quire­ments of both standards. The con­ver­sion of a website from WCAG 1.0 to WCAG 2.1 only requires small ad­just­ments. In the following sections, the criteria in the most recent version, WCAG Version 2.1, is used.

Con­form­ance

If a website fulfills the re­quire­ments of the WCAG, this is referred to as con­form­ance. But it’s important to note that a WCAG-compliant website doesn’t have to consider every single success criterion listed in the guidelines. Instead, the W3C dif­fer­en­ti­ates between three levels of con­form­ance: A, AA and AAA. These provide in­form­a­tion about how well a website is adapted to the needs of all internet users.

When de­term­in­ing the level of con­form­ance, web pages (or a single HTML document available under its own URL) are evaluated in­di­vidu­ally.

• If a section of a web page doesn’t fulfill the re­quire­ments outlined in a specific con­form­ance level, the web page as a whole will not be awarded the level.
• If the web page is part of a click path that allows a specific action to be performed, all web pages of the click path must fulfill the criteria of the same con­form­ance level or a higher con­form­ance level. If one web page in the click path doesn’t fulfill the re­quire­ments of a certain level, all of the pages in the click path will not receive the con­form­ance level.

Example of con­form­ance

In contrast to WCAG 1.0, WCAG 2.0 offers the pos­sib­il­ity to implement in­di­vidu­al aspects of ac­cess­ible web design on different con­form­ance levels. For the colour contrast aspect, for example, the current standard defines two success criteria and different con­form­ance levels:

1.4.3 Contrast (Minimum): The visual present­a­tion of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA) […]

1.4.6 Contrast (Enhanced): The visual present­a­tion of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA) […]

Optional con­form­ance claim

Website operators have the option to issue a con­form­ance statement for all web pages that meet the WCAG success criteria. This statement is voluntary and does not affect the actual ac­cess­ib­il­ity of the website. If a website operator chooses to provide a con­form­ance statement, the W3C specifies that it must include the following mandatory elements:

• Date of the con­form­ance claim
• In­dic­a­tion of which WCAG being referred to, including title, version, and link to the standard
• In­dic­a­tion of which con­form­ance level has been fulfilled (Level A, AA, or AAA)
• Precise de­scrip­tion of which web pages the domain in the claim refers to (e.g., a list of all URLS)
• A list of all essential web tech­no­lo­gies used on the WCAG-con­form­ant web pages that affect their level of con­form­ance.

In addition, website operators can choose to include the following in­form­a­tion in the con­form­ance claim:

• List of all success criteria that was fulfilled beyond the stated degree of con­form­ance
• List of all web tech­no­lo­gies used by the website that don’t affect the website’s con­form­ance
• List of all user agents that the website was tested with
• Machine-readable version of the list of all essential web tech­no­lo­gies used by the WCAG-compliant web pages
• Machine-readable version of con­form­ance claim
• A list of ad­di­tion­al ac­cess­ib­il­ity measures that are not covered by the WCAG; a template for the con­form­ance statement is provided by the European Union.

Overview of the WCAG 2.1 guidelines

The Web Content Ac­cess­ib­il­ity Guidelines consist of 13 guidelines organised under four found­a­tion­al prin­ciples. While the WCAG prin­ciples define the core re­quire­ments for ac­cess­ible web usage, the guidelines provide specific in­struc­tions that should be followed when aiming for a par­tic­u­lar level of con­form­ance. You can find the official WCAG 2.0 text on the website of the World Wide Web Con­sor­ti­um (W3C). Below, we offer a brief summary of WCAG 2.1, which also in­cor­por­ates the updated guidelines in­tro­duced in WCAG 2.2.

Per­ceiv­able

For optimal web usability, you should present your content in a way that makes it possible for all internet users to perceive it. The following WCAG guidelines outline how to improve per­cept­ib­il­ity for web content:

• Text al­tern­at­ives: An alternate text-based present­a­tion makes it possible to transfer non-text content into other forms, such as large print, Braille, symbols or plain language. These measures cor­res­pond to con­form­ance level A. Alt at­trib­utes of images can also improve SEO rankings.
• Mul­ti­me­dia content: The website provides alternate present­a­tion forms for time-based media (i.e., audio and video content). Depending on the con­form­ance level you want to achieve, you can make different types of al­tern­at­ive media formats available, including de­script­ive texts, audio de­scrip­tions (such as speech synthesis), subtitles, tran­scripts and sign language. This guideline covers 9 success criteria across con­form­ance levels A, AA and AAA.
• Ad­apt­ab­il­ity: The content of the website can be converted into al­tern­at­ive display forms without losing in­form­a­tion (simple layout). The guideline outlines 6 success criteria across con­form­ance levels A, AA and AAA.
• Dis­tinct­ive­ness: Content is created in such a way that it’s visually and acous­tic­ally distinct from other content (colour, font size, contrast, discreet back­ground). This guideline has 13 success criteria across con­form­ance levels A, AA and AAA.

Operable

For web content to be ac­cess­ible, the user interface must be designed in a way that enables all users to reach the in­form­a­tion they need. The usability of web offerings can be improved by following these guidelines:

• Ac­cess­ible via keyboard: For the best possible web usability, all contents and func­tion­al­it­ies should be ac­cess­ible with a keyboard. In this case, the keyboard is used as the primary user interface. This guideline has four success criteria in con­form­ance levels A and AAA.

• No time pressure: Users are given suf­fi­cient time to read and use web content. This guideline can be useful for people who need more time to interact with website content or to carry out certain actions, such as entering in­form­a­tion. This guideline covers 6 success criteria under con­form­ance levels A and AAA.

• Minimise risks for seizures: All web content is designed to minimise any possible risk of seizures. This guideline defines threshold values for visual stimuli that could possibly lead to seizures. In this guideline, three success criteria are specified under con­form­ance levels A and AAA.

• Nav­ig­a­tion: The website provides users with means for easy nav­ig­a­tion. The spe­cific­a­tions for ac­cess­ible nav­ig­a­tion refer to meta-titles, meta de­scrip­tions, anchor texts, ways to access different web pages, headings and captions for text sections, and keyboard focus. The guidelines for nav­ig­a­tion cover 13 success criteria in con­form­ance levels A and AA.

• Ac­cess­ible via other devices: All features and functions that are available via keyboard should also be ac­cess­ible through al­tern­at­ive means, such as gestures. The guideline provides eight success criteria across con­form­ance levels A, AA and AAA.

Un­der­stand­able

Web content should be designed in such a way that the in­form­a­tion, as well as how to interact with it, is un­der­stand­able. Web de­velopers and authors can achieve optimal in­tel­li­gib­il­ity using the following guidelines.

• Read­ab­il­ity: Optimal ac­cess­ib­il­ity requires readable and un­der­stand­able content. The guideline for read­ab­il­ity covers rules spe­cify­ing how lin­guist­ic elements should be char­ac­ter­ised and enriched with ad­di­tion­al in­form­a­tion in order to ensure optimal content ac­cess­ib­il­ity. The WCAG has 6 criteria for read­ab­il­ity across con­form­ance levels A, AA and AAA.

• Pre­dict­ab­il­ity: The behaviour of func­tion­al and in­ter­act­ive web page elements should always remain pre­dict­able in order make it easier to un­der­stand. The 6 proposed success criteria are under con­form­ance levels A, AA, and AAA.

• Input as­sist­ance: Easily ac­cess­ible websites help visitors to avoid errors by auto­mat­ic­ally cor­rect­ing them using input as­sist­ance. The guideline for ac­cess­ib­il­ity tools covers spe­cific­a­tions for automatic error detection, help texts and labeling of input fields, as well as input mech­an­isms for legally relevant data or financial trans­ac­tions. There are nine success criteria across con­form­ance levels A, AA and AAA.

Robust

The WCAG principle of ro­bust­ness refers to the com­pat­ib­il­ity of web content. To ensure easy ac­cess­ib­il­ity, content should be designed in such a way that it can be processed reliably by the majority of user agents (web browsers, assisting output devices, etc.). Website operators can find cor­res­pond­ing spe­cific­a­tions in the com­pat­ib­il­ity guidelines:

• Com­pat­ib­il­ity: Ensuring com­pat­ib­il­ity with current and future tech­no­logy means con­sist­ently applying form­al­ised web standards. A fun­da­ment­al part of this is correctly im­ple­ment­ing content using markup languages like HTML, making sure that the markup language is written without any errors and in ac­cord­ance with the com­pat­ib­il­ity guideline. This guideline contains two success criteria and includes con­form­ance levels A and AA.

Updates to the WCAG in WCAG 2.2

With WCAG 2.2, 9 new success criteria were added to the current version of the guidelines:

• Keyboard use: 3 criteria for dis­play­ing content when a keyboard navigates to focusable elements

• Input with touch­screen and mouse: 1 criterion for swipe gestures and 1 criterion for clickable areas.

• More support for people with cognitive dis­ab­il­it­ies:

  • Assistive features should always be located in the same place
  • As­sist­ance for redundant data entry
  • Al­tern­at­ive ways to enter passwords and ac­cess­ible cognitive function tests
  • Al­tern­at­ives to picture and object selection for au­then­tic­a­tion tests

WCAG 2.2 functions as a sup­ple­ment to WCAG 2.1, serving to close gaps in the current version of the guidelines.

WCAG checklist

The W3C Working Draft (the working version of WCAG 2.0), published on April 27, 2006, contained a checklist in the appendix that listed all of the success criteria defined by the W3C. For many website operators, it has served as a con­veni­ent overview of the guidelines. Since the pub­lic­a­tion of the official W3C Re­com­mend­a­tion on December 11, 2008, this checklist, however, is no longer current.

The original checklist has been replaced by an in­di­vidu­ally modi­fi­able WCAG quick reference guide. This allows website operators to tailor the criteria catalog for ac­cess­ible web design to their own needs (namely, their technical re­quire­ments and desired com­pli­ance level). A filter function allows for the creation of custom check­lists.

WCAG tests

The spe­cific­a­tions of the WCAG outline testable success criteria, which website operators can use to assess the degree to which in­di­vidu­al web pages conform to the standards created by the WAI. For website operators that would like to check not only in­di­vidu­al pages but also the ac­cess­ib­il­ity of their entire web presence, the WAI has developed 4 strategies:

Easy Checks

With Easy Checks, the WAI covers basic aspects of ac­cess­ible web design. The list is intended to allow website operators to get a quick overview of the status of their online project. The following criteria can be examined with Easy Checks:

• Meta-titles
• Alt texts
• Headlines
• Contrast ratio
• Text scalab­il­ity
• Ac­cess­ib­il­ity via keyboard
• Content that moves, flashes or auto­mat­ic­ally starts
• Mul­ti­me­dia al­tern­at­ives
• Website structure

Compared to other eval­u­ations, an Easy Check is sig­ni­fic­antly less thorough. Further eval­u­ations (for example, the WCAG EM) are necessary to better determine the actual level of con­form­ance.

WCAG-EM

Easy Checks serve to provide website operators with a first im­pres­sion of the overall ac­cess­ib­il­ity of their online project. For website operators who want to reliably and veri­fi­ably determine the WCAG com­pli­ance of their web project, the WAI developed a best practice approach with the Website Ac­cess­ib­il­ity Con­form­ance Eval­u­ation Meth­od­o­logy. The WCAG-EM includes five steps:

1. Define the eval­u­ation scope
2. Analyse the website
3. Select rep­res­ent­at­ive web pages
4. Evaluate the selected pages
5. Create a con­form­ance eval­u­ation report using the WCAG-EM Report Tool

Pub­lish­ing the con­form­ance report is not required. The results of the eval­u­ation serve as the basis for an (optional) con­form­ance statement (see above).

User-based eval­u­ations

Website operators who want to evaluate the ac­cess­ib­il­ity of their online presence generally con­cen­trate on standard testing methods like WCAG-EM. But the WAI re­com­mends combining the com­pli­ance eval­u­ation with a user-based eval­u­ation, if possible. This way, operators can identify usability problems that aren’t included in the WCAG 2.1 criteria catalog.

A user-based ac­cess­ib­il­ity test typically seeks to examine how older in­di­vidu­als and people with dis­ab­il­it­ies are able to interact with a website. Informal testing methods in the form of surveys as well as form­al­ised usability tests, which are based on the stat­ist­ic­al eval­u­ation of certain tasks, can be used.

Advice on how website operators can involve their page visitors in such eval­u­ation methods is available on this in­form­a­tion page from WAI.

Eval­u­ation tools

Website operators can find various tools online for the eval­u­ation of the ac­cess­ib­il­ity of their web presence. WAI also en­cour­ages the de­vel­op­ment of ap­pro­pri­ate programs and web services, though a re­com­mend­a­tion for a par­tic­u­lar eval­u­ation tool can be found on the W3C website. Instead of re­com­mend­ing a single tool, WAI offers an extensive list of available eval­u­ation tools that can be con­veni­ently limited to fit in­di­vidu­al re­quire­ments and a specific standard thanks to a filter function.

WCAG in the UK

In the UK, digital ac­cess­ib­il­ity is primarily governed by the Equality Act 2010, which replaced previous le­gis­la­tion such as the Dis­ab­il­ity Dis­crim­in­a­tion Act 1995. The Equality Act legally protects in­di­vidu­als from dis­crim­in­a­tion, including on the basis of dis­ab­il­ity, and applies to both public and private sector or­gan­isa­tions.

For public sector or­gan­isa­tions, ad­di­tion­al and specific rules apply under the Public Sector Bodies (Websites and Mobile Ap­plic­a­tions) (No. 2) Ac­cess­ib­il­ity Reg­u­la­tions 2018. These reg­u­la­tions came into force in September 2018 and require that:

• All public sector websites and mobile apps meet WCAG 2.1 Level AA standards.
• An ac­cess­ib­il­ity statement must be published and kept up to date.
• Public sector or­gan­isa­tions must monitor ac­cess­ib­il­ity and respond to ac­cess­ib­il­ity feedback.

Certain or­gan­isa­tions are exempt, such as:

• Public sector broad­casters (e.g. the BBC)
• Schools and nurseries (in part)
• Some archive and heritage services

An or­gan­isa­tion may also claim an exemption if making the required changes would impose a ‘dis­pro­por­tion­ate burden’, though this must be well-doc­u­mented and justified.

Private sector con­sid­er­a­tions

Although private sector websites are not ex­pli­citly required by law to meet WCAG 2.1 in the UK, under the Equality Act 2010, busi­nesses have a legal duty to make ‘reas­on­able ad­just­ments’ to ensure their services are ac­cess­ible to disabled users. Meeting WCAG standards is widely regarded as a practical way to fulfill this ob­lig­a­tion.

Outlook: WCAG 3.0

WCAG 2 (and the updates in WCAG 2.2.) is the standard currently re­com­men­ded by W3C. But WAI is already working on a new version of the Web Content Ac­cess­ib­il­ity Guidelines, WCAG 3.0. In the new version, a special focus will be placed on ad­di­tion­al tests and different eval­u­ation mech­an­isms. Unlike previous versions, WCAG 3.0 will not be backward com­pat­ible, but will instead be a new set of guidelines. The con­form­ance model will also be revised. To find out more about the new version of the guidelines, you can have a look at the working draft of WCAG 3.0 on W3C’s website.