Skip to content

Compare: WCAG 2 Task Force process

Showing with 105 additions and 5 deletions.
  1. +69 −0 2025‐01‐10.md
  2. +26 −0 2025‐01‐17.md
  3. +1 −1 Draft-Work-Statement.md
  4. +3 −0 Meeting-minutes-index.md
  5. +6 −4 WCAG-2-Task-Force-process.md
10 changes: 6 additions & 4 deletions WCAG-2-Task-Force-process.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ Contents:
* [Standing Agenda](#Standing-Agenda)
* [Project board](#Project-board)
* [Approval process for changes](#Approval-process-for-changes)
* [Levels of issue/change](#levels-of-issuechange)
* [Levels/labels of issue/change](#levelslabels-of-issuechange)
* [Errata changes](#Errata-changes)
* [Email template](#Email-template)
* [GitHub issue triage](#GitHub-issue-triage)
Expand Down Expand Up @@ -104,13 +104,15 @@ Generally issues/PRs go from left to right, but may go back one or more steps if
* Anything which cannot be resolved (get consensus) in the github thread will be placed on the **For discussion** column and included in a meeting agenda
* Any proposed normative change will be tagged as both Normative and Erratum Raised and brought to an AG meeting.

## Levels of issue/change:
## Levels/labels of issue/change:

* **Normative**: Changes to the normative text of the specification, as defined in [5.1 Interpreting Normative Requirements](https://www.w3.org/TR/WCAG22/#interpreting-normative-requirements), which would individually be escalated to the chairs as a Normative Erratum Raised and go through a CFC process.
* **Normative**: Changes to the normative text of the specification, as defined in [5.1 Interpreting Normative Requirements](https://www.w3.org/TR/WCAG22/#interpreting-normative-requirements), which would individually be escalated to the chairs as a Normative and go through a CFC process. The working group is currently working through a process to differentiate the scope of when a normative change is classified and reported as an erratum, and the scope when the change exceeds an erratum and is queued to be part of a new version of the specification.

* **Erratum**: Normative and non-normative parts of the specification can both be tagged as errata. An obvious typo in the normative text that does not alter meaning is an erratum (and so labelled both Normative and Erratum Raised). Changes to examples or notes within the technical standard are tagged with Erratum Raised, but do not constitute normative changes, so do not also get the Normative tag. They still go through a specific adoption and merge process, and also need to be added as errata (see Errata changes, below).

* **Substantive**: Changes that meaningfully add or alter existing guidance. New techniques, new sections in documents, concepts being added or emphasized. This includes if there is a total restructuring of an informative document so that it might not be obvious to a casual observer that meaning has not changed. As well, any previously proposed substantive changes which received divergent feedback and have been redrafted.

* **Editorial**: Improvements that are not intended to alter interpretation. Re-phrasing that clearly does not change meaning, but aims to improve readability or understanding of informative documents. Examples include adding headings, adding or changing sentences, reordering sentences or paragraphs. This includes previously proposed substantive or editorial changes approved by AG and for which only minor changes were needed to be resolved. Note that changes to examples or notes within the technical standard are tagged with Erratum Raised, but do not constitute normative changes, so do not also get the Normative tag (instead, Editorial). Examples and notes in definitions, for example, are not normative, but do need to go through a specific adoption and merge process, and also need to be added as errata (see Errata changes, below).
* **Editorial**: Improvements that are not intended to alter interpretation. Re-phrasing that clearly does not change meaning, but aims to improve readability or understanding of informative documents. Examples include adding headings, adding or changing sentences, reordering sentences or paragraphs. This includes previously proposed substantive or editorial changes approved by AG and for which only minor changes were needed to be resolved. .

* **Bug fix**: Trivial editorial corrections (e.g., typos, spelling, subject-verb agreement, punctuation), style consistency, code syntax corrections, broken links, etc. will be reported in the PR, but the work will be done as the errors are found.

Expand Down