RE: 4.1.1 Parsing in WCAG 2.0 and 2.1

Since the documented standards process (Revising a Recommendation: Substantive changes<https://www.w3.org/2021/Process-20211102/#revised-rec-substantive>) does allow for removal in WCAG 2.0 & 2.1 as Alistair states – using the Corrections that do not add new features (a Class 3 change), it seems the most consistent way to go.

However, complications do exist because WCAG 2.0 is adopted verbatim into other standards. To list the ones I’m aware of: GB/T 37668-2019 in China, JIS X 3241-3 in Japan, and ISO/IEC 40500:2012, as well as the EN 301 549 in the EU and its derivatives /or direct adoption by the standards organizations in various countries [KS 2952-1:2022 in Kenya, IS 17802 in India, AUS in Australia].

If we do remove from WCAG 2.0 and 2.1, there would need to be work done to reach out to the standards organizations responsible for maintaining all of these standards to highly recommend they make the same change in their standards.

Best regards,

Mary Jo Mueller
IBM Accessibility Standards Program Manager

From: Wilco Fiers <wilco.fiers@deque.com>
Date: Thursday, March 9, 2023 at 1:20 PM
To: Bradley Montgomery, Rachael L <rmontgomery@loc.gov>
Cc: Alastair Campbell <acampbell@nomensa.com>, WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: [EXTERNAL] Re: 4.1.1 Parsing in WCAG 2.0 and 2.1
Hey Alastair, I do not support a note in WCAG 2. 0 / 2. 1, but removal from WCAG 2. 2. I would support it if that note was put into WCAG 2. 2 instead of removing the SC. On Thu, Mar 9, 2023 at 6: 42 PM Bradley Montgomery, Rachael L <rmontgomery@ loc. gov>
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hey Alastair,
I do not support a note in WCAG 2.0 / 2.1, but removal from WCAG 2.2. I would support it if that note was put into WCAG 2.2 instead of removing the SC.

On Thu, Mar 9, 2023 at 6:42 PM Bradley Montgomery, Rachael L <rmontgomery@loc.gov<mailto:rmontgomery@loc.gov>> wrote:
I prefer Removal but will not object to Adding a Note.

From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Date: Thursday, March 9, 2023 at 12:35 PM
To: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: 4.1.1 Parsing in WCAG 2.0 and 2.1
Resent-From: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Resent-Date: Thursday, March 9, 2023 at 12:34 PM


CAUTION: This email message has been received from an external source. Please use caution when opening attachments, or clicking on links.
Hi everyone,

I wanted to follow up on the process aspect and ask those who +1ed the CFC whether they would object to the alternative below.

The processes for the options are different:

Removal:
If the SC text is removed, or stated as not required, I’m calling this the ‘removal’ approach. I was mistaken on the errata aspect, the removal approach would mean using the “Corrections that do not add new features<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2021%2FProcess-20211102%2F%23class-3&data=05%7C01%7Cacampbell%40nomensa.com%7Cfafc10286f4e48caad1a08db20b27ffb%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C638139723248368224%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oMLAspY%2BQf%2B7y6VzcAzvfELTLUuhmpr%2F6GKKy1eHs7U%3D&reserved=0>” process. It would require a public review (and Patent Review draft), probably of 60 days (although that isn’t specified).

Adding a note:
If the SC is left as a requirement but a note is added, this would be an editorial change. We’d need director approval, but there’s not requirement for public review.

Using a dot-version:
If we made an update and called that WCAG 2.0.1, or 2.1.1, then we’d need to go through the whole publishing process from Working Draft to Rec, which would take months. Also, we’d need to decide whether the default URI (w3.org/TR/WCAG21<http://w3.org/TR/WCAG21>) went to the new version. In which case, would anyone notice the difference in number?

We had considered the ‘adding a note’ approach during the github threads, survey and discussions leading up to the CFC. It had not garnered much support which is why the CFC was not on that option.

If we did take that approach then we’d add a note after the SC text. Working from a previous suggestion<https://github.com/w3c/wcag/pull/2823/files>, that could be:

“NOTE: Modern web technologies have standardized how user agents parse incorrect markup. Any invalid markup is therefore allowed under 4.1.1 Parsing for technologies such as HTML 5 and CSS 3. This success criterion is always satisfied for these technologies.
Issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different success criteria.”

For those people who +1ed the removal approach, would you object to this approach?

Kind regards,

-Alastair

--

@alastc / www.nomensa.com<http://www.nomensa.com>



--
Wilco Fiers
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]