RE: Removing 4.1.1

I agree with Shadi and Alastair: Choosing to drop the requirement from the current version is different from messing with past versions.


If our versioning strategy is clear and stable - we provide versions, the latest editors' draft is available, we clearly delineate changes made between versions (including when they are in a relatively unstable Editors' Draft) then we enable the world at large (about 200 countries, many of which actually include multiple jurisdictions that overlap in weird and wonderful ways, not to mention vastly more corporate/organisational policies...) to build on our work.


If we change expectations of what a Recommendation means, we are impacting policies we have never seen, let alone understood. We might well be solving a problem for 30-odd countries we know fairly well, but doing it through an ad hoc alteration to specifications that were published and declared to be stable years ago means a vast number of users can no longer rely on how we describe a version, which IMHO does a disservice to our community.


If we believe people should not be relying on an older version of a specification, then the solution is to tell them why, rather than to change it under them. In many cases that would not solve the problem we're trying to address, while it does introduce new problems.


I would support an editorial annotation being added to specifications (how sad that browsers don't support a standard system of annotations, after a quarter-century of working on it specifically for browsers).

I also think it is very important to implement Shadi's suggestion to keep the reference link working (i.e. the #fragmentId bit) and pointing to some explanation of the fact that 4.1.1 was removed, and it would be good to have an explanation of why.

cheers

On Wednesday, 21 December 2022 15:08:50 (+01:00), Abou-Zahra, Shadi wrote:



Hi Wilco, all,

 

Looks like we’re all in agreement to “drop 4.1.1 in some way”, the disagreement seems to be on how. I’m not sure what your proposal is?

 

I personally like Alastair’s proposal of separating out our thoughts for dropping 4.1.1 from WCAG 2.2 and from prior versions of WCAG:

https://github.com/w3c/wcag/issues/2820#issuecomment-1342709648

 

I think that most normative references to WCAG 2.x use a dated version of the spec. For example, EN 301 549, ISO 40500, and the technical standards for Section 508 refer to the specific publication dates of WCAG 2.0 and/or WCAG 2.1. I don’t think these technical standards, therefore any of the policies that refer to these technical standards, are immediately impacted regardless what we do in updates and republications of the spec. I think republishing WCAG 2.0 and WCAG 2.1 with a clear note added to the current SC text and title, and with further explanation in the Understanding documents is the clearest way forward – it maintains continuity and transparency, as well as guidance for people who need to continue using WCAG 2.0 and WCAG 2.1. Not doing this would be irresponsible in my view, as it would mislead thousands of content and tool developers to do completely unnecessary work.

 

As to WCAG 2.2, I can’t think of any good reason to keep the current SC text. I think the SC text should be removed from WCAG 2.2 but the document structure should still have the item 4.1.1 with an updated SC title (i.e. with a clear marker like “obsolete”, “removed”, or “rescinded”), and a clear note that refers to the Understanding documents for further background.

 

Best,

  Shadi

 

---

Shadi Abou-Zahra

Amazon Devices and Services

Principal Accessibility Standards and Policy Manager

---

 

 

From: Wilco Fiers <wilco.fiers@deque.com>
Sent: Tuesday, 13 December, 2022 11:26 PM
To: Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: RE: [EXTERNAL]Removing 4.1.1

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

Hey folks,

I am concerned with the direction the AGWG chairs are taking this. This would have been a fantastic thing for AGWG to work on two years ago. But to start this work now, with so little time left for us to figure out how to do this right, and when we're already in the extension period of our charter, I think it's inappropriate.

I feel that something this significant deserves to be handled with a lot of care and forethought. For example, what are even the requirements for publishing an amended WCAG 2.0 and 2.1. It's never been done. Does it need to go through formal approval? I bet someone knows, but nobody on the call today did.

Then there is bigger stuff, like what does this mean for WCAG's ISO standard. Can that be updated? What's the process for that? If it can be done, who would need to approve such a thing, and will they? Can we do it with this W3C legal entity thing going on? What about other standards like EN 301 549? Can they, and if so will they adopt a similar change? What about policy and legislation? What about WCAG 2 translations, will those be updated, or is Germany just going to keep using 4.1.1 because it was never removed from their translation? What about test methodologies like Trusted Tester and RGGA? How long will all of these things be in disagreement while they're sorting out this update?

I'm sure this stuff can all be figured out, but we should have the answers before we make the change. We can't just throw out this curve ball and hope for the best. Please understand that I want to see 4.1.1 be dropped in some way. But we have a responsibility to coordinate and communicate about these things. We haven't done that, and we don't have time for it anymore.

 

 

On Tue, Dec 13, 2022 at 7:42 PM Alastair Campbell <acampbell@nomensa.com> wrote:

Hi everyone,

 

In the discussion today we decided (again) to remove 4.1.1 from WCAG 2.2 and include a note.

 

We also got towards agreeing to do the same in WCAG 2.0 and 2.1. That would involve creating an errata, then re-publishing the specs to include the errata.

 

Areas of agreement:

We don't want people to be required to test or report on 4.1.1.
Any issues that impact end-users that are caught by other SC, so a fully conforming 2.2 site would conform to 2.1/2.0 for those meaningful issues (even if it still included 4.1.1).

 

The rest of the discussion was how to implement it.

 

Looking at the current editor’s draft, it would be like this:

https://w3c.github.io/wcag/guidelines/22/#parsing

 

But with an additional note. Gregg suggested:

“NOTE: This was originally adopted to address problems that Assistive Technology had directly parsing HTML. This is no longer true so this criterion no longer solves that problem and is removed.”

That is in https://github.com/w3c/wcag/pull/2840/files

 

There is also a section at the top of the understanding document explaining the rationale. https://w3c.github.io/wcag/understanding/parsing.html

(I need to work out how to get the old SC text to appear on the understanding doc, remove the “new in wcag 2.2” bit, and add the mapping table.)

 

So the question for 2.0/2.1 is whether to do exactly the same thing?

 

Pertinent comments from the meeting included:

Removing it from early specs feels like re-writing history.
Keeping them consistent means that you maintain inter-version compatibility.
Keeping the SC text in allows the worst aspects of 4.1.1 to continue (e.g. drive-by legal threats).
We could maintain the SC text and add a note saying (strongly) not to report on obsolete SCs.
Regulations tend to use specific dates of a standard, so it doesn’t change regulations until they decide to do so.

 

Do you have any different arguments for/against removing 4.1.1 from 2.1/2.0?

 

Kind regards,

 

-Alastair

 

-- 

 

@alastc / www.nomensa.com

 

 

 




 

--

Wilco Fiers

Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force

 




Amazon Development Center Austria GmbH
Brueckenkopfgasse 1
8020 Graz
Oesterreich
Sitz in Graz
Firmenbuchnummer: FN 439453 f
Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz




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