Far more than a simple checklist, the Web Content Accessibility Guidelines are the core of a sweeping collection of resources to educate and support technology providers in their accessibility workflow. This page outlines some ways you can work with WCAG in your workspace or domain.

Applications for WCAG

Measuring website accessibility

WCAG was initially developed to measure the accessibility of websites. WCAG 1.0 consisted of 14 guidelines and referred exclusively to websites and web technologies throughout the original documentation. While WCAG 2.x now is technology agnostic, the guidelines, success criteria, and techniques still are the unequaled standard for testing web accessibility. 

Most accessibility testing tools test against WCAG success criteria. Learn more about accessibility testing

Measuring non-web accessibility

Despite its name, WCAG principles are not exclusive to web content. Universal features like color contrast, labels and instructions, multiple modes of perception and interaction, and adjustable timing apply to virtually any technology. WCAG2ICT, a note from the W3C, provides informative guidance on applying WCAG to non-web information and communications technologies (ICT).

Visit WCAG2ICT at the W3C.

Reviewing Accessibility Conformance Reports (ACR)

An Accessibility Conformance Report (ACR, sometimes known as a Voluntary Product Accessibility Template, or "VPAT") is a voluntary statement from a third-party technology vendor or other tech provider that asserts a level of compliance for their product. Persons involved in purchasing and procurement can review a vendor’s ACR as part of a product acquisition. 

In the United States, the ACR claims are almost universally mapped to WCAG.  Learn more about VPAT/ACR in the purchasing process.

Distributing accountability for accessibility

The architecture of the guidelines, and especially the foundational POUR principles, provide a way for teams to assign accessibility tasks to team members best positioned to apply them. WCAG tasks can apply to stakeholders in a variety of roles including graphic designers, technical writers, application developers, project managers, testing teams, and supervisory roles. 

The W3C Accessibility Responsibility Breakdown is not definitive but offers a starting point for defining accessibility roles in your workgroup.

View the Accessibility Responsibility Breakdown 

Shift-Left for accessibility

WCAG conformance can also serve as a requirement standard for local and in-house development projects. Design teams, project managers, and other stakeholders can use the guidelines to establish timelines, benchmarks, and testing strategies for technology components throughout the life cycle of the digital product. By incorporating the guidelines into each phase of development, project teams can reduce the need for costly and time-consuming remediation in later stages or after release.

Meeting obligations under Title II of the ADA

Although public institutions have long been required to provide equivalent access to services and programs, Title II of the Americans with Disabilities Act had not previously defined a measurable standard for conformance. In April 2024, the Department of Justice issued a Final Rule for Title II that calls for state and local government entitles to make the bulk of their digital content conformant to WCAG 2.1, Level AA by April 2026. This marked the first time an objective standard was established for conformance with Title II.

WCAG Resources

WCAG and WAI Resources from the W3C

Thursday, September 24, 2020