Home

This repository is home to the WCAG 2.0, 2.1 and 2.2 source documents for the WCAG standards and supporting documents.

WCAG 2.0, WCAG 2.1, and WCAG 2.2 are stable Web Standards that are not changing. However, the Techniques for WCAG and Understanding WCAG are updated regularly.

Your comments on WCAG maybe be used for an errata (documenting errors), for updating Understanding WCAG and Techniques for WCAG, or for informing the next generation of accessibility standards and guidelines.

The issues are reviewed and dealt with by the WCAG 2.x task force within the Accessibility Guidelines working group.

The process for the task force is documented.

The meetings are in the calendar, you'll need to be logged in to get the Zoom link.

Commenting on WCAG documents with GitHub

Pull requests (PRs) should be made against the main branch. See the process for the task force for how changes are approved. Pull requests and issues that are accepted by the working group will be merged into the source documents and the commenter will receive a notification from GitHub that the pull request was accepted.

Suggestions for comments submitted via GitHub pull requests

• Provide a complete summary and description for each pull request. The Working Group needs to understand the rationale for proposed changes. This description may need to be very detailed in some cases, such as if proposing to remove a technique; or may be quite brief, for example if providing a change to address a spelling issue.
• Keep pull requests specific to individual comments. Some comments may require changes to multiple source files, for example if an external link is incorrect in multiple files, and this is appropriate if the changes all relate to the same comment. However, if several separate comments are submitted together within a single pull request not only is it more difficult for the working group to parse the different points made in the comment but unless the group agrees with all aspects of the comment the pull request may need to be rejected. In this case, the accepted parts of the comment will be added separately, but utilizing the commenter's contribution is more difficult.
• If the commenter does not know what edits need to be made, filing a GitHub issue is helpful also.