上海时时乐的技巧:Instructions for Commenting on WCAG 2 Documents
Please read this page for important information about commenting on Web Content Accessibility Guidelines (WCAG) 2.
Note that comments on WCAG 2 cannot impact the standard since it is no longer in development, although we will still take them into consideration as described below.
WCAG 2.0 and WCAG 2.1 are stable Web Standards that will not change. Your comments on WCAG 2 maybe be used for an errata (documenting errors), for updating Understanding WCAG 2 and Techniques for WCAG 2, or for informing the next generation of accessibility standards and guidelines.
Understanding WCAG2 and Techniques for WCAG 2 will be updated periodically. Your comments will help inform the updates.
Before commenting, please read WCAG introductory and education material, including:
How to Comment
There are multiple ways to provide comments on WCAG 2.0 and related documents:
GitHub pull request
The source XML documents for WCAG 2.0 and related documents are available on GitHub . Commenters familiar with GitHub can fork the WCAG 2.0 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.
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.
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, comments and relevant details can be shared with the working group by creating an issue in GitHub.
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 master 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.
Please use online comment form to comment on:
- Web Content Accessibility Guidelines 2.0 (WCAG 2.0)
- How to Meet WCAG (Quickref)
- Understanding WCAG 2.0
- Techniques for WCAG 2.0
(For WCAG 2.0 documents not in the list above, send comments to [email protected], 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 [email protected]. 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 ([email protected]), 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 .
To submit techniques for consideration by the WCAG Working Group, please use the Techniques for WCAG 2 submission form .
For more info
Please see the following resources for more information:
- WCAG documents listed in the navigation area of this page
- How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute