Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

It is not a question of HTML validation.  That is not required for accessibility.  

It is a question of Accessibility checkers turning up all sorts of  "failures"  that are not related to accessibility anymore. 

But without the change — the regulations all require it to be done — even though it no longer has any value for accessibility at all.


> On Mar 10, 2023, at 8:00 AM, Brooks Newton <brooksallennewton@gmail.com> wrote:
> 
> 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 <mailto: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
>>