Formal Objections (was: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1)

Hi Wendy,

As I am one person currently suggesting a Formal Objection, let me say that
I do understand your perspective. The problem is, right now, the working
group is offering a binary choice: support the wonks or support the
non-wonks [sic]. It is an unfair choice.

As a counter to the current proposal, I have offered a potential way
forward that I believe supports the needs of both groups, and that is to
"extend" (using the dot extension model) versions 2.0 and 2.1 to 2.0.1 and
2.1.1 versions respectively. I will argue this meets the needs of both
groups more equitably as that too addresses "...for those that do need to
reference 2.0 and 2.1 for conformance or legal reasons, they will
understand that a change has occurred and what it means." - and in a far
cleaner/precise way than what Matt noted as  “WCAG 2.0 (Second Edition)”

(As to depreciation versus obsolete; obsolete suggests "removal", whereas
deprecation suggests "no longer required, but hey, it's still good
practice" - which it is. This distinction can be clarified in the Note
being associated to the proposed change)

When you say "I think it’s important to focus on the needs of our
community" I actually agree - this means (logically) ALSO supporting the
needs of the so-called process wonks (like me) in the community, who care
about both the impact of standards, but how standards themselves are
created and presented. It also means supporting the needs of the
regulators, and of those practitioners who are reliant on translations of
the current Recs, two constituencies I see being left behind with the
current proposal.

And so, if my surfacing the risk of a Formal Objection today is distasteful
to some at this time, I'll roll that back to "This is a decision I CANNOT
live with".
I believe at the end of the day it amounts to essentially the same thing.

JF

On Thu, Mar 9, 2023 at 11:46 AM Reid, Wendy <wendy.reid@rakuten.com> wrote:

