Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

Hi Andrew,

Thinking about this more, there is a subtle but distinct difference between
updating a "Previous Version", and what this proposal is seeking, which is
both an update (for those that choose to adopt it), but is more accurately
a fork, as both versions may be normatively referenced or pointed-to by
external resources.

For many organizations, they may elect to either adopt 2.1.1 or 2.0.1 as an
internal formal decision (to address the drive-by abuses/busy work issue):
what impact that has on their legal obligations will be for them and their
lawyers to assess.

But some orgs may still require meeting SC 4.1.1 either due to legal
obligations or internal policy decisions - so 2.0.1/2.1.1 cannot simply
"replace" 2.0/2.1, but rather stand beside those previous versions. I would
be opposed to somehow suggesting that 2.0 (2008) has no value because it
was replaced by 2.0 (2023), because it is simply not true. In many ways,
this is why 2.0 remains a valid Recommendation alongside of 2.1 (and soon,
2.2) - we've not obsoleted or retired any of the 2.x family of specs, they
all stand on their own merit. Making a normative change to 2.0 and 2.1
should conceptually be treated the same way in my opinion.

As for time-stamping alone (which is what Section 508 has done) - I
personally think that is an inelegant solution to the question, but I also
understand why they chose to do so - to avoid exactly the problem the
proposal of updating a Recommendation but leaving the "normative name" the
same introduces. I just think we can do better than that.

JF

On Fri, Mar 10, 2023 at 11:31 AM Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> A link to a previous version doesn’t need to indicate that it is outdated.
> That is done in the previous link in WCAG 2.0 today because the previous
> version (which is the PR version) is outdated.
>
>
>
> Also, even if the WG indicated that WCAG 2.0 from Dec 2008 was outdated,
> does that matter? If Section 508 uses that version, it is still published
> on the site. We would want people to know that there is a more current
> version, so this type of message isn’t affecting any ability to use the
> standard, just indicating that it isn’t the most current.
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Director, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
>
>
>
>
> *From: *John Foliot <john@foliot.ca>
> *Date: *Friday, March 10, 2023 at 11:16 AM
> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>
> *Cc: *John Foliot <john@foliot.ca>, Alastair Campbell <
> acampbell@nomensa.com>, WCAG <w3c-wai-gl@w3.org>, WAI-IG <
> w3c-wai-ig@w3.org>
> *Subject: *Re: 4.1.1 Parsing in WCAG 2.0 and 2.1
>
>
>
> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>
>
>
> Andrew,
>
>
>
> > https://www.w3.org/TR/WCAG20/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG20%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842556460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mAWllVA3LhrlJ2QBZBcGgv6%2BLJMJFMk35LVGjFmmavc%3D&reserved=0> is
> just a pointer to the most recent version.
>
>
>
> Sure, but for some (many?) the "most recent version" is not the one they
> would be held accountable to. It's not just "the most recent", it is also a
> *different* version. Currently, when you go to
> https://www.w3.org/TR/WCAG20/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG20%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842556460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mAWllVA3LhrlJ2QBZBcGgv6%2BLJMJFMk35LVGjFmmavc%3D&reserved=0>
> and then follow the link to Previous version:
> http://www.w3.org/TR/2008/PR-WCAG20-20081103/
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FTR%2F2008%2FPR-WCAG20-20081103%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842712692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=f4oWbhx1TR3X%2BP%2F4UyNi2UhcHvHpvOgvF8dtoRpn%2BtY%3D&reserved=0>,
> users are advised that "This version is outdated".
>
>
>
>
> (screen capture of the current warning message outputted)
>
>
>
> We cannot (I assert) say that to a normative modification to 2.0/2.1
> because the versions that still include the requirement to meet 4.1.1
> cannot be *outdated* due to the knock-on impact I previously noted: the
> known list of Policies
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2Fpolicies%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842712692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VTfMah2lfeaIzCYbdqJPM7C1mbrhlY9ePqa91%2BGvOlA%3D&reserved=0> (above
> and beyond 508 / EN) potentially impacted, the list of official W3C
> translations
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2Fstandards-guidelines%2Fwcag%2Ftranslations%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842712692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b6ffhLtT9SDqlYEb90PQvDU5CmMNvCFknXEogMhRSYY%3D&reserved=0> of
> either of those versions of WCAG, as well as noting the likely references
> in external policies, print publications, and tooling.
>
>
>
> For this reason, I assert that normative changes to 2.0 and 2.1 are
> creating NEW Recommendations after the fact. We can *encourage*
> organizations to adopt and use the New versions, but because we alone
> cannot compel them to do so, we must leave both options available as fully
> articulated and VALID Recommendations (even if we know that one version is
> "bad") - it's not either / or, its 'both' - simultaneously.
>
>
> JF
>
>
>
> On Fri, Mar 10, 2023 at 10:13 AM Andrew Kirkpatrick <akirkpat@adobe.com>
> wrote:
>
> Just one point to add, John:
>
>
>
> This particular question is actually at the root of my current concern and
> "CANNOT LIVE WITH" stance; If we "republish" 2.0 / 2.1 with normative
> changes, then it is no longer .../TR/WCAG20 or .../TR/WCAG21, the revisions
> are normatively different (and thus, I propose .../TR/WCAG201 &
> .../TR/WCAG211 respectively).
>
>
>
> As I’m sure you know but will point out for others, the official URI for
> WCAG 2.0 is http://www.w3.org/TR/2008/REC-WCAG20-20081211/
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FTR%2F2008%2FREC-WCAG20-20081211%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842712692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Zef713FN3gB3D9%2Fd4tK9RkRc5FFcgyXF2HLBZCziP64%3D&reserved=0>
> and https://www.w3.org/TR/WCAG20/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG20%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842712692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BZc9UWq5ugQxH7bfa2O9mc%2FP0%2BkvadON2cGcUsuLg%2BI%3D&reserved=0>
> is just a pointer to the most recent version. Similarly for
> https://www.w3.org/TR/2018/REC-WCAG21-20180605/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2018%2FREC-WCAG21-20180605%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842712692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o%2BB44xeeF7DXoZcKJOZYScTVcnDlR1Wmy%2FjbkppZEw8%3D&reserved=0>
> and https://www.w3.org/TR/WCAG21/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842712692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lPqv%2FkwXZLtWEICI7Fus1VsHeql3S8mrFCOa%2BnmD6B0%3D&reserved=0>.
> So there definitely would be a different date version, but the group would
> need to decide about using the existing pointer or not.
>
>
>
> Now, as one example, Section 508 references WCAG using the pointer URI,
> but clarifies that it is the Dec 11 2008 version (see
> https://www.access-board.gov/ict/#702.10.1
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.access-board.gov%2Fict%2F%23702.10.1&data=05%7C01%7Cakirkpat%40adobe.com%7Cc7da9eb4e1d54492100b08db2182c96b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140617842712692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tCucUSRVYdh6fOSfvW63SoQfyrQ1pwQVay5BiKKVKj8%3D&reserved=0>
> ).
>
>
>
> AWK
>
>
>
>
> --
>
> *John Foliot* |
> Senior Industry Specialist, Digital Accessibility |
> W3C Accessibility Standards Contributor |
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>


-- 
*John Foliot* |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"