How the Accessibility Developer Guide Relates to WCAG 2.1

Updated

The Accessibility Developer Guide (ADG) is built strictly on the W3C's Web Content Accessibility Guidelines (WCAG) 2.1. It does not replace the standard or invent its own success criteria; instead, it translates WCAG 2.1 into practical guidance for designing, implementing, and testing accessible websites. If you need to build or verify a site against WCAG 2.1, the ADG is intended as a companion that helps you apply the standard in day-to-day work.

The relationship in one sentence

WCAG 2.1 is the normative standard. The ADG is a practice-oriented guide that explains how to meet it.

That distinction matters when you are deciding what to cite or rely on:

Aspect WCAG 2.1 Accessibility Developer Guide
Role Official W3C standard Practical companion
Content basis Success criteria and conformance requirements Best practices derived from WCAG 2.1
Primary audience Anyone defining or auditing conformance Developers, designers, and testers
Scope Requirements to meet How to design, implement, and test

What "strictly based on WCAG 2.1" means for you

The ADG states that all of its contents are based strictly on WCAG 2.1. In practice, this means:

  • The guidance you find there is anchored to the same requirements your auditor or compliance process will use.
  • You can use the ADG to understand how to satisfy a criterion, while still treating WCAG 2.1 as the source of truth for whether it is satisfied.
  • It is not a separate certification or a competing standard, so following it does not exempt you from WCAG 2.1 conformance.

Where the guide fits into a real workflow

The ADG explicitly aims to cover three stages: design, implementation, and testing. That maps cleanly onto how accessibility work usually happens:

  1. Design — decide how components and navigation should behave before code is written.
  2. Implement — build the markup, keyboard behavior, and semantics correctly.
  3. Test — verify the result, including with keyboard and assistive technology.

For example, if your team needs to handle repeated navigation blocks, the ADG's material on skip links and skip navigation links shows the practical pattern: a skip link is usually the first interactive element on a page, visually hidden by default, appearing on keyboard focus so users can bypass repeated blocks. That is a concrete implementation of a WCAG-aligned goal, presented as a usable technique rather than as abstract criteria.

Who should use it, and when

The ADG is a good fit if you:

  • Are responsible for building or reviewing front-end code and need to know what "accessible" looks like in practice.
  • Want guidance that is already aligned with WCAG 2.1, so you are not reconciling two different rule sets.
  • Need to cover the full path from design decisions through testing, not just a checklist.

It is less useful if you need the exact normative wording of a success criterion or an official conformance statement — for that, go to WCAG 2.1 itself.

A note on scope and currency

The ADG also covers topics beyond pure WCAG technique, such as the European Accessibility Act (EAA), which harmonises accessibility requirements across EU member states. That is legal context, not a WCAG success criterion, so treat it as adjacent material rather than part of the WCAG 2.1 mapping. The site is actively maintained, with recent additions and changes, so check the current page for the latest guidance rather than relying on a snapshot.