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>
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
> The Global Public Inclusive Infrastructure (GPII) http://GPII.net
> The Morphic project  https://morphic.org
>
> On Mar 8, 2023, at 4:21 PM, 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>
> *Sent:* March 8, 2023 3:20 PM
> *To:* Siegman, Tzviya <tsiegman@wiley.com>
> *Cc:* Alastair Campbell <acampbell@nomensa.com>; WCAG list (
> w3c-wai-gl@w3.org) <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> wrote:
>
> +1
>
>
>
> *Tzviya Siegman*
>
> Information Standards Principal
>
> Wiley
>
> 201-748-6884
>
> tsiegman@wiley.com
>
>
>
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Wednesday, March 8, 2023 12:59 PM
> *To:* WCAG list (w3c-wai-gl@w3.org) <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://secure.wiley.com/email-disclaimers>
> ------------------------------
>
>
>
> --
>
> *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