RE: Updating WCAG SCs through erratas, instead of as part of 2.2

Thank you Wilco for creating a separate thread for this conversation!

As someone who missed the 2.0 retcon to 1.3.3 to include color, I would argue that we should do both.  That is, issue an errata for 2.1 – and have the corrected wording in 2.2.

I would also be okay with republishing 2.0/2.1 with a new date (that incorporates the errata) but with each keeping the same versioning.   Or with having a 2.01 and 2.11 (or 2.0.1 / 2.1.1) versions.

Just having corrections in errata doesn’t surface them, and you note examples of that with the translations.  Have the QuickRef (et al.) updated with the corrected phrasing at least serves as a clue that one might need to check the errata.  Keeping the QuickRef (et al.) true to the first dot release just means the errata is easier to miss.

FWIW, IMHO, the 2.0 retcon to 1.3.3 is a noop.  Since 1.3.3 is scoped to only instructions, and instructions are a subset of “conveying information” as scoped by 1.4.1, adding “color” to 1.3.3 does end up being a trivial edit.

--
Top posting for my convenience.


From: Wilco Fiers <wilco.fiers@deque.com>
Sent: Saturday, October 19, 2019 4:52 PM
To: Patrick H. Lauke <redux@splintered.co.uk>
Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: Updating WCAG SCs through erratas, instead of as part of 2.2

Hey all,

Firstly, I'm creating a separate thread for this conversation, as I don't want to derail the existing talk about 1.4.11.

The short version of why I'm against changing success criteria in WCAG 2.2 is that success criteria need to be consistent between it's minor versions. Not doing so causes problems. The way to handle updates to success criteria is through eratas. Anything that wouldn't be acceptable as an errata, shouldn't be a change to the SC in the first place.

There is a lot of documentation, audit templates, test methodologies, tools, etc. that need to serve multiple versions of WCAG 2.x. One example at the W3C is the quickref, which is linked from both WCAG 2.0 and WCAG 2.1. I'm sure almost everyone on this list uses things like that. Updating success criteria texts between versions of WCAG causes problems in those environments.

Let's say AG did update SC 1.4.11 in WCAG 2.2. We would also update the quickref, techniques and understanding docs to reflect that. But those documents are the same ones used for WCAG 2.1 and 2.0. So the WCAG 2.1 SC 1.4.11 "how to meet" link goes to a page which has a different SC text from what is in WCAG 2.1 itself. That's problematic. The wording of the success criteria is the most crucial part of WCAG. People spend whole days discussing the precise meaning of individual words! Having the normative text say one thing, and the help say another is likely to create confusion. One could argue it's even a failure of SC 3.2.4 Consistent Identification.

There are already examples of this. The 2017 WCAG 2.0 errata (https://www.w3.org/WAI/WCAG20/errata/<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG20%2Ferrata%2F&data=02%7C01%7Cbailey%40access-board.gov%7C8c192a82478340998f0d08d754d64ed5%7Cfc6093f5e55e4f93b2cf26d0822201c9%7C0%7C0%7C637071151738885573&sdata=Oir0iVPin9tjE50ou9phpgDpM6C5t3xtdKsi6Arrdho%3D&reserved=0>) made a number of changes to success criteria. Unfortunately those changes were never applied to WCAG 2.0, showing up in 2.1 for the first time. If you look at SC 1.3.3 in WCAG 2.0, and follow the "how to meet" link, the word "color" is now in the SC text. Someone using trusted tester methodology, may really be surprised by this, because it (based on the language still in WCAG 2.0) explicitly says that color is not included in 1.3.3 (https://section508coordinators.github.io/TrustedTester/sensory.html<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsection508coordinators.github.io%2FTrustedTester%2Fsensory.html&data=02%7C01%7Cbailey%40access-board.gov%7C8c192a82478340998f0d08d754d64ed5%7Cfc6093f5e55e4f93b2cf26d0822201c9%7C0%7C0%7C637071151738885573&sdata=0mXEjjbcHmpS1JvanR25P496%2FIgzG9RB1wyjuMzxhZ4%3D&reserved=0>). Trusted tester isn't the only place I've seen this either.

> If instructions or operating procedures rely solely on:
> - color, then the content FAILS for 13.A for 1.4.1-color-meaning.
> - other sensory information (such as shape, size, visual location, orientation, or sound), then the content FAILS for 13.B for 1.3.3-sensory-info.

Another problem that came from this, is that none of the WCAG 2.1 official translations have all the changes from the erata in them (at least, they don't appear to have, given the help of a translation tool). The 1.3.1 "color" add isn't in the Danish and Chinese translations. That's in documents which went through a rigorous review process. This isn't likely to be better in all of the thousands of guides, tools and templates that have these texts in them.

I have no problem updating the language of WCAG success criteria for the purpose of clarifying them. But those changes should be made to all WCAG 2.x versions, not only to the latest one. By doing this, AG ensures that documentation and tools like the quickref can be accurate across all WCAG 2.x releases. It is also important that those changes are called out somewhere, so that if someone does see a difference, they can figure out where it came from.
Kind regards,

W


On Thu, Oct 17, 2019 at 11:12 PM Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
On 17/10/2019 20:09, Wilco Fiers wrote:
> -1 to this and any other change changing existing success criteria.

The proposed change does not change the coverage or meaning of the SC,
it just makes it clearer. I'm not quite seeing why you'd be reluctant in
this case.

P
--
Patrick H. Lauke

www.splintered.co.uk<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.splintered.co.uk&data=02%7C01%7Cbailey%40access-board.gov%7C8c192a82478340998f0d08d754d64ed5%7Cfc6093f5e55e4f93b2cf26d0822201c9%7C0%7C0%7C637071151738895567&sdata=Ygx4qF8JpGj%2FcJ%2Ba4LaUk9GjJgVNyoXsrHJKOBg%2Fd1A%3D&reserved=0> | https://github.com/patrickhlauke<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpatrickhlauke&data=02%7C01%7Cbailey%40access-board.gov%7C8c192a82478340998f0d08d754d64ed5%7Cfc6093f5e55e4f93b2cf26d0822201c9%7C0%7C0%7C637071151738905561&sdata=poBRLzNdkJCT9b8u4ps09vM204RH0OHNUW6U4Iy8xqI%3D&reserved=0>
http://flickr.com/photos/redux/<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fflickr.com%2Fphotos%2Fredux%2F&data=02%7C01%7Cbailey%40access-board.gov%7C8c192a82478340998f0d08d754d64ed5%7Cfc6093f5e55e4f93b2cf26d0822201c9%7C0%7C0%7C637071151738905561&sdata=ZkxeyYC2S%2Bn%2FaE95%2BVqEd1OCP65ZQlUrAbiuUp08RrE%3D&reserved=0> | http://redux.deviantart.com<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fredux.deviantart.com&data=02%7C01%7Cbailey%40access-board.gov%7C8c192a82478340998f0d08d754d64ed5%7Cfc6093f5e55e4f93b2cf26d0822201c9%7C0%7C0%7C637071151738915557&sdata=QeFLF92o%2FPM1hJOd0iOEl3gYdGOsHqDS4mZLwfww8ww%3D&reserved=0>
twitter: @patrick_h_lauke | skype: patrick_h_lauke