w3c/wcag: A Source Repository for WCAG 2 Editorial Work

WCAG content authoring rather than runtime checking

w3c/wcag addresses the editorial and publication side of web accessibility standards. Its README says the repository is used to develop content for WCAG 2, associated Understanding documents, and techniques. The intended users include Success Criteria Managers, editors, Working Group contributors, and other people preparing proposals or explanatory material. It is not presented as an accessibility scanner, browser extension, assertion library, or service that inspects a deployed site.

That distinction determines how to evaluate the project. A development team looking for automated checks during application work needs software that accepts URLs, page elements, browser state, or source files. This repository instead contains structured source documents and a build system for assembling normative and explanatory content. Its links to onboarding documentation and the WCAG 2 Style Guide also place it within an editorial and standards-review workflow.

Versioned HTML fragments in the wcag repository

WCAG 2.1 and later content is divided into directories so that individual criteria and definitions can be edited independently. The main document is `guidelines/index.html`. Individual success criteria are stored below `guidelines/sc/{version}/*.html`, definitions below `guidelines/terms/{version}/*.html`, and Understanding material below `understanding/{version}/*.html`. The version values identify where content originated: `20` for WCAG 2.0, `21` for content introduced in WCAG 2.1, and `22` for content introduced in WCAG 2.2.

Each success criterion is an HTML fragment rather than a complete page. The documented structure contains an `h4` for the criterion handle, a paragraph containing its conformance level, a paragraph describing its change status, the main criterion text, optional definition-list points, and optional notes. Definitions use `dt`, `dfn`, and `dd` elements. A reference to a defined term uses an anchor without an `href`, allowing scripts to generate the appropriate link.

This file structure supports parallel editing, but it also makes `guidelines/index.html` part of the workflow rather than the sole entry point. A contributor must determine which version directory owns the proposed criterion and whether related definitions or Understanding content need changes.

Eleventy, Liquid, and Cheerio document processing

The repository uses Eleventy for its build system, Liquid for templating, and Cheerio for transformations. The root `package.json` identifies the project as a private package named `wcag`, version `0.1.0`. Its `build` script invokes `tsx` and the Eleventy command-line program with `eleventy.config.ts`. The file also defines TypeScript checking, Prettier formatting, CSpell spelling checks, changelog generation, W3C publishing commands, and a local watch-and-serve command.

The project is therefore both standards content and a build environment. Editing an HTML fragment may require a build or formatting pass, while changes to configuration can affect generated documents. The README identifies `11ty/README.md` as the source for more detail and local preview instructions, but the root README does not reproduce the complete preview procedure.

The top-level layout extends beyond the core guideline files. Directories such as `errata/`, `conformance-challenges/`, `requirements/`, `techniques/`, and `working-examples/` indicate separate editorial concerns. Cloning the repository therefore provides access to a broad standards workspace rather than only the published guideline text.

Cloning wcag and preparing an edit

The README directs contributors to clone the repository using its GitHub URI. It does not give a complete dependency installation command in the root document, so consult `11ty/README.md` for that part of the setup.

The URI to clone from is https://github.com/w3c/wcag.git.

After cloning, the contributor switches to a working branch named for the shortname of the draft success criterion and its issue number, concatenated together. The exact branch name comes from the proposal, so it cannot be replaced with a generic value.

For a candidate criterion, the README instructs contributors to open the corresponding file in `guidelines/sc/21` when editing a WCAG 2.1 proposal. Related definitions live in `guidelines/terms/21`. The branch can use another version directory when appropriate.

The documented fragment shows where a contributor places the criterion text. Braces denote values that the contributor replaces. The author does not supply the success-criterion number because numbers are assigned later.

<section class="sc">
	<h4>{SC Handle}</h4>
	<p class="conformance-level">{Level}</p>
	<p class="change">{Change}</p>
	<p>{Main SC Text}</p>
</section>

`Level` accepts `A`, `AA`, or `AAA`. `Change` accepts `Unchanged`, `Changed`, or `New`. Optional sub-points use `dl`, `dt`, and `dd`, while notes use `p` elements with `class="note"`. After editing, the contributor updates the relevant references in `guidelines/index.html`, which may require removing or adding HTML comment marks around those entries.

Working Group review before wcag publication

A repository commit does not by itself make wording part of a published WCAG requirement. The README defines a review path that starts with a candidate success criterion on a proposal branch. The contributor saves the files and uses a suitable commit message, including the originating issue number in the commit comments with a hash-prefixed reference such as `#1`.

When the criterion is ready, the contributor informs the chairs for Working Group review. After the Working Group accepts the proposal, editors merge the working branch into `main`. The README says that merge places the proposal into the editors' draft and the eventual Technical Report publication path. Contributors therefore need to track both Git operations and formal review status.

Understanding content follows a related but separate structure. `understanding/index.html` acts as an index, while version-specific Understanding files sit below `understanding/{version}`. The README says these files begin with a template and that elements with `class="instructions"` provide guidance. Contributors are told to retain the template structure while adding content, reducing structural variation across criterion explanations.

The publication scripts show how selected output is built. The `publish-w3c` script uses `WCAG_VERSION=22`, `WCAG_JSON=1`, and `WCAG_MODE=publication`. A separate `publish-w3c:21` command targets version `21`. These are publication commands, not evidence that every repository commit has become normative WCAG content.

Term definitions, generated references, and limitations

Term definitions have a dedicated format that enables scripts to recognize and link them. The README uses `dfn` with a `dfn-{shortname}` identifier and places the definition in a following `dd` element. The `dfn` element instructs the build process to apply term styling and linking behaviour.

A term reference does not need a hard-coded destination in the source fragment. If the link text exactly matches the canonical term, the document can use an anchor without an `href`:

<a>web page</a>

Inflected or alternate wording requires a `data-lt` hint. For example, the README documents the canonical term `web page` with alternate link text `web pages|page|pages`. This keeps definitions and generated references coordinated, but contributors must distinguish defining a term from merely mentioning it.

The repository has real limits. Its scripts build, check TypeScript, format files, check spelling, generate changelog data, publish output, or start a preview. They do not inspect a deployed website. Automated accessibility scanners examine implementation behavior, whereas this repository supplies the wording, definitions, Understanding documents, techniques, and processing tools for standards work. Successful generation cannot prove that an application conforms to WCAG.

Maintenance, releases, and the custom wcag licence

The repository is not archived, and its last push was on 2026-10-16. Its GitHub history has no GitHub releases, so release notes and packaged upgrade artifacts are not available as an adoption signal. The root package version is `0.1.0`, but `package.json` also sets `"private": true`, presenting the package metadata as private rather than as a public software distribution.

Maintenance follows content and review changes rather than a conventional dependency release cycle. Contributors may edit version-specific criteria, definitions, Understanding files, build scripts, configuration, techniques, or supporting directories. The root README links to onboarding and `11ty/README.md`, but it does not provide a complete dependency installation sequence or a full local preview procedure.

GitHub classifies the licence as custom, and the repository contains `LICENSE.md`. The `package.json` licence field is `W3C`, which is not sufficient by itself to determine permitted reuse, attribution, modification, or redistribution. Review `LICENSE.md` and the relevant W3C contribution terms before copying content into a product or publishing derived material. This is a repository-integrity check, not legal advice.

Editorial conclusion

Adopt w3c/wcag if you are contributing WCAG 2 wording, definitions, Understanding content, or publication processing. Do not use it as an application dependency or expect it to test a website automatically. Before contributing, inspect the version-specific files, read `11ty/README.md`, check the relevant Working Group review process, and examine the custom terms in `LICENSE.md`.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. w3c/wcag on GitHub