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

I pointed out that I would probably object as an AC rep to "changing WCAG 2.0 and 2.1". Below I'll discuss a couple of ways forward I see that would resolve my objections, followed by an explanation of why I would object (I'm not sure that I have explained that clearly. If I have, please just skip the repeat...).


I am opposed to, but could live with, the suggestion that we make a 2.01 and a 2.11 version (or something along those lines) without the relevant SC, if (and only if) it included an explanation of what the SC was, and why it was removed.


I am neutral about leaving 2.0 and 2.1 alone - especially 2.0: I would prefer to explicitly follow the obsoleting process for that specification.


I support adding a note to a revision of those specifications (and especially the understanding and techniques docs) pointing out that effectively 4.1.1 is now met UNLESS you are aiming at some historically interesting but mostly no longer available technology (based on decade-old browsers at the time of writing). This doesn't change the SC at all, it merely explains it in context, and is therefore a "non-substantive", or editorial change.


Perhaps incidentally, I am opposed to continuing to maintain the idea that that WCAG 2.2-conformant content must be conformant to WCAG 2.0. Because I believe that 4.1.1 is effectively satisfied for all content in most circumstances anyway, that's not strictly relevant to this SC, although it might be relevant to the principles that inform the discussion. It is also the case that the group has historically said that's a key underpinning of its work, and it would be inappropriate to drop that without rechartering, to permit the W3C community to discuss that more broadly and make a conscious decision. Even if that would feel like this discussion. :S


Why I object to changing the old specs:


W3C has a long history of publishing specifications as Recommendations, that are specific versions, and then not changing them, but if desirable producing a new version. That's why we have WCAG 1.0, WCAG 2.0, WCAG 2.1, etc.


If someone writes a purchase order against a specific version of a W3C Recommendation, to take a scenario Gregg outlined, they do so with reasonable grounds to believe that it won't change, because W3C has said that is true for near 30 years. The way it is implemented might change (there weren't javascript PNG editing packages when the PNG Recommendation was released), but what the spec says you need to do is still the same (unless you want to use a newer version).


W3C now has a procedure to say, e.g. "WCAG 2.0 is obsolete". (15 years after publication, that seems to generate more controversy as a proposal than I understand, but I realise the world moves at variable speeds). We can also say "it is superseded by WCAG 2.1" - but we have chosen so far not to do so.

For what it is worth (probably very little), I would be in favour of saying WCAG 2.0 is superseded, but that's not the core argument. What it seems people are proposing is that we edit WCAG 2.0, trying to say "this bit is superseded, but the other outdated stuff such as missing requirements isn't". 


That's not standards "wonkery". It's providing a way to weasel out of one bit of work (checking that code meets basic quality standards) that isn't necessary for accessibility any more, while also weaseling out of the new work that 2.1 and 2.2 mandate - even though we realised it was important to actually make content accessible and put it into the new versions of WCAG.


And if the proposal to do so breaks W3C's core promise about versions of Recommendations then that's what doesn't work for me. Because it affects not just WCAG, but all W3C's Recommendations for all groups.


cheers


Chaals

On Thursday, 9 March 2023 18:18:06 (+01:00), John Foliot wrote:


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 (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

 

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://github.com/w3c/wcag/pull/3094

 

Survey results: https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq23 

 

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

 

Kind regards,

 

-Alastair

 

-- 

 

@alastc / www.nomensa.com

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.




 

--

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"

-- 
Charles 'Chaals' Nevile
Lead Standards Architect, ConsenSys Inc