Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

Completely agree with Gregg’s post a minute ago on this topic in the CFC version of this thread.

I’m finding this thread hard to follow – the WG agreed that we would remove 4.1.1 from WCAG 2.2 in a CFC and it seems like we are rehashing some of the same concerns that were raised and discussed in the context of that decision.

The problem with a note is that it is non-normative, so really doesn’t change anything. If WCAG 2.1 and 2.0 had a note, that is marginally better than doing nothing in that is sends the message what the WG opinion is but doesn’t have as much benefit as a revision (whether as a WCAG 2.0.1 or WCAG 2.0 but with a different date).

The removal won’t change anything for those who need to meet Section 508 or the EN, so tool makers will likely need to have a different setting for customers who need to do so. Which makes me wonder what real benefit marking WCAG 2.0/2.1 brings to axe or Accessibility Insights.

So, I’d rather do an revised version (which would allow us to FINALLY incorporate the editorial errata into WCAG 2.0 and WCAG 2.1 also), but I can live with any of these as long as WCAG 2.2 removes 4.1.1.

Thanks,
AWK

Andrew Kirkpatrick
Director, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk



From: Jon Avila <jon.avila@levelaccess.com>
Date: Thursday, March 9, 2023 at 4:13 PM
To: WCAG <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>
Resent-Date: Thursday, March 9, 2023 at 4:12 PM


EXTERNAL: Use caution when clicking on links or opening attachments.


I perceive the note is essentially saying that the SC 4.1.1 is met by accessibility supported implementations in modern browsers.  We could then create an HTML technique that shows when combined with a modern browser and assistive technology it is met even when the source code has some of the items mentioned in SC 4.1.1.

Jonathan

From: Gregg Vanderheiden <gregg@vanderheiden.us>
Sent: Thursday, March 9, 2023 2:24 PM
To: Alastair Campbell <acampbell@nomensa.com>
Cc: w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>
Subject: Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

Hmmm

That note is kind of confusing and unclear what it means.

I still think the clearest thing is to proceed as proposed earlier and remove it with a note.

But if all we can agree on is adding a note I would make it much clearer as follows. (Or else it will not solve anything and will just spur new debates and confusion and still leave people having to do the work to be sure.)

“NOTE: This SC should be considered as automatically met for any content using HTML.  Modern browsers all have automatic error correction for parsing errors, and 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.   This SC can therefore be ignored as being redundant.  It no longer provides any benefit to people with disabilities in itself and should not be enforced or required for accessibility.

RE John F’s suggestion.  Since we do not use the word Deprecate anywhere in the note — his suggested edit to the conformance statement is un-needed  (and would have no effect anyway since it only relates do provisions we label as deprecated).


gregg

------------------------------
Gregg Vanderheiden
gregg@vanderheiden.us<mailto:gregg@vanderheiden.us>



On Mar 9, 2023, at 9:33 AM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2021%2FProcess-20211102%2F%23class-3&data=05%7C01%7Cakirkpat%40adobe.com%7Ceaff65f0a60c4dd249ef08db20e30d15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638139931801133957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c5HQacAJOZ1whbSFeTiX9AUcv6tleiGwND1NCh6QOW8%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<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw3.org%2FTR%2FWCAG21&data=05%7C01%7Cakirkpat%40adobe.com%7Ceaff65f0a60c4dd249ef08db20e30d15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638139931801446435%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xQmvbOFn6MDZRnmE%2Blc0mB4y9N8UPk5NZOo7KLw4KdQ%3D&reserved=0>) 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fpull%2F2823%2Ffiles&data=05%7C01%7Cakirkpat%40adobe.com%7Ceaff65f0a60c4dd249ef08db20e30d15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638139931801446435%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Uw%2F%2FjQsWXwJnwwS2SF2Xwu%2BuXuhhdUJXNhvDmsiEADY%3D&reserved=0>, 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<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nomensa.com%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Ceaff65f0a60c4dd249ef08db20e30d15%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638139931801446435%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9j0oPL%2FCndcblaea16brtNBlgmUCScjsEzBKDD0lEfQ%3D&reserved=0>