Re: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1

Sorry, all, for some delayed messages on my part – they have been hung up in the list processor.

I had originally raised some concerns with 4.1.1 removal from 2.0/2.1 during the last survey. Many of these points were addressed by Alastair and others and I feel that, on balance, keeping consistency between 2.0/2.1/2.2 is worth pursuing.

I find the “add a note” approach discussed most recently by Gregg and Wilco extremely appealing. It sidesteps the issue by noting that, for markup languages like HTML5 that define ambiguous parsing behavior, 4.1.1 is in practice already satisfied. We are then in a position of clarifying the application of existing guidelines, rather than materially altering them.

To that end, if the group moves in this direction, it would also be helpful to:

  1.  Add a similar note to the Understanding document for 4.1.1
  2.  Add a sufficient technique for 4.1.1 similar to, “Use an accessibly supported markup language that defines how user agents must behave when a parser error occurs, such as HTML 5”

This collection of notes would go a long way toward communicating the specific intent/understanding of the working group.

--
Corey Hinshaw
Thomson Reuters

From: Wilco Fiers <wilco.fiers@deque.com>
Sent: Friday, March 10, 2023 6:25 AM
To: w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>
Subject: Re: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1

Hey folks,

I completely agree with Gregg:
> You can even argue that - since it is taken care of by new technology —  the provisions is automatically met - even if the code at the bottom (the html) is missing the tags. By the time any AT sees the code - there is no problem.   The ’tree’ is there and the AT can’t even see the underlying code.

That's what I've been arguing too. There's an exception for things that are allowed by the language in SC 4.1.1. It reads:
> except where the specifications allow these features

I think a fairly reasonable reading of that is that invalid markup is allowed if the markup language describes how user agents should handle it. After all, that was the problem this SC was intended for. Don't use markup that, while accessible today, may become inaccessible tomorrow because the parsers have changed. HTML 5 and ARIA have solved this by defining how user agents must behave when a parser error occurs.

The point isn't that these SCs are no longer required, the point is that they cannot be failed. Taking that position has a lot of advantages:

- It can be done by adding a note, which makes this a non-normative editorial update. So no need for a public review
- It doesn't require a change to the conformance modal to exclude deprecated/obsolete success criteria. The SC simply passes, always.
- It can be applied immediately, even while working with documents that may not get updated like ISO.
- It doesn't invalidate pre-existing WCAG audits, it's effectively an accessibility support update like we did on flashing content last year






On Thu, Mar 9, 2023 at 9:49 PM Gregg Vanderheiden <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>> wrote:
I was talking about 2.0 and 2.1

That statement is true for all versions of WCAG.

The provision was put in to solve a problem that existed back then for screen readers.

This is not longer a problem for screen readers - or any AT.

So whether you are applying the old Standard or the New one  — the provision has no value of any kind to people with disabilities.
It only creates a bunch of work — for not benefit at all.

So people need to understand that — and stop worrying about it.

You can even argue that - since it is taken care of by new technology —  the provisions is automatically met - even if the code at the bottom (the html) is missing the tags. By the time any AT sees the code - there is no problem.   The ’tree’ is there and the AT can’t even see the underlying code.


If you want — you can think of this like you think of Wordpress.   What the user sees is not what is stored.  Wordpress takes the data and creates a page on the fly that is presented to the user.  The author doesnt create the page - just the instruction for word press to create the page.   And if they make little mistakes - Wordpress often can repair them before the user sees it.   This is the same except the repair is done in the browser before the tree is presented to the AT.

In any case — that provision needs to be eliminated from anyones concern and certainly from anyone doing evaluation for 'repair' of problems that are not problems.


gregg

———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org<https://urldefense.com/v3/__http:/raisingthefloor.org__;!!GFN0sa3rsbfR8OLyAw!dG07RRw3c1C0fqPaOl-VkRoPKRe7HsuAtSQ6UHm5IeuvsI6rxyENQA91w0DXz-KE-RrOFc2JAzskI5IWIQQWAAB2P1cZyQ$>
The Global Public Inclusive Infrastructure (GPII) http://GPII.net<https://urldefense.com/v3/__http:/GPII.net__;!!GFN0sa3rsbfR8OLyAw!dG07RRw3c1C0fqPaOl-VkRoPKRe7HsuAtSQ6UHm5IeuvsI6rxyENQA91w0DXz-KE-RrOFc2JAzskI5IWIQQWAAD4bps9vQ$>
The Morphic project  https://morphic.org<https://urldefense.com/v3/__https:/morphic.org__;!!GFN0sa3rsbfR8OLyAw!dG07RRw3c1C0fqPaOl-VkRoPKRe7HsuAtSQ6UHm5IeuvsI6rxyENQA91w0DXz-KE-RrOFc2JAzskI5IWIQQWAACUJVUDIQ$>


