Scope of WCAG 2.2 / 2.1 errata changes

[alastc]

To help guide the WCAG 2.2 Task Force, it would help for the group to agree what level of change can be made to the main specification documents (WCAG 2.2 and 2.1).

For the informative documents (Understanding and Techniques docs), this is outlined in the Task force process.

The current status for the normative document is that we would not add "new features" (e.g. a new Success Criteria) without starting a new version (a 2.3) and we have not agreed to do that. For errata it is being done on a case by case basis.

Things we have agreed to previously are:

• Adding a note to WCAG 2.1 explaining that SC 4.1.1 is no longer providing any benefit (and not including the SC at all in WCAG 2.2 as it was published).
• Updated informative notes underneath SCs (e.g. Amend the note for focus appearance #3657).
• Updated the definitions for flashing and red-flashing thresholds.
• Made numerous consistency updates.

The positives to updating the main document can be:

• Where we find that people interpret the text differently, we can ensure the intended meaning is conveyed.
• People using the document should find it easier to understand & interpret if it is refined.

The negatives can be:

• Misalignment with translated versions.
• Some legally enforced standards (e.g. EN 301 549) link to the 'canonical version' (e.g. /TR/WCAG22/) rather than a dated version, so changing WCAG 2.x changes the legal situation.

Please do comment with other positives/negatives underneath if you can think of any more.

I think everyone is in agreement with including very minor editorial updates, and not making updates to substantially change the meaning of normative text at the A/AA level.

However, there is a grey area in the middle ground.

For example, an exception on timing-adjustable is a good case here, where it can be interpreted as “Extend to 10 times the original limit of time”, or “Extended by 10 instances with no time constraint”. We know what the original writers intended, but it’s about a 50/50 split in how people have interpreted that clause.
Currently people could be failing instances of this in different ways. A very knowledgeable person could say that either interpretation can be used, but it is likely to be causing disagreements out there.

That could be dealt with by an errata to make only one interpretation possible. However, we have not been able to agree that.

So there is a class of changes which is to update the text to prevent multiple interpretations, which may or may not (depending on your point of view) change the meaning of the text.

Another example is a alignment of target size at AAA, with the newer AA version in PR #2858. We agreed that in-meeting, but one or more people who weren't at the meeting are likely to -1 in the CFC. That improves the cross-tester agreement, but does change the normative text so that some cases might pass/fail differently. Does that matter at AAA?

The question for each of my comments below (case 1-4) is: Should we implement this type of errata to WCAG 2.2/2.1 in future?

Please thumbs up or down for each case (not the arrows!)

[alastc]

Case 1: Capitalization, dashes, other minor editorial

For example, changing "web site" to "Web site", or "real time" to "real-time". E.g #3267

[WilcoFiers]

I'm not too keen on even these kinds of changes. I can live with this stuff, but I feel if we're going to keep making these kinds of changes we have a responsibility for promote and track down stream adoption of them. We should check whether changes are getting picked up in important "copies" and implementations of WCAG. We should get in touch with the people responsible for those copies and try to get dates for when those are updated.

There is a good deal more that needs to be updated when WCAG changes, not just translations:

• ISO/IEC 40500
• Lots of W3C resources including WCAG2ICT, Quickref, ACT Rules, etc.
• Developer docs like web.dev and MDN
• Test methodologies like Trusted Tester, RGAA, BiTV, etc.
• Accessibility test tools and their documentation

[goodwitch]

+1 (I'm okay with these changes, that is technically what errata is all about). I'd love it if we could help other dependent copies (like ISO/IEC 40500) know about these types of changes...but since the changes will not be changing the meaning...I can live with not proactively alerting other "copies".

[jenstrickland]

As long as all instances of those words are consistent in the original, they should not be changed afterwards. People understand what it means, and whatever the proper term is will be subjective in most cases.

[mbgower]

As long as all instances of those words are consistent in the original, they should not be changed afterwards. People understand what it means, and whatever the proper term is will be subjective in most cases.

To provide context, the words are rarley consistently used in the original. While I agree that preferred style is subjective, the "proper term" is determined in accordance with the style guide maintained by the W3C.

[alastc]

Case 2: Informative parts of normative docs

For example, notes under SCs or definitions, e.g. #3657

This assumes the update to the note does not change the meaning of the SC, but does improve or refine the explanation.

[goodwitch]

(0/neutral) Super slippery slope. I'm technically okay with this...but we've got to be 100% certain that the proposed change to informative (inside a normative document) is NOT changing the meaning of the normative.

[yatil]

Considering that notes and other informal documents are not part of the normative text of the document, they cannot change the normative meaning of an SC. They might introduce confusion, but the normative text is the same.

[alastc]

Case 3: Align AAA criteria with newer criteria

For example, adjusting the inline-text exception of Target Size (Enhanced) with Target Size (min), e.g. #2858

[mbgower]

I believe these need to be handled on a case-by-case basis. Where there are foundational reasons that one level of complementary requirement is intentionally phrased distinctly from its peer at another level, that is a different situation than where the wording of one requirement was not considered when a complementary requirement at another level was altered for specific reasons.
In other words, where this is unintended misalignment that is causing interpretation confusing, it should be dealt with it.

[goodwitch]

(-1) While I agree that AAA criteria should be aligned with newer criteria, but changes like this are not errata changes. This type of change must be indicated with a version number. Perhaps we could adopt a version like 2.1.x and 2.2.x to indicate this type of change.

The legal definition of errata: Errata refers to errors in printing or writing, such as misspellings, omissions, and other typographical errors. For example, after taking a deposition, the testimony is transcribed by the reporter. After reading the transcript, the parties may submit a list of errata to the reporter, so that corrections may be made to accurately reflect the testimony. However, the party may not use an errata list to change the printed wording due to a change of mind regarding the testimony given. It is used to merely correct inadvertent errors. If substantive changes to the printed content is sought, it may be disallowed or subject to review.

source: https://definitions.uslegal.com/e/errata/

[alastc]

In the context of W3C process, errata can be any change that doesn't add new features.

[yatil]

I don’t think the usage of AAA criteria is worth touching them for consistency reasons.

[mbgower]

@goodwitch, you said

(-1) While I agree that AAA criteria should be aligned with newer criteria, but changes like this are not errata changes. This type of change must be indicated with a version number. Perhaps we could adopt a version like 2.1.x and 2.2.x to indicate this type of change.

The legal definition of errata: Errata refers to errors in printing or writing, such as misspellings, omissions, and other typographical errors. For example, after taking a deposition, the testimony is transcribed by the reporter. After reading the transcript, the parties may submit a list of errata to the reporter, so that corrections may be made to accurately reflect the testimony. However, the party may not use an errata list to change the printed wording due to a change of mind regarding the testimony given. It is used to merely correct inadvertent errors. If substantive changes to the printed content is sought, it may be disallowed or subject to review.

source: https://definitions.uslegal.com/e/errata/

It is important to point out that the above definition is not the determinant to this discussion. The W3C clearly defines what it considers errata in the Classes of Changes section of the process document:

In this Process Document, the term “erratum” (plural “errata”) refers to any error that can be resolved by one or more changes in classes 1-3 of section § 6.2.3 Classes of Changes.

I am going to quote class 3, because it illuminates the breadth of what is intended to be allowed within the errata process:

Other changes that do not add new features

For Recommendation-track documents, these changes may affect conformance to the specification. A change that affects conformance is one that:

• makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or
• makes non-conforming data, processors, or other agents become conforming, or
• clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming.

That last bullet is the focus of one of the casees Alastair has posted.

[alastc]

Case 4: Removing multiple interpretations

For example, changing Timing Adjustable so that it is clear whether it is 10 times the original time, or 10 opportunities to extend the time. #2584

[yatil]

And I agree to change the normative text and is outside of errata. (At least when it is done 16 years after the initial release. Within the first year, I can see errata to resolve issues like this, but at some point, it’s not erratable. That said, I’m 100% pro changing SCs if they get better.)

[patrickhlauke]

I had people argue that extending the time 10 times by 1s would technically meet the SC, and that’s fine by me. If people want to be disrespect their users, that’s their choice.

my concern is more the opposite scenario ... a developer who lets the user extend the timeout by 10 times the standard length, but not in 10 individual instances, only in 9 or something. end result is the user is given sufficient actual time, but the fail the normative wording because they don't get 10 instances of extension. these are the "you're doing everything right, but you're failing due to the an arbitrary misguided wording in the SC text"

[yatil]

I think one extension at 10x the initial time limit meets the SC. But yeah, it should be clear from the normative wording. (“It is possible to extend the time limit so that at least 11 times the length of the initial time limit passes before the user is unable to extend the time limit further.”)

[MakotoUeki]

In Japan, it was interpreted and translated as "it is 10 times the original time" when the 2010 year version of JIS X 8341-3 (Japanese national standard) adopted WCAG 2.0 SCs.

I'm curious to confirm which was the intent when WCAG 2.0 became the W3C recommendation in 2008.

[mbgower]

(-1) by definition, this is not errata. See legal definition of errata: source: https://definitions.uslegal.com/e/errata/

As mentioned in another thread, this is an errata according to the w3c process.

[WilcoFiers]

I also think it's worth talking about "accidentally" making a substantive change to WCAG. On several occasions now I've pushed back on changes proposed by Backlog TF, where the proposed change wasn't intended as a substantive change, but careful reading of it showed that at least it could be. Such as removing currency-amount, prohibiting color picking for contrast in CSS, linking to the definition of "text" in places that shouldn't have it, the updated pointer input definition.

Since there is no "case 5: make a substantive change to a criterion" I assume the intent is to never make substantive changes. But are there things this group can / should do to avoid accidentally making a substantive change?

[mbgower]

IMO everyone involved in the WCAG 2 TF process is biasing to a conservative approach to changes. We are really talking about degrees of conservatism.

In response to Wilco's question, are there things this group can / should do to avoid accidentally making a substantive change?, IMO the entire process we have generated is aimed at addressing this, starting with the scope of work. The review phases within the TF, the wider AGWG reviews, and the CFC process (in the case of normative changes) all scrub the language and reduce this risk. He is not the only person who has identified unintended consequences of a change, which have then been addressed; those identifications, and the discussion surrounding the nature of the changes, serve as indicators on the success of the cautionary approach taken by the group.

--

That said, this discussion points to the inherent conflict between stable normative wording and two phenomena:

1. the reality that there are errors and contradictions in the standard which, if left unaddressed, reduce the value of the standard and confidence in it, and
2. the reality that interpretations change over time -- in the sense of how different individuals understand the wording and what they do as a consequence of their understanding (not in the sense of a translation between languages).

The most conservative position -- never considering altering any of the material -- doesn't solve either problem. It puts the written language in a state of stasis, but conflicts and errors continue to cause problems, and interpretations of language will continue to change, as demonstrated by the continuously growing number of issues opened against WCAG 2 (we have closed over 1500 issues, and yet the number of new issues has kept the open issues at approximately 600).

The w3c process provides some flexibility in how errata can be used to do minor corrections (but not additions) to address point 1. Changes to our non-normative guidance (including non-normative changes in normative documents) seem to be the primary means for addressing point 2.

[WilcoFiers]

@mbgower

1. the reality that there are errors and contradictions in the standard which, if left unaddressed, reduce the value of the standard and confidence in it, and
2. the reality that interpretations change over time -- in the sense of how different individuals understand the wording and what they do as a consequence of their understanding (not in the sense of a translation between languages).

You and I agree on that. The major issue I have with what backlog TF is doing is that this is being done through the errata process. I am all on board with putting out a revised WCAG 2.x, but it has to be versioned properly. If it's not backward compatible with 2.x, then it needs a new major version, or we need some other versioning scheme that lets us break away from 2.x.

Solving these issues through errata's is far too problematic. Our WCAG 2.x ecosystem isn't set up for backward incompatible changes, even minor ones. WCAG 2 isn't a living standard. I too want to see these issues addressed, but erratas create far more problems then they solve.

I strongly disagree with you that this process is working. We're not going through W3C approval, we're not going through public review, translations aren't getting doing, we're not updating republications of WCAG. And we too can make mistakes, miss things, introduce new problems. But because we're using erratas, there is no public review. Through EN 301 549, a very small group has somehow ended up with the ability to on a dime, change legal requirements for web accessibility on a global level, without oversight, basically whenever we feel like it. That's terrifying! We shouldn't want that responsibility.

[alastc]

or we need some other versioning scheme that lets us break away from 2.x.

If the EN linked to a dated version, would that resolve this for you?

[yatil]

We could easily do WCAG 2.2 Rev. March 2025 and lawmakers can decide if they want to reference the latest WCAG 2.1 or a specific revision. This is all solvable. (My preference would be that the EN references WCAG 2, the latest published version, with enforcement of new/changed SCs 6 months after publication.)

[WilcoFiers]

If the EN linked to a dated version, would that resolve this for you?

It wouldn't. EN linking to WCAG isn't the problem. This TF proposing to make substantive changes to WCAG through the errata process is. I think these revisions are largely a good idea. I'm supportive of a regular re-publication of WCAG to start addressing inconsistencies and undesirable ambiguities, but it needs to be properly dated, versioned, and reviewed. You don't even need to do it on rec track if that's too much of a hassle. Put it out as a working group note, if there's a lot of interest in having that in an actual read you can choose to raise it to a rec in the future.