What are the Web Content Ac­ces­si­bil­i­ty Guide­lines (WCAG)?

The Web Content Ac­ces­si­bil­i­ty Guide­lines (WCAG) outline key criteria for creating ac­ces­si­ble websites. In par­tic­u­lar, people with dis­abil­i­ties often rely on such specially designed web content to perceive and un­der­stand in­for­ma­tion.

What are the WCAG?

The Web Content Ac­ces­si­bil­i­ty Guide­lines (WCAG) are in­ter­na­tion­al standards for making websites ac­ces­si­ble. They outline how web content should be designed and im­ple­ment­ed—both tech­ni­cal­ly and visually—to ensure it is usable by people with dis­abil­i­ties, re­gard­less of lim­i­ta­tions such as visual, auditory, or cognitive im­pair­ments.

WCAG is developed by the Web Ac­ces­si­bil­i­ty Ini­tia­tive (WAI) of the World Wide Web Con­sor­tium (W3C) and serves as the foun­da­tion for many legal ac­ces­si­bil­i­ty re­quire­ments around the world, including in European digital ac­ces­si­bil­i­ty leg­is­la­tion.

The most current version is WCAG 2.2, of­fi­cial­ly released on October 5, 2023. It builds upon WCAG 2.1 by in­tro­duc­ing nine new success criteria, specif­i­cal­ly aimed at improving ac­ces­si­bil­i­ty for users with cognitive im­pair­ments, limited fine motor skills, or low vision.

Purpose and sig­nif­i­cance of WCAG

WCAG defines technical and design re­quire­ments for web content to ensure that digital services are ac­ces­si­ble to as many people as possible—re­gard­less of in­di­vid­ual im­pair­ments or the tech­nolo­gies used (e.g., screen readers, Braille displays, keyboard nav­i­ga­tion).

Versions 2.1 (2018) and 2.2 (2023) build upon WCAG 2.0 (2008) by expanding ac­ces­si­bil­i­ty criteria to include support for mobile devices, touch in­ter­ac­tion, and cognitive as­sis­tance. All three versions are backward-com­pat­i­ble, 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­for­mance model and more com­pre­hen­sive eval­u­a­tion 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­ces­si­bil­i­ty in web projects. The WCAG seek to meet the needs of in­di­vid­u­als as well as those of or­ga­ni­za­tions and gov­ern­ment in­sti­tu­tions.

Compared to the previous standard and versions, WCAG 2.1 features a tech­nol­o­gy-in­de­pen­dent approach. This means that the guide­lines are for­mu­lat­ed in such a way that current tech­no­log­i­cal standards as well as future de­vel­op­ments are accounted for.

One sig­nif­i­cant 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­ces­si­bil­i­ty Guide­lines Version 1.0 is separated into 14 prin­ci­ples, each con­tain­ing 1 to 10 check­points of pri­or­i­ties 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­ces­si­bil­i­ty Guide­lines Version 2.x provides a system that is sub­di­vid­ed into the 4 basic design prin­ci­ples of per­cep­ti­bil­i­ty, usability, in­tel­li­gi­bil­i­ty, and ro­bust­ness. For each guideline, WCAG 2.x provides a set of ver­i­fi­able success criteria for the A, AA, and AAA con­for­mance 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­men­ta­tion have been placed on the in­for­ma­tion pages “Un­der­stand­ing WCAG 2.0” and “Tech­niques for WCAG 2.0”. The pages also include links to the cor­re­spond­ing success criteria.

Despite the dif­fer­ences in the or­ga­ni­za­tion of re­quire­ments and design criteria, WCAG 2.x remains backward com­pat­i­ble. 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­for­mance

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

When de­ter­min­ing the level of con­for­mance, web pages (or a single HTML document available under its own URL) are evaluated in­di­vid­u­al­ly.

• If a section of a web page doesn’t fulfill the re­quire­ments outlined in a specific con­for­mance 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­for­mance level or a higher con­for­mance 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­for­mance level.

Example of con­for­mance

In contrast to WCAG 1.0, WCAG 2.0 offers the pos­si­bil­i­ty to implement in­di­vid­ual aspects of ac­ces­si­ble web design on different con­for­mance levels. For the color contrast aspect, for example, the current standard defines two success criteria and different con­for­mance levels:

1.4.3 Contrast (Minimum): The visual pre­sen­ta­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 pre­sen­ta­tion of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA) […]

Optional con­for­mance claim

Website operators have the option to issue a con­for­mance statement for all web pages that meet the WCAG success criteria. This statement is voluntary and does not affect the actual ac­ces­si­bil­i­ty of the website. If a website operator chooses to provide a con­for­mance statement, the W3C specifies that it must include the following mandatory elements:

• Date of the con­for­mance claim
• In­di­ca­tion of which WCAG being referred to, including title, version, and link to the standard
• In­di­ca­tion of which con­for­mance 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­nolo­gies used on the WCAG-con­for­mant web pages that affect their level of con­for­mance.