On Mar 8, 2023, at 4:21 PM, matt.garrish@gmail.com<mailto:matt.garrish@gmail.com> wrote:

What impact will this change have if you’re required to follow the ISO version of 2.0? Will it be updated, as well, or will this fork the standards?

Will WCAG 2.0 have to become “WCAG 2.0 (Second Edition)” because of the change, for example, along the lines of the in-place changes made to XML 1.0? That would make it clearer that a change has happened but doesn’t address the ISO question.

I’m not sure what to make of this cfc without more info about the process.

Matt

From: John Foliot <john@foliot.ca<mailto:john@foliot.ca>>
Sent: March 8, 2023 3:20 PM
To: Siegman, Tzviya <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>
Cc: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>; WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1

Like Chaals, I'm also likely to make a Formal Objection to substantively changing a previously published W3C Recommendation. That is why we went with the dot extension model: 2.2 WILL BE different than 2.1 just as 2.1 was different than 2.0. Whether we like it or not, changing any of the WCAG versions after they have reached Rec Status may very well have knock-on impacts to legislated requirements around the world, and could have a detrimental (negative) reflection on the W3C writ large.

Despite Wilco's flawed argument, if you are conformant today to ALL of the WCAG 2.1 SC, then the path to meeting 2.2 conformance is to simply meet the new SC requirements (putting aside whether you previously did or did not meet 4.1.1).

I also struggle with invoking the term "Obsolete", and would much prefer to see "Deprecated" - the nuance is subtle but distinct.

JF

On Wed, Mar 8, 2023 at 3:01 PM Siegman, Tzviya <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote:
+1

Tzviya Siegman
Information Standards Principal
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Sent: Wednesday, March 8, 2023 12:59 PM
To: WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1
Importance: High

⛔
This is an external email.
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<https://urldefense.com/v3/__https:/www.w3.org/2023/03/07-ag-minutes*item10__;Iw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmfez9VGJw$>

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://urldefense.com/v3/__https:/github.com/w3c/wcag/pull/3093__;!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmdMiSXedg$>
https://github.com/w3c/wcag/pull/3094<https://urldefense.com/v3/__https:/github.com/w3c/wcag/pull/3094__;!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmcNvvv_-g$>

Survey results: https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/results#xq23<https://urldefense.com/v3/__https:/www.w3.org/2002/09/wbs/35422/wcag22-misc5/results*xq23__;Iw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmewMpiCqg$>

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<https://urldefense.com/v3/__https:/www.w3.org/2021/Process-20211102/*last-call-review__;Iw!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmcpGrAkRg$>

Kind regards,

-Alastair

--

@alastc / www.nomensa.com<https://urldefense.com/v3/__http:/www.nomensa.com__;!!N11eV2iwtfs!ugTba4q53qozcGQqEMEEyasXd33losP4RZNX-n0rUudD53Ypjem-rTaYQTM6JowML9H_10C7jmfGTPcEDg$>
________________________________
The contents of this email and any attachments are confidential and intended only for the person or entity to whom it is addressed. If you are not the intended recipient, any use, review, distribution, reproduction or any action taken in reliance upon this message is strictly prohibited. If you received this message in error, please immediately notify the sender and permanently delete all copies of the email and any attachments.
Click here for translations of this disclaimer.<https://urldefense.com/v3/__https:/secure.wiley.com/email-disclaimers__;!!GFN0sa3rsbfR8OLyAw!dG07RRw3c1C0fqPaOl-VkRoPKRe7HsuAtSQ6UHm5IeuvsI6rxyENQA91w0DXz-KE-RrOFc2JAzskI5IWIQQWAAB4WT-VEA$>
________________________________


--
John Foliot |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |
"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"



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