Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

Quick question:  Is the problem with SC 4.1.1 Parsing too much busy work
for accessibility auditors trying to make sense of an inaccurate HTML
validator report?  Or, is the problem a lack of transparency as to how
browsers and other user agents have been programmed to parse non-conforming
content?  Can we make cleaner, more useful validation reports if the
browser manufacturers self-report on how their wares are going to handle
poorly formed web content and bake those variables into a newer, better
code validation tool, for example?

Also, if you assume that everything is "fixed" now, in terms of browsers
accurately and predictively handling malformed markup - can we assume that
it will be handled "correctly" (whatever that is) in the future?  Are there
any regulations, laws, standards that require software makers to keep their
wares working properly on a consistent basis moving forward?

Or, is it the whole point on this action to sever one of the last remaining
threads in the WCAG specification that hints at coordination between the
various essential and interdependent components of Web accessibility
<https://www.w3.org/WAI/fundamentals/components/> (content authors, user
agents, assistive technology, standards makers, users, etc.) to achieve a
predictable, usable and accessible content?

I spoke up about this proposed action to remove SC 4.1.1 Parsing as part of
the early WCAG 2.2 discussions in the Accessibility Guidelines Working
Group, as well as a participant on this discussion list a few months ago.
I haven't gotten a response yet that directly addresses these important
questions.

Brooks

On Fri, Mar 10, 2023 at 9:15 AM Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> Just one point to add, John:
>
>
>
> This particular question is actually at the root of my current concern and
> "CANNOT LIVE WITH" stance; If we "republish" 2.0 / 2.1 with normative
> changes, then it is no longer .../TR/WCAG20 or .../TR/WCAG21, the revisions
> are normatively different (and thus, I propose .../TR/WCAG201 &
> .../TR/WCAG211 respectively).
>
>
>
> As I’m sure you know but will point out for others, the official URI for
> WCAG 2.0 is http://www.w3.org/TR/2008/REC-WCAG20-20081211/ and
> https://www.w3.org/TR/WCAG20/ is just a pointer to the most recent
> version. Similarly for https://www.w3.org/TR/2018/REC-WCAG21-20180605/
> and https://www.w3.org/TR/WCAG21/. So there definitely would be a
> different date version, but the group would need to decide about using the
> existing pointer or not.
>
>
>
> Now, as one example, Section 508 references WCAG using the pointer URI,
> but clarifies that it is the Dec 11 2008 version (see
> https://www.access-board.gov/ict/#702.10.1).
>
>
>
> AWK
>