RE: 4.1.1 Parsing in WCAG 2.0 and 2.1

Leaving the requirement as is, but noting as an updated editorial comment that the group has determined it is no longer strictly necessary for the purpose it was designed to serve was in the survey.


Doing so would almost certainly remove my objection. It's still a good practice. I'd object to something that gives the impression that we consider it's a bad idea to write code that's actually correct.

cheers


Chaals

On Thursday, 9 March 2023 10:31:32 (+01:00), Abou-Zahra, Shadi wrote:



Hi Alastair,

 

Do you know the level of support or objections to the option “We try to compromise by not removing the SC text, but including a note that says it is not required anymore”? It seems to address all requirements.

 

Best,

  Shadi

 

---

Shadi Abou-Zahra

Amazon Devices and Services

Principal Accessibility Standards and Policy Manager

---

 

 

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Thursday, 9 March, 2023 10:14 AM
To: Chaals Nevile <charles.nevile@consensys.net>; WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: RE: [EXTERNAL]4.1.1 Parsing in WCAG 2.0 and 2.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.

 

Hi Charles,

 

(Taking this off the CFC thread.)

 

Wilco’s response in the survey was just one of the arguments, there have been others during previous discussions. I’ll try and gather those here:

 

The SC is being actively abused now (e.g. drive-by validation), and causes the most wasted work of all the SCs. Changing only WCAG 2.2 doesn’t help with that.
Removing the SC doesn’t change the underlying accessibility requirements. We’ve mapped those to other WCAG 2.0 SCs. (And that’s a useful understanding doc addition we can make).
There has been wide misinterpretation of the SC’s intent. If we don’t remove it, we should update the understanding document (potentially the SC text via errata) to clarify that, and people will realise it now achieves nothing except ‘busy work’.
If we don’t make this change to WCAG 2.0 and 2.1, we will have objections to removing it from WCAG 2.2. (That is one, I’m aware of another potential member objection.)
Some organisations are already ignoring the SC now, requiring customers/clients to justify changes based on user-impact rather than lack of conformance.
For most people, it is simply less to do. Even from folks involved in regulations, their reaction has been (paraphrasing): People building/testing to 2.0 may continue to do something they don’t need to, people checking will be pleasantly surprised there is one less thing to do.

 

Chair-hat off to add my own observation: 

There is a difference between WCAG and other W3C specs: If people stop using a CSS feature, it doesn’t particularly matter if it is still included in the spec, it doesn’t create work for authors. If a defunct SC remains in a spec, it creates work for thousands (millions?) of authors and testers around the world. 

If we had an accessibility priority of constituencies, I think we’d put that work over spec purity.

 

Chair-hat on to look at ways forward, I can see several paths:

This CFC passes;
We try to compromise by not removing the SC text, but including a note that says it is not required anymore.
We don’t align it with 2.2 but update it to make clear it doesn’t include the ‘content model’.

 

Kind regards,

 

-Alastair

 

 

From: Chaals Nevile

This isn't really a new argument. It is about procedure and W3C process, not the technical merits (which I don't think are in much dispute).

 

I'm likely to object, including as an AC rep making a formal objection to substantively changing a previously published versioned recommendation.

Wilco's reasoning, that doing so makes WCAG 2.2 compatible with WCAG 2.0/2.1 fails to convince me. What it does do is mean that earlier claims of non-conformance to WCAG 2.0 or 2.1 are no longer valid.

 

It also means that any organisation who are using WCAG 2.0/2.1 now, for whatever reason, need to understand that the promise underpinning a W3C Recommendation is being broken. That seems a far more serious issue than removing he promise that WCAG 2.2 will be backwards compatible, and one that affects every W3C Recommendation and so most W3C Working Groups.

 

I am unlikely to decide I "can live with" this. If you want an HTML-style specification that changes when you feel like it, then make one, instead of a W3C Recommendation.

 

cheers

 

Chaals

On Wednesday, 8 March 2023 18:58:40 (+01:00), Alastair Campbell wrote:

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


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




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

Received on Thursday, 9 March 2023 09:56:02 UTC