This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.


Jump to: navigation, search

Page to track the creation and review of new techniques & failures for WCAG 2.1.


  • Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.
  • Draft the technique, either:
    • Create in the wiki by copying the content of the template.
    • Editing the appropriate branch in Github (instructions below).
  • Link to the draft technique by editing the page below.
  • The drafts will be reviewed by the AG working group.

NB: To find the branch in github, go to the main repository page and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.

Understanding Document tracking


List of Techniques

PLEASE NOTE: The tracking and assignment is now handled in a spreadsheet, not this page!

The spreadsheet is viewable here, contact the chairs for editing rights:

Creating Technique documents

The overall process is:

  1. Decide on a technique to work on, put your name next to it in the page above, or identify the change that is needed in the Understanding document.
  2. Work on it, in a new GitHub branch, on the wiki, or wherever you want. For guidance on techniques see
  3. When it is ready, create a pull request (if using a github branch) and/or tell the chairs.
    1. If developed in the wiki or elsewhere, the chairs will make the branch and then make the Pull request. At this point, any further edits will take place in GitHub unless the content is sent back from the WG for major re-work.
  4. Chairs will label the pull requests with "Ready for initial review" and "Techniques".
  5. Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed). Reviewers can search for pull requests by searching for the labels
  6. Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is "ready" (the 5 people should not all be from a single TF).
  7. Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as Sufficient Technique with changes/Accept as Advisory Technique with changes/Do not accept yet and will require people to comment in Github.
  8. If the "ready" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.
  9. Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.
  10. If there are major problems or major changes that the group believes requires additional review, the process for review repeats

There is general guidance on writing techniques: Technique writing resources, see especially the writing notes.

Github step-by-step

Github branch dropdown.png

Step 1: Go to the working branch (this is important!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the github repo and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).

Initial creation

To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.

Step 2: Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft".

If you need to create a separate page for examples you should include a folder for it under /working-examples/, so /working-examples/example-name/. There is more about that in the readme.

Add a comment to this wiki page, saying you've updated it.

Reviews and alternative versions

For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. Do step 1 first, select the working branch.

Step 2a: Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.

Step 3a: Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.

Step 4a: Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.

Wikitext version

If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.

  1. Create in the wiki by copying the content of the Technique Template.
    1. Give it the same name as in the listing above.
    2. Let the chairs know you've created it (so it can be copied into github).
  2. Create it in github, steps below.