In addition, website operators can choose to include the following in­for­ma­tion in the con­for­mance claim:

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

Overview of the WCAG 2.1 guide­lines

The Web Content Ac­ces­si­bil­i­ty Guide­lines consist of 13 guide­lines organized under four foun­da­tion­al prin­ci­ples. While the WCAG prin­ci­ples define the core re­quire­ments for ac­ces­si­ble web usage, the guide­lines provide specific in­struc­tions that should be followed when aiming for a par­tic­u­lar level of con­for­mance. You can find the official WCAG 2.0 text on the website of the World Wide Web Con­sor­tium (W3C). Below, we offer a brief summary of WCAG 2.1, which also in­cor­po­rates the updated guide­lines 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 guide­lines outline how to improve per­cep­ti­bil­i­ty for web content:

• Text al­ter­na­tives: An alternate text-based pre­sen­ta­tion makes it possible to transfer non-text content into other forms, such as large print, Braille, symbols or plain language. These measures cor­re­spond to con­for­mance level A. Alt at­trib­ut­es of images can also improve SEO rankings.
• Mul­ti­me­dia content: The website provides alternate pre­sen­ta­tion forms for time-based media (i.e., audio and video content). Depending on the con­for­mance level you want to achieve, you can make different types of al­ter­na­tive media formats available, including de­scrip­tive texts, audio de­scrip­tions (such as speech synthesis), subtitles, tran­scripts and sign language. This guideline covers 9 success criteria across con­for­mance levels A, AA and AAA.
• Adapt­abil­i­ty: The content of the website can be converted into al­ter­na­tive display forms without losing in­for­ma­tion (simple layout). The guideline outlines 6 success criteria across con­for­mance levels A, AA and AAA.
• Dis­tinc­tive­ness: Content is created in such a way that it’s visually and acousti­cal­ly distinct from other content (color, font size, contrast, discreet back­ground). This guideline has 13 success criteria across con­for­mance levels A, AA and AAA.

Operable

For web content to be ac­ces­si­ble, the user interface must be designed in a way that enables all users to reach the in­for­ma­tion they need. The usability of web offerings can be improved by following these guide­lines:

• Ac­ces­si­ble via keyboard: For the best possible web usability, all contents and func­tion­al­i­ties should be ac­ces­si­ble with a keyboard. In this case, the keyboard is used as the primary user interface. This guideline has four success criteria in con­for­mance 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­for­ma­tion. This guideline covers 6 success criteria under con­for­mance levels A and AAA.

• Minimize risks for seizures: All web content is designed to minimize 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­for­mance levels A and AAA.

• Nav­i­ga­tion: The website provides users with means for easy nav­i­ga­tion. The spec­i­fi­ca­tions for ac­ces­si­ble nav­i­ga­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 guide­lines for nav­i­ga­tion cover 13 success criteria in con­for­mance levels A and AA.

• Ac­ces­si­ble via other devices: All features and functions that are available via keyboard should also be ac­ces­si­ble through al­ter­na­tive means, such as gestures. The guideline provides eight success criteria across con­for­mance levels A, AA and AAA.

Un­der­stand­able

Web content should be designed in such a way that the in­for­ma­tion, as well as how to interact with it, is un­der­stand­able. Web de­vel­op­ers and authors can achieve optimal in­tel­li­gi­bil­i­ty using the following guide­lines.

• Read­abil­i­ty: Optimal ac­ces­si­bil­i­ty requires readable and un­der­stand­able content. The guideline for read­abil­i­ty covers rules spec­i­fy­ing how lin­guis­tic elements should be char­ac­ter­ized and enriched with ad­di­tion­al in­for­ma­tion in order to ensure optimal content ac­ces­si­bil­i­ty. The WCAG has 6 criteria for read­abil­i­ty across con­for­mance levels A, AA and AAA.

• Pre­dictabil­i­ty: The behavior of func­tion­al and in­ter­ac­tive web page elements should always remain pre­dictable in order make it easier to un­der­stand. The 6 proposed success criteria are under con­for­mance levels A, AA, and AAA.

• Input as­sis­tance: Easily ac­ces­si­ble websites help visitors to avoid errors by au­to­mat­i­cal­ly cor­rect­ing them using input as­sis­tance. The guideline for ac­ces­si­bil­i­ty tools covers spec­i­fi­ca­tions for automatic error detection, help texts and labeling of input fields, as well as input mech­a­nisms for legally relevant data or financial trans­ac­tions. There are nine success criteria across con­for­mance levels A, AA and AAA.

Robust

The WCAG principle of ro­bust­ness refers to the com­pat­i­bil­i­ty of web content. To ensure easy ac­ces­si­bil­i­ty, 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­re­spond­ing spec­i­fi­ca­tions in the com­pat­i­bil­i­ty guide­lines:

