Introducing The Web Content Accessibility Guidelines


Before giving a brief history of WCAG and describing its technical components at a very high, hopefully easy to follow level, I’m going to discuss what I believe is the most important thing people need to know about the Web Content Accessibility Guidelines–the reality that their development is inequitable and largely excludes people with disabilities. I’m beginning with the lack of equity involved in the WCAG development process, because I’m hoping folks will consider what our lack of involvement in the technical aspects really mean for our odds of using WCAG to create a web that’s truly accessible to us.

WCAG’s Lack of Equity

I covered this at the end of a previous live version of the podcast, but it needs to be restated here. The process of developing the WCAG is not at all equitable or inclusive of members of the disability community. The WCAG is developed by the Web Accessibility Initiative (WAI). Specifically, the development of WCAG is done by the Accessibility Guidelines Working Group. The current chairs of the Accessibility Guidelines Working Group are Charles Adams (Oracle), Rachael Bradley Montgomery (Library of Congress), and Alastair Campbell (Nomensa a British company). As far as I can tell, and I have looked reasonably hard, none of the three is a user of assistive technologies. All of them describe themself as working on accessibility, in the field of accessibility, and/or advocating for accessibility for periods of years. I can’t find one mention of any of them discussing their life as a person with a disability, describing how they use assistive technologies, or commenting about how they are personally impacted by inaccessibility.

I mentioned the employers of the chairs of the Accessibility Guidelines Working Group because the Working Group is an organization that for all intents and purposes only allows other organizations to join as full members. This means that an individual (regardless of their disability status, knowledge of assistive technologies, web codes, and related tools) cannot join without an invitation unless their employer pays to be an organizational member or they are able to pay thousands of dollars to join as an individual. The Membership FAQ has lots of information about joining the Accessibility Guidelines Working Group.

The fees for joining the Accessibility Guidelines Working Group highlight the elitist, restrictive, inequitable nature of the WCAG development process. The current cheapest fee for joining, in the United States available to very small nonprofits and government agencies, is $7,900 Annually. The largest annual fee for a United States business is currently more than $77,000 annually.

As the FAQ about the membership process and the fee structure for joining the Accessibility Guidelines Working Group indicate, the development of WCAG and the leadership of that development is a process that the vast majority of the disabled community cannot participate in at all. to make matters worse, the only people with a real shot at membership and the right to true participation are people who gain entrance in the organization with the permission of their employer. This structure creates an obvious conflict of interest forcing people to, at minimum, represent the wishes of their employer if they want to continue participating. So, the structure effectively guarantees very few people with disabilities will have an actual say in decision making and that the guidelines reflect the wishes of the business community–not the disability community.

To pretend it welcomes participation and to offer a largely false nod to equity and inclusion, the Accessibility Guidelines Working Group does offer different ways for members of the public to comment. But as you have heard me say repeatedly on this podcast, the most important concept of disability equity is nothing about us without us. By using a process that effectively prevents people with disabilities, unless they are representing their employer’s interest, from having a voting say in the development of WCAG, the Web Accessibility Initiative (WAI) has created a process that is all about those of us with disabilities while largely preventing those of us with disabilities from meaningful participation and denying us a real chance to lead efforts reporting to make web content more accessible to us.

Basics of the Web Content Accessibility Guidelines

The Web Content Accessibility Guidelines (WCAG) are developed by the Web Accessibility Initiative (WAI), a division of the World Wide Web Consortium (W3C). W3C is a web standards organization founded in 1994 which develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential. The W3c is directed by Sir Tim Berners-Lee, who invented the World Wide Web in 1989.

Version 1.0 of WCAG was officially released on May 5 1999. Version 2.0 of WCAG was released on December 11, 2008. Version 2.1 of WCAG was released on June 5, 2018. Version 2.1 of WCAG is the current official version of the standard. Version 2.2 was recommended as an official standard on January 25, 2023. It has not yet been officially adopted. That is supposed to happen at some point this year. The latest working draft of version 3.0 was released on December 7,2021.

