WCAG 2.2 working process

The WCAG 2.2 Success criteria acceptance requirements outline what the (potential) new success criteria (SC) should be, this page details how the AGWG intends to work on those. This is mostly based on the Write up from TPAC 2018.

Overall process

1. An initial list of potential SC proposed.
2. The people who propose each SC write-up a plain-english statement of what it is trying to achieve.
3. We will run a survey for people to sign up to work on each SC, creating one cross-discipline group (CDG) per SC. We are looking for 2-5 people on each SC, including 1 or 2 subject-matter-experts (e.g. COGA TF members for a COGA SC), and 1-3 people from other TFs or the Working Group. At least one person should be familiar with writing WCAG style SC.
4. Each mini-group will create a document for each new SC. This process will take a few weeks, and could run in parallel to the review sprints.
5. We will hold a survey to establish the initial ordering of new SC to work on. SCs at the top of the order should include those from/for COGA and any which require new tools for testing. However, there are practical contraints as well, we can only review & work on SC which have reached agreement in the CDG.
   • The survey will contain a mechanism to quantify the prioritization of SC to work on.
6. The first two (a) SC will be reviewed by the working group, and worked on in 2-week review sprints.
   • Feedback offered by the WG in the first week needs to be incorporated by the end of the week for Working Group review during week two.
7. At the end of each sprint "objections" (b) are noted in a survey, and SC not agreed on are put in the backlog. SCs that have been put into the backlog can be put into a new sprint if there are changes that address the objections.
8. At the end of each sprint two SC will be selected for the next sprint. There will need to be discretion by the chairs to keep making progress efficiently, deciding when to put SC into each sprint or move on to new SC.
9. When there is agreement that an SC meets the requirements, it will be integrated in to the Editors draft.

Note: The group will run periodic retrospective to assess the process & progress, approximately every 5 sprints.

Notes

a) After the 1st sprint, we may vary the number of SCs we deal with at one time.

b) "Objections" in the sense of "this doesn't meet the SC requirements yet", it does not mean the purpose of the SC is invalid.

Github is still the best place for comments, but each document will be listed on this wiki.

With 2 week sprints, there are likely to be less than 20 sprints before the draft is locked-down.