• Com­pat­i­bil­i­ty: Ensuring com­pat­i­bil­i­ty with current and future tech­nol­o­gy means con­sis­tent­ly applying for­mal­ized web standards. A fun­da­men­tal 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­cor­dance with the com­pat­i­bil­i­ty guideline. This guideline contains two success criteria and includes con­for­mance 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 guide­lines:

• 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­abil­i­ties:

  • Assistive features should always be located in the same place
  • As­sis­tance for redundant data entry
  • Al­ter­na­tive ways to enter passwords and ac­ces­si­ble cognitive function tests
  • Al­ter­na­tives to picture and object selection for au­then­ti­ca­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 guide­lines.

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­ve­nient overview of the guide­lines. Since the pub­li­ca­tion of the official W3C Rec­om­men­da­tion on December 11, 2008, this checklist, however, is no longer current.

The original checklist has been replaced by an in­di­vid­u­al­ly mod­i­fi­able WCAG quick reference guide. This allows website operators to tailor the criteria catalog for ac­ces­si­ble 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 spec­i­fi­ca­tions of the WCAG outline testable success criteria, which website operators can use to assess the degree to which in­di­vid­ual web pages conform to the standards created by the WAI. For website operators that would like to check not only in­di­vid­ual pages but also the ac­ces­si­bil­i­ty of their entire web presence, the WAI has developed 4 strate­gies:

Easy Checks

With Easy Checks, the WAI covers basic aspects of ac­ces­si­ble 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 scal­a­bil­i­ty
• Ac­ces­si­bil­i­ty via keyboard
• Content that moves, flashes or au­to­mat­i­cal­ly starts
• Mul­ti­me­dia al­ter­na­tives
• Website structure

Compared to other eval­u­a­tions, an Easy Check is sig­nif­i­cant­ly less thorough. Further eval­u­a­tions (for example, the WCAG EM) are necessary to better determine the actual level of con­for­mance.

WCAG-EM

Easy Checks serve to provide website operators with a first im­pres­sion of the overall ac­ces­si­bil­i­ty of their online project. For website operators who want to reliably and ver­i­fi­ably determine the WCAG com­pli­ance of their web project, the WAI developed a best practice approach with the Website Ac­ces­si­bil­i­ty Con­for­mance Eval­u­a­tion Method­ol­o­gy. The WCAG-EM includes five steps:

1. Define the eval­u­a­tion scope
2. Analyze the website
3. Select rep­re­sen­ta­tive web pages
4. Evaluate the selected pages
5. Create a con­for­mance eval­u­a­tion report using the WCAG-EM Report Tool

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

User-based eval­u­a­tions

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

A user-based ac­ces­si­bil­i­ty test typically seeks to examine how older in­di­vid­u­als and people with dis­abil­i­ties are able to interact with a website. Informal testing methods in the form of surveys as well as for­mal­ized usability tests, which are based on the sta­tis­ti­cal eval­u­a­tion of certain tasks, can be used.

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

Eval­u­a­tion tools

Website operators can find various tools online for the eval­u­a­tion of the ac­ces­si­bil­i­ty 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 rec­om­men­da­tion for a par­tic­u­lar eval­u­a­tion tool can be found on the W3C website. Instead of rec­om­mend­ing a single tool, WAI offers an extensive list of available eval­u­a­tion tools that can be con­ve­nient­ly limited to fit in­di­vid­ual re­quire­ments and a specific standard thanks to a filter function.

WCAG in the U.S.

In the United States, most legal pro­tec­tions for in­di­vid­u­als with dis­abil­i­ties are outlined in the Americans with Dis­abil­i­ties Act (ADA). Ad­di­tion­al re­quire­ments apply under Section 508 of the Re­ha­bil­i­ta­tion Act, which mandates that federal agencies ensure their digital content is ac­ces­si­ble.

Under these laws, both gov­ern­ment websites and public-facing business websites are required to be ac­ces­si­ble. While neither law ex­plic­it­ly mandates con­for­mance with the WCAG, the U.S. De­part­ment of Justice and federal courts commonly refer to WCAG 2.1 Level AA as the standard for web ac­ces­si­bil­i­ty com­pli­ance.

An overview of testing methods and tools for website ac­ces­si­bil­i­ty and general in­for­ma­tion about ac­ces­si­ble design can be found on the official Section 508 website.

Outlook: WCAG 3.0

WCAG 2 (and the updates in WCAG 2.2.) is the standard currently rec­om­mend­ed by W3C. But WAI is already working on a new version of the Web Content Ac­ces­si­bil­i­ty Guide­lines, WCAG 3.0. In the new version, a special focus will be placed on ad­di­tion­al tests and different eval­u­a­tion mech­a­nisms. Unlike previous versions, WCAG 3.0 will not be backward com­pat­i­ble, but will instead be a new set of guide­lines. The con­for­mance model will also be revised. To find out more about the new version of the guide­lines, you can have a look at the working draft of WCAG 3.0 on W3C’s website.