> +1
>
>
>
> I do want to explain this and I hope it might offer some clarity to those
> in opposition or on the fence on this.
>
>
>
> There is two ways to look at this change. One is from a strictly
> standards/process point of view. From that point of view, a more
> appropriate approach would be to leave 2.0 and 2.1 alone and mark 4.1.1 as
> deprecated in 2.2. It’s the most adherent to how standards are built, and
> for the standards wonks is the clearest communication of the change. The
> standards approach may accommodate an editorial note on previous versions
> at most.
>
>
>
> The other point of view, and the one I am taking, is what would be most
> beneficial for the community at large, which includes far more people who
> are not standards wonks. That audience of people may or may not know what
> “deprecated” even means, or at least not in the context of standards. For
> this constituency, the proposed approach is much clearer, as it not only
> allows someone to read 2.2 and learn exactly what they need to know about
> WCAG, but for those that do need to reference 2.0 and 2.1 for conformance
> or legal reasons, they will understand that a change has occurred and what
> it means.
>
>
>
> I understand the desire for precision, and I can be a standards wonk
> myself at the best of times, but I think it’s important to focus on the
> needs of our community over adhering to process for the sake of it. I
> understand how fraught this is, as someone who works on another
> specification with incredibly strict backwards compatibility requirements
> it is not easy to make these decisions and communicate them effectively.
>
>
>
> On a personal note, the throwing around of threats to formally object to
> this change on what appears to solely be process grounds is in poor taste,
> and I really ask that those who are making those threats consider the
> impact that has on the culture and tone of this group. We all care very
> strongly about the quality of this document and its impact on our community
> and the disability community at large, don’t make this harder than it needs
> to be.
>
>
>
> Cheers,
>
> Wendy
>
>
>
> *From: *John Foliot <john@foliot.ca>
> *Date: *Thursday, March 9, 2023 at 8:56 AM
> *To: *Hakkinen, Mark T <mhakkinen@ets.org>
> *Cc: *John Foliot <john@foliot.ca>, Alastair Campbell <
> acampbell@nomensa.com>, WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject: *Re: [EXTERNAL] Re: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1
>
> *[EXTERNAL] *This message comes from an external organization.
>
> Mark writes:
>
> >  The concern is adequately addressed by deprecating (which I agree is
> the correct approach) in the latest, and member approved, specification.
>
> +1. Mark is 100% correct, the proper way forward is deprecation, and not
> making the SC obsolete. This is indeed a well worn and common path for
> other W3C Recommendations.
>
> Off list, it has been suggested to me that this proposed change will not
> have an impact on Section 508 or EN 301 549. It is important to remember
> however that while those two legislations do drive a significant amount of
> compliance behaviour, they are not the only external dependencies on WCAG
> 2.0/2.1 (ref: https://www.w3.org/WAI/policies/). Have any of these other
> legislated requirements been queried to see what (if any) impact this
> proposed change might have to those other dependencies?
>
> Additionally, what will the impact be on officially translated versions of
> the Recommendation? (
> https://www.w3.org/WAI/standards-guidelines/wcag/translations/) Having an
> English version of WCAG 2.0 that does not align with the Polish Version
> <https://www.w3.org/Translations/WCAG21-pl/> (for example) very much
> feels like a problem simply waiting to happen.
>
> What I do not see is a proposal for publishing a WCAG 2.0.1 / WCAG 2.1.1,
> which I will argue both addresses the needs and concerns around this SC in
> previously published versions of the Recommendation, while at the same time
> having a minimal impact on previously published versions of the Rec. The
> 'dot-extension' mechanism is flexible enough to accommodate this way
> forward, and it effectively and unambiguously delineates the two versions
> of either WCAG 2.0 or WCAG 2.1
>
>
> I remain adamant however that I WILL file a Formal Objection if this
> Working Group continues to proceed with "overwriting" an existing
> Recommendation.
>
> Respectfully,
>
>
>
> JF
>
>
>
>
>
> On Wed, Mar 8, 2023 at 9:44 PM Hakkinen, Mark T <mhakkinen@ets.org> wrote:
>
> Agreeing with John and Chaals.
>
>
>
> Is there any precedent within W3C for changing an existing, versioned and
> published recommendation, agreed to previously in time by W3C membership?
> Is it an errata? Don’t think so.  The concern is adequately addressed by
> deprecating (which I agree is the correct approach) in the latest, and
> member approved, specification.  SC 4.1.1 appeared relevant to us at the
> time, it was approved, and remains part of WCAG’s history.  Deprecate and
> move on in subsequent versions.
>
>
>
> Mark
>
>
>
> *From: *John Foliot <john@foliot.ca>
> *Date: *Wednesday, March 8, 2023 at 3:20 PM
> *To: *Siegman, Tzviya <tsiegman@wiley.com>
> *Cc: *Alastair Campbell <acampbell@nomensa.com>, WCAG list (
> w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject: *[EXTERNAL] Re: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1
>
> *CAUTION: This email originated from outside of our organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.*
>
> Like Chaals, I'm also likely to make a Formal Objection to substantively
> changing a previously published W3C Recommendation. That is why we went
> with the dot extension model: 2.2 WILL BE different than 2.1 just as 2.1
> was different than 2.0. Whether we like it or not, changing any of the WCAG
> versions after they have reached Rec Status may very well have knock-on
> impacts to legislated requirements around the world, and could have a
> detrimental (negative) reflection on the W3C writ large.
>
>
>
> Despite Wilco's flawed argument, if you are conformant today to ALL of the
> WCAG 2.1 SC, then the path to meeting 2.2 conformance is to simply meet the
> new SC requirements (putting aside whether you previously did or did not
> meet 4.1.1).
>
>
> I also struggle with invoking the term "Obsolete", and would much prefer
> to see "Deprecated" - the nuance is subtle but distinct.
>
> JF
>
>
>
> On Wed, Mar 8, 2023 at 3:01 PM Siegman, Tzviya <tsiegman@wiley.com> wrote:
>
> +1
>
>
>
> *Tzviya Siegman*
>
> Information Standards Principal
>
> Wiley
>
> 201-748-6884
>
> tsiegman@wiley.com
>
>
>
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Wednesday, March 8, 2023 12:59 PM
> *To:* WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject:* CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1
> *Importance:* High
>
>
>
> ⛔
>
> This is an external email.
>
> Call For Consensus — ends Friday Wed 15th at midday Boston time.
>
>
>
> The group has discussed what to do with 4.1.1 Parsing in WCAG 2.0 & 2.1
> now that it has been removed from WCAG 2.2.
>
>
>
> From the discussion:
>
> https://www.w3.org/2023/03/07-ag-minutes#item10
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.w3.org%2F2023%2F03%2F07-ag-minutes*item10__%3BIw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmfez9VGJw%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BpgSNsLNWoan0MMpMhykdOtKiwpi%2BZ%2FO0d1HFjiyvyE%3D&reserved=0>
>
>
>
> Following the same approach as WCAG 2.2 was the preferred approach, where
> the SC text would be removed and replaced with a note that says why it has
> been removed.
>
>
>
> The specific changes are detailed in these two pull requests:
>
> https://github.com/w3c/wcag/pull/3093
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2Fw3c%2Fwcag%2Fpull%2F3093__%3B!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmdMiSXedg%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dc3IcVKEtDoNcN3Qrmn7UZGAw1NH2r628%2FGJSrnuHSk%3D&reserved=0>
>
>
> https://github.com/w3c/wcag/pull/3094
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2Fw3c%2Fwcag%2Fpull%2F3094__%3B!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmcNvvv_-g%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uRxuptZeSVTF%2BSi5ANWPNTAH6JDNcgP4Wl8svIbIBAI%3D&reserved=0>
>
>
>
> Survey results:
> https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq23
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F35422%2Fwcag22-misc5%2Fresults*xq23__%3BIw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmewMpiCqg%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=R6V9q0sWNGbw0IWJITDyGWlKLO6tYxuolpmiiBkx99s%3D&reserved=0>
>
>
>
>
> If you have concerns about this proposed consensus position that have not
> been discussed already and feel that those concerns result in you “not
> being able to live with” this decision, please let the group know before
> the CfC deadline.
>
>
>
> Assuming the group agrees to this change, there is likely to be a public
> review before we can re-publish WCAG 2.0 & 2.1.
>
> https://www.w3.org/2021/Process-20211102/#last-call-review
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.w3.org%2F2021%2FProcess-20211102%2F*last-call-review__%3BIw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmcpGrAkRg%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mjWLAtijjUxjfswpSIZbcwgsdFrKfUhVRZ7XOr7AR%2Bo%3D&reserved=0>
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
> --
>
>
>
> @alastc / www.nomensa.com
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.nomensa.com__%3B!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmfGTPcEDg%24&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8MisvXGtatsJL9voEZFfcnztYchSFEop7St19rZEGj4%3D&reserved=0>
> ------------------------------
>
> The contents of this email and any attachments are confidential and
> intended only for the person or entity to whom it is addressed. If you are
> not the intended recipient, any use, review, distribution, reproduction or
> any action taken in reliance upon this message is strictly prohibited. If
> you received this message in error, please immediately notify the sender
> and permanently delete all copies of the email and any attachments.
> Click here for translations of this disclaimer.
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.wiley.com%2Femail-disclaimers&data=05%7C01%7Cmhakkinen%40ets.org%7C8293865bc300409a8d3b08db201297f8%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C638139036468432882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=edTrghDOjweQNT2Lt7BYF0khbYofSMyNPyetmPx8CTI%3D&reserved=0>
> ------------------------------
>
>
>
>
> --
>
> *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"
>
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
>
>
> Thank you for your compliance.
> ------------------------------
>
>
>
>
> --
>
> *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"