Re: SC 4.1.1 and WCAG 2.0

Normatively, 2.0 and 2.1 (without any errata) already contain a clause
"...except where the specifications allow these features." The note that we
added (in errata in 2.0, and in republishing 2.1) clarifies our position
that we interpret the *existing* normative language as *already* not
requiring testing of 4.1.1 for HTML content.

On Wed, Oct 18, 2023 at 1:28 PM Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> so *normatively* 2.0 and 2.1 still require actual testing of 4.1.1?
>
> On 18 Oct 2023, at 11:50, Kevin White <kevin@w3.org> wrote:
>
> Hi Patrick and Jon,
>
> Trying to address the points you have raised.
>
> The errata statement has meaning in as much as these would be considered
> mistakes that are intended to be addressed in future publications of the
> Recommendation. Ideally WCAG 2.0 would have been republished in the same
> way that 2.1 was. As Alastair points out, there are some significant
> challenges to this hence using the errata.
>
> In the case of 4.1.1, however, the addition of the note in 2.1 is
> non-normative and the 2.0 errata flags the change as an editorial change to
> a non-normative aspect of the Recommendation. Based on this 2.1 and 2.0 are
> effectively the same in terms of clarifying the status of 4.1.1.
>
> Thanks
>
> Kevin
>
> On 18 Oct 2023, at 02:38, Patrick H. Lauke <redux@splintered.co.uk> wrote:
>
> So I'm confused now ... does this sentence right at the top of WCAG 2.0
> have no actual relevance/meaning then?
>
> "Please refer to the *errata* <http://www.w3.org/WAI/WCAG20/errata/> for
> this document, which may include normative corrections."
>
> P
>
> On 17 Oct 2023, at 14:17, Chaals Nevile <charles.nevile@consensys.net>
> wrote:
>
> 
> There was a substantial amount of discussion about how the change would
> affect backwards compatibility. The group did reach consensus that
> insisting on meeting 4.1.1 wasn't helpful, but failed to reach consensus on
> stating clearly that there is a technical incompatilibity - you can meet
> 2.2 without meeting 2.0 by not fulfilling the 2.0 requirements of SC 4.1.1
> - even though the real world impact on accessibility is no longer relevant.
>
> The reason we believe it makes no concrete difference is because for about
> a decade we have had standard handling for whatever code you find, widely
> deployed and part of normal tooling.
>
> Technically speaking, unless we change WCAG 2.0, some people might
> continue to insist on what amounts to a useful basic quality process as if
> it were the real problem it used to be of not being able to predict how
> content would be presented.
>
> I suggest, our guidance should be "if you're still stuck on the WCAG 2.0
> spec (despite a valuable replacement being publish 5 years ago, with its
> replacement in turn available now, you should probably stop insisting that
> you harm accessibility unless you meet 4.1.1. It's not bad to meet the
> requirement, it's just no longer an accessibility issue if you don't".
>
> Formally updating WCAG 2.0 to note that the requirement can be considered
> as met, since browsers now fix the problem, or some such procedure, would
> be vaguely useful. Understanding the difference in uncertainty between "we
> changed stuff between last week and this week", and "things have changed
> over the 18 years since WCAG 2.0 was published" is important - regulators
> need guidance that includes recognising that rulemaking like it's 1999 can
> be counter-productive when conditions fundamentally change.
>
> cheers
>
> On Tuesday, October 17, 2023 19:52:39 (+02:00), Jon Avila wrote:
>
> Based on Chaals feedback, that the errata have no official standing for
> 2.0 then it would seem that WCAG 2.2 is no longer backwards compatible?
> This is something that I don't think was clearly communicated when we
> discussed this previously in the working group meetings.
>
>
> Regulators and the industry need clear, specific, and consistent guidance
> on treatment of this as without it people will be held to different
> standards which causes confusion.
>
>
> Jonathan
>
>
> -----Original Message-----
>
> From: Chaals Nevile <charles.nevile@consensys.net>
>
> Sent: Tuesday, October 17, 2023 11:26 AM
>
> To: Alastair Campbell <acampbell@nomensa.com>; Mary Jo Mueller <
> maryjom@us.ibm.com>; Patrick H. Lauke <redux@splintered.co.uk>; WCAG <
> w3c-wai-gl@w3.org>
>
> Subject: Re: SC 4.1.1 and WCAG 2.0
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Alistair wrote
>
>
> "Where we re-publish a spec (like 2.1 recently) the errata will then
> appear on the face of the spec, but technically they apply even when that
> isn’t the case."
>
>
> I don't think that's quite true.
>
>
> The W3C Recommendation is the published document. Republishing updates
> that to incorporate errata. Until then, the errata are a working group note
> saying what they got wrong. Or perhaps just what some people think is wrong
> - there's no specific requirement on errata because they have no official
> standing.
>
>
> Publishing updates to Recommendations for errata isn't typically a massive
> amount of work, although it isn't done that often.
>
>
> cheers
>
>
> Chaals
>
>
> On Wednesday, October 11, 2023 00:32:37 (+02:00), Alastair Campbell wrote:
>
>
> Hi Patrick,
>
>
> Mary-Jo is obviously best placed to talk about the ACRs, on the spec side:
>
>
> Was it because we couldn't spin up an update/republication of 2.0.
>
>
> Essentially yes, it is theoretically possible to update but it would
> involve a huge amount of work.
>
>
>
> If so, does the mention in the errata supersede the main spec text
>
>
> Yes, in effect you have to imagine the errata are in place in the main
> spec.
>
>
> Where we re-publish a spec (like 2.1 recently) the errata will then appear
> on the face of the spec, but technically they apply even when that isn’t
> the case.
>
>
> Kind regards,
>
>
> -Alastair
>
>
> --
>
>
> @alastc / www.nomensa.com<http://www.nomensa.com/>
>
>
>
>
>
>
> --
>
> Charles 'Chaals' Nevile
>
> Lead Standards Architect, ConsenSys Inc
>
>
>
>
> --
> Charles 'Chaals' Nevile
> Lead Standards Architect, ConsenSys Inc
>
>
>