Since version 2.1 is the official version and version 2.2 will be the official version later this year, the rest of this episode will focus on those versions. Version 3.0, at this point, seems at least a couple of years off. So, I will cover it in a future episode.


The Web Accessibility Initiative has an overview of WCAG two covering versions 2.0, 2.1, and 2.2.

Before diving in to specifics of WCAG two it’s important to define what the WAI means when it says web content. Web “content generally refers to the information in a web page or web application, including:

  • Natural information such as text, images, and sounds
  • Code or markup that defines structure, presentation, etc

Important things to know about all versions of WCAG two are as follows:

  • The standards don’t change after they are officially published.
  • WCAG 2.0 and WCAG 2.1 are backward compatible, meaning if content complies with 2.1 it complies with 2.0.
  • WCAG 2.1 does not supersede WCAG 2.0. Meaning organizations that have adopted version 2.0 as their standard do not need to adopt 2.1 to be compliant with WCAG.

Four Principles of WCAG

WCAG is based on four principles: perceivable; operable; understandable; and robust.

  1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
    This means that users must be able to perceive the information being presented (it can’t be invisible to all of their senses)
  2. Operable – User interface components and navigation must be operable.
    This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)
  3. Understandable – Information and the operation of user interface must be understandable.
    This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)
  4. Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible) If any of these are not true, users with disabilities will not be able to use the Web.

Guidelines and Success Criteria

Under versions 2.1 and 2.2 there are 13 guidelines. For each of the 13 guidelines there are testable success criteria. The success criteria are divided into three levels: A; AA; and AAA. Every organization that has adopted a policy promising to comply with WCAG that I have seen has adopted level AA. This is because level A results in improved but limited accessibility. Level AAA, in some instances, is not achievable. Level AAA is best used when its success criteria would add accessibility for certain disabilities and/or in certain situations. The success criteria are used to determine whether content complies with WCAG. WCAG 2.0 had 61 success criteria. WCAG 2.1 added 17 success criteria, bringing the total number of success criteria in WCAG 2.1 to 78. WCAG version 2.2 added an additional nine success criteria and eliminated one, bringing the total number of success criteria to 86 in version 2.2.

Under version 2.1 there are 30 success criteria at level A, 20 at level AA, and 28 at level AAA. Under version 2.2 there are 31 success criteria at level A, 23 at level AA, and 32 at level AAA.

To illustrate how the levels work, let’s consider this example. Under version 2.2, there are 31 success criteria at Level A and 23 at Level AA. For a site to comply with Level AA, as every policy I have seen reports to require, that site must conform with the 54 success criteria combined in Levels a and AA to be considered to meet Level AA compliance under WCAG 2.2. But because there is no requirement to comply with each new version of WCAG two, a site is considered to comply with WCAG as long as it satisfies the requirements of WCAG 2.0 Level AA. Meaning, an organization could have adopted a compliance policy based on WCAG 2.0 in 2008 and would not be required to comply with the requirements added over the last 15 years unless that organization expressly adopted version 2.2 as their new compliance standard. This is what they mean when they say the latest version of WCAG two does not supersede previous versions of WCAG two. My belief, which I hope is true, is that if people with disabilities were allowed meaningful participation in the development of the WCAG that entities would be required to comply with the latest version in within a reasonable time after release in order for them to be considered in compliance with WCAG.


My hope is that folks will learn the truth about WCAG and that our community will call out the World Wide Web Consortium for its lack of inclusion and inequitable processes. The only way WCAG will actually reflect the needs of the disabled community is when the disabled community, not corporations, are determining what constitutes accessible web content. That will never happen until we as disabled people call out the World Wide Web Consortium for their discriminatory practices and when we ask our advocacy organizations to demand a true seat at the leadership table and the right to make decisions about what constitutes accessible web content in the future development of the WCAG.

I would appreciate hearing from you. This is our website!