Home

This repository is home to the WCAG 2.0 source documents for the WCAG 2.0 standard and supporting documents.

WCAG 2.0 itself is a stable Web Standard that is not changing. However, the Techniques for WCAG 2.0 and Understanding WCAG 2.0 are updated approximately every six months.

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

Commenting on WCAG documents with GitHub

The WCAG 2.0 sources page includes basic information about the files contained in the GitHub repository to help commenters understand which files to edit.

Pull requests should be made against the latest working branch rather than the main branch. When a pull request is accepted by the Working Group, an editor will integrate changes into the working branch. When it is time to publish the complete document as a refreshed document (about every six months) then the working branch will be merged into the main branch. 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 and an email indicating this will also be sent to the public WCAG comments email list.

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.