Instructions for Commenting on WCAG 2.1 Documents

GitHub

WCAG 2.1 source documents and source documents for the Techniques and Understanding content are all publicly viewable on the WCAG 2.1 GitHub Repository. The repository allows people outside of the Working Group to log issues and to suggest code changes through pull requests.

Issue Processing

When submitting an issue via GitHub, please be aware that the Working Group will be discussing the issue on this issue’s discussion thread in GitHub, as well on Working Group teleconferences and other communication channels. You are welcome to participate in the discussion on GitHub, but please be advised that all discussion is preliminary and should not be interpreted as a Working Group decision or official response to the issue until explicitly indicated as follows.

If an issue is purely editorial (e.g. a spelling or grammar error), a full Working Group response is not required, and an Editor may provide a response and will preface the response with "[Editorial Resolution]".

Issue Resolution

Once the Working Group reaches consensus on an issue a comment with the resolution will be provided in the GitHub issue. This comment will include “[Official WG Response]” at the start of the comment to indicate that it represents the official position of the Working Group.

At that time, we request that you confirm whether you are satisfied with the response within 1 week. In the event of no response the Working Group will regard the issue as being satisfactory to the individual or group initiating the comment. 

If an issue is purely editorial (e.g. a spelling or grammar error), a full Working Group response is not required, and an Editor may provide a response and will preface the response with "[Editorial Resolution]".

When the Working Group offers the Official response for a GitHub issue, it will add the GitHub user name for the original commenter so they are notified.

Issue Notifications

On GitHub issues a commenter is automatically "subscribed" to the discussion thread and may receive many email notifications for issues with active discussion (some issues have received ~400 responses). To unsubscribe from the discussion thread in the GitHub web interface, click the button labeled “unsubscribe” presented in the right column and following the text “Notifications”. You will not receive any further emails unless your GitHub user name is mentioned in a comment or if you comment on the the issue discussion thread – both of these will reset your status to be subscribed to the issue thread.

Pull requests

Commenters familiar with GitHub can fork the WCAG 2.1 repository, clone that to their local machine, edit the source files, and submit a well-commented pull request as a way to provide comments and edits to the working group for review. If you later decide to make another pull request, first sync your fork to be sure your edits will be based on the the latest content.

Suggestions for comments submitted via GitHub pull requests:

1. 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.
2. 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.
3. If the commenter does not know what edits need to be made, comments and relevant details can be shared with the working group by creating an issue in GitHub.

Online Form

Please use online comment form to comment on:

• Web Content Accessibility Guidelines 2.1 (WCAG 2.1)
• How to Meet WCAG (QuickRef)
• Understanding WCAG 2.1

(For WCAG 2.1 documents not in the list above, send comments to wai-eo-editors@w3.org, a publicly archived list.)

When you use the form, your comments are automatically entered into our comment tracking database.

Email comment submission

If you cannot use the form, you can send comments to public-comments-wcag20@w3.org. So that we can best understand and address your comments, please include:

• the title of the document
• location within the document
• the concern
• the suggested change
• and any additional rationale for the comment

The WCAG Public Comments List is for public comments on the WCAG documents. Please use the forms only to submit errors, omissions, issues, or needed clarifications.

Please note that these forms should not be used to ask questions about particular websites or implementation issues. Questions about how to apply WCAG to a particular page or site should be directed to one of the many consultants working in the area, to the WAI Interest Group (IG) mailing list (w3c-wai-ig@w3.org), or to one of the many other mailing lists and forums that focus on Web accessibility.

Note: Comments submitted via the form and via e-mail are publicly available in the archive for the WCAG 2.0 public comments mailing list.