Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

Hi AWK,

Here is the bulleted summary of my post followed by the full version:


   - Validating code as a way of measuring compliance with SC 4.1.1 Parsing
   is currently a waste of time.
   - It is a waste of time, not because following rules in implementing and
   parsing markup languages is unproductive, but because there seems to be no
   agreement amongst the essential components of accessibility
   <https://www.w3.org/WAI/fundamentals/components/> to follow a common set
   of rules.
   - Getting rid of SC 4.1.1 is a lot bigger deal than simply eliminating
   the code validation step from WCAG testing.


Like all well-meaning WCAG auditors, I have had to face the wall of noise
that comes from generating a validation report as a way of testing SC
4.1.1.  It is no fun to try to use the reports, true enough.  And like you
say, these validation reports we generate in an attempt to measure
compliance with SC 4.1.1 are not much help at all in identifying coding
errors that content authors must correct to make sure that the content is
parsed correctly by user agents and assistive technology.  I get why it's
easy to sell the elimination of this Success Criteria to consumers of the
standard.  That's especially true when it comes to making it easier for
folks who just want to find a way to efficiently move through what has
become an increasing time and resource consuming task: WCAG 2.x testing.

But in my opinion, getting rid of SC 4.1.1 Parsing is a lot more than just
making it easier, faster and cheaper to check all of the boxes in a WCAG
2.x or other derivative standard audit.  It is getting rid of a big part of
what made up the "R" in the P.O.U.R. initialism - it's giving up a lot of
what folks, including me, thought was "Robust" about the WCAG standard.
Diminishing the robustness of expensive, time consuming code-correct
accommodations we on this list try do every day to support access to people
with disabilities gives me great pause.

There is an implicit agreement hinted at in SC 4.1.1.  It has all sorts of
important ramifications when it comes to software support and ultimately,
the performance of accessibility solutions as engineered by content owners.
Or, has what seems like an implicit agreement been a one-sided wild goose
chase all this time? Do only content authors have to follow the rules of
HTML, and not software manufacturers?  How does this disconnect impact
access to digital content by people with disabilities?

Will organizations, municipalities, nations and other political bodies know
that the W3C is erasing the "R" out of P.O.U.R. if you go back to
retroactively remove SC 4.1.1 out of WCAG 2.0/2.1 that they've already
adopted?  Changing the name to some new version number variant does not
equal transparency in letting folks know there's no implied understanding
that if you use valid code your content will be supported in a way that
facilitates access by essential software in the user experience.

Removing SC 4.1.1 Parsing is a bigger issue than just the way it has been
presented.  And consequently, I think it deserves more discussion along the
lines I've identified.

Brooks

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

> Brooks,
>
> 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?
>
>
>
> AWK: The former primarily. Authors are given huge number of issues that
> have no impact on end users, and it is a waste of time to log these issues
> and a waste of time to fix them if there is no impact on the appearance or
> behavior of the content.
>
>
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2Ffundamentals%2Fcomponents%2F&data=05%7C01%7Cakirkpat%40adobe.com%7Ca7f53f51708742cba72608db2180a6a8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638140608664771822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SLE99SmR%2FUlPb%2BE5BvZEE4TSCLZx3%2BIox5khp2eLwKw%3D&reserved=0>
> (content authors, user agents, assistive technology, standards makers,
> users, etc.) to achieve a predictable, usable and accessible content?
>
>
>
> AWK: This is a little bit leading as a question. No, the goal is not to
> sever anything, it is to reflect the reality of this SC not providing any
> benefit to users. The conformance criteria and concept of accessibility
> support function as something far more robust than a thread that hints at
> coordination.
>
>
>
> Hopefully this answers two of your questions. I’m not sure about the
> second one (“Are there any regulations, laws, standards that require
> software makers to keep their wares working properly on a consistent basis
> moving forward?”)
>
> AWK
>