Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

Alastair writes:

> ...the crux of the question is: *Should people be required to report on
4.1.1 in WCAG 2.0 & 2.1?*

That may be the central question, but it introduces 2 other associated
questions:

   1. What is the impact of that decision on Section 5.2 Conformance in
   WCAG 2.0 and WCAG 2.1?
   2. What is the impact of that decision on the "republishing" of WCAG 2.0
   and WCAG 2.1?

I have provided a summary at the end of this rather long email for those
who do not wish to read all of my points. Scroll to the bottom.

*********************

[Off Topic]
*WCAG 2.2:*
The Working Group has (not wrongly) decided that "reporting on 4.1.1"
serves no advantage. It currently introduces concerns over "drive-by
conformance abuses", and generates non-useful "busy work" - two known
problems that I also concur with.

In WCAG 2.2, the accepted group decision was to remove 4.1.1 from the
Requirements. It has been made Obsolete. (Definition
<https://www.merriam-webster.com/dictionary/obsolete>: "no longer in use or
no longer useful") I personally feel that it was an overly blunt decision,
but the result reaches the desired outcome. It is not my first choice, but
I CAN live with the final group consensus.

Applying my 2 other questions to this decision:

*What is the impact of that decision on Section 5.2 Conformance?*

4.1.1 is no longer a normative Success Criteria in WCAG 2.2 *as it has been
completely removed*, and so the conformance model remains the same: "For
Level A conformance (the minimum level of conformance), the Web page
<https://www.w3.org/TR/WCAG21/#dfn-web-page-s> satisfies
<https://www.w3.org/TR/WCAG21/#dfn-satisfies> *all the* Level A Success
Criteria" (4.1.1 has been removed, so you do not have to meet it)

*What is the impact of that decision on the "republishing" of WCAG 2.0 and
WCAG 2.1?*

None, as this is a new normative release of WCAG, in the 2.x family of
releases

*******************

Now, to the Topic of the CFC: *WCAG 2.0 & 2.1*

Before looking at solutions, a review of the historical backdrop is
important here, as making Normative changes to either of these versions
likely has unknown, unmeasurable, and unforeseen consequences downstream. I
have already pointed to the known list of Policies
<https://www.w3.org/WAI/policies/> (above and beyond 508 / EN) potentially
impacted, referenced the list of official W3C translations
<https://www.w3.org/WAI/standards-guidelines/wcag/translations/> of either
of those versions of WCAG, as well as noting the likely references in
external policies, print publications, and tooling. Additionally, as
Alastair notes, "*generally there is no one person at these organisations
who can answer a question like this.*" which is why I assert that we will
likely never definitively know what the complete impact of our proposed
changes will have on existing legacy materials. *For this reason we MUST
proceed with extreme caution.*

Here again, there are 3 choices: Remove 4.1.1 (a normative change), add a
non-normative note, or leave it in the Recommendation but *normatively*
make it "no longer necessary to evaluate or repair" (which is not
obsoletion, but deprecation superseded, or rescinded
<https://www.w3.org/2021/Process-20211102/#rec-rescind> - although
currently those defined terms at the W3C ONLY apply to entire
specifications).

*Add a Note:*
Adding a non-normative note does not solve the root problem: organizations
will continue to struggle with 4.1.1, due to Section 5.2's unambiguous
requirement that ALL SC must be successfully met. *For this reason, that
option appears to have been generally discarded - it does not solve the
problem we are attempting to solve.*

*Remove 4.1.1 from 2.0 & 2.1:*
We can remove 4.1.1 from earlier versions of WCAG. As Alastair previously
noted, we can do that using the “Corrections that do not add new features
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2021%2FProcess-20211102%2F%23class-3&data=05%7C01%7Cacampbell%40nomensa.com%7Cfafc10286f4e48caad1a08db20b27ffb%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C638139723248368224%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oMLAspY%2BQf%2B7y6VzcAzvfELTLUuhmpr%2F6GKKy1eHs7U%3D&reserved=0>”
process. Alastair also notes *it would require a public review (and Patent
Review draft), probably of 60 days* (although that isn’t specified). [JF:
Why? Because it is a normative change to a previously finalized version of
WCAG]
However, more than one person (Chaals, Wilco, Mark Hakkinen, myself,
others) have an issue with this approach, and it does not seem to be
garnering group consensus.

*Leave 4.1.1 in the spec, but make it no longer normatively required for
conformance:*
I have seen/heard this option mentioned as well. AWK noted, "*If WCAG 2.1
and 2.0 had a note, that is marginally better than doing nothing in that is
sends the message what the WG opinion is but doesn’t have as much benefit
as a revision (whether as a WCAG 2.0.1 or WCAG 2.0 but with a different
date)."*
There is some Draft language that Gregg has brought forward that states in
part, *"It should be considered as automatically met for any content using
HTML.  This SC can therefore be ignored as being redundant."*

I have previously noted that overall I like Gregg's proposed language, and
applying that Note to SC 4.1.1 in 2.0/2.1 solves some of the problems in
our problem statement - but leaves one critical question unresolved. That
is, what is the impact of that "normative" Note on Section 5.2 Conformance
<https://www.w3.org/TR/WCAG21/#conformance-reqs>? This is because the
*real* problem with 4.1.1 today is Conformance (also normatively defined in
WCAG). *Not meeting 4.1.1 means you are not meeting the requirements of
5.2, and thus are not conformant to WCAG 2.0/2.1, which is what is
generating the validation abuses and busy work.*

*What is the impact of that decision on Section 5.2 Conformance?*

For that Note to have any real impact on the problem statement (drive-by
conformance abuses / "busy work"), we need to also remove 4.1.1 from the
"...satisfies <https://www.w3.org/TR/WCAG21/#dfn-satisfies> all the Level A
Success Criteria" normative requirement found in Section 5.2.

In 2.2, we did that by completely removing 4.1.1 from the Recommendation,
but if we DO NOT remove 4.1.1 from earlier versions, but instead say "yes,
yes, but you can now safely ignore this" (paraphrasing Gregg's language),
then we still need to address the impact on 5.2. For that reason, I had
previously proposed a revision to Gregg's note: "*This SC has been
deprecated." *(Update: I could also live with Superseded or Rescinded).

But then, we would also need to revise Section 5.2 from saying "*...satisfies
<https://www.w3.org/TR/WCAG21/#dfn-satisfies>** all the Level A Success
Criteria*" to something that instead said "*...satisfies
<https://www.w3.org/TR/WCAG21/#dfn-satisfies>** all the Level A Success
Criteria (that have not been deprecated/superseded/rescinded)*" - because
this is what is triggering the drive-by complaints / busy work: *organizations
NEED to meet Section 5.2's normative requirements*

*What is the impact of that decision on the "republishing" of WCAG 2.0 and
WCAG 2.1?*

At the highest level, we are proposing to make *normative changes* to both
of those Recommendations. We *can* do that procedurally, but we will then
have two "almost identical" versions of each Recommendation. No matter
whether we "Remove it" or "Leave it but de-fang it", either choice will
trigger what Alastair has already noted as *"...**require(ing) a public
review (and Patent Review draft), probably of 60 days"*

TO BE CRYSTAL CLEAR, I AM NOT PERSONALLY OPPOSED TO THAT.

However, because of the understood knock-on effects of that decision, *we
will (I assert) need an unambiguous way of referencing either version*.
Matt Garrish previously dubbed the change “WCAG 2.0 (Second Edition)”,
whereas elsewhere I've seen it referred to as WCAG 2.0 (2008) versus WCAG
2.0 (2023), but I have suggested it be WCAG 2.0.1. (I suggest this, because
it is a well known and broadly understood naming convention: it is
unambiguous that 2.0 and 2.0.1 are different, and because of the
commonality of that naming convention, most if not all will understand that
v2.0.1 came AFTER v2.0)

Alastair also noted: *we’d need to decide whether the default URI
(w3.org/TR/WCAG21 <http://w3.org/TR/WCAG21>) went to the new version. In
which case, would anyone notice the difference in number?*

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).

*Summary:*

   - *Any* normative changes we make to 2.0/2.1 will require a public
   review (and Patent Review draft), probably of 60 days

   - JF *CANNOT LIVE WITH* the "*Following the same approach as WCAG
   2.2...where the SC text would be removed and replaced with a note that says
   why it has been removed*" proposal for 2.0/2.1 that the current CFC is
   asking for consensus on.

   - JF *DOES* support the "Leave it in, defang it via a Note, *and modify
   Section 5.2 to address the change in conformance requirements*" - 2
   normative changes to both 2.0 and 2.1 (I *CANNOT *accept leaving but
   changing 4.1.1 while not also changing 5.2 at the same time)

   - JF will *OBJECT *to republishing 2.0/2.1 under the same Name and W3C
   "TR" reference URL *after normative changes have been applied* - I can
   possibly be convinced on a different naming convention other than 2.0.1 and
   2.1.1, but the need of a clear, unambiguous naming choice remains
   unchanged. (I also note that adopting the 2.0.1 naming convention makes the
   .../TR/ URL reference simple and clean as well)

JF

On Thu, Mar 9, 2023 at 4:49 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi everyone,
>
>
>
> (John, I think you’ve missed some of the previous conversations /
> decisions, the WCAG 2.2 aspect was agreed in Jan:
>
> https://lists.w3.org/Archives/Public/w3c-wai-gl/2023JanMar/0097.html)
>
>
>
> Based on the previous discussions, the crux of the question is:
> *Should people be required to report on 4.1.1 in WCAG 2.0 & 2.1?*
>
>
>
> For WCAG 2.2 we decided “no”, no reporting on 4.1.1 would be required.
> Therefore, the most effective way of showing that was to remove the SC text
> and replace it with a note of explanation.
>
> Deprecation (the term and the concept) was considered, but confusing as to
> whether it was required or not.
>
>
>
> We all know that, in practice, the well-formedness aspects are dealt with
> by browsers and things like duplicate IDs, when harmful, will be caught
> under 1.3.1/4.1.2.
>
>
>
> However, if reporting on it is still required, the testing to fill in the
> report will still be needed, so we won’t have achieved very much (except in
> 2.2).
>
>
>
> We could potentially retain the normative text, but heavily hint that
> 4.1.1 is not recommended anymore.
>
>
>
> So I can see two levels of note for 2.0/2.1, in concept:
>
>
>
>    1. Say it is removed from a later version, it is not recommended but
>    still required for conformance claims, or
>    2. Say it is removed from a later version, it is 'obsolete' and can be
>    disregarded.
>
>
>
> I think Gregg’s version of (2) is the clearest so far.
>
>
>
> Mary Jo – We have reached out to people from some of those organisations,
> I read out some correspondence from one in the last meeting. The gist of it
> was: If the regs have copied WCAG it won’t make any difference, if they
> link through to the default version people will have one less thing to do.
> There was no sense of panic.
>
>
>
> Also, generally there is no one person at these organisations who can
> answer a question like this. A bit like asking an AGWG participant what we
> would think. If they don’t have active work now, there may not be a chair
> equivalent role to organise a group opinion. The best we will get is
> individuals’ opinions.
>
>
>
> Kind regards,
>
>
>
> Alastair
>
>
>
> PS. Gregg’s version was:
>
> NOTE: This SC should be considered as automatically met for any content
> using HTML.  Modern browsers all have automatic error correction for
> parsing errors, and issues such as incorrect states or names due to a
> duplicate ID, or missing roles due to inappropriately nested elements are
> covered by different success criteria.   This SC can therefore be ignored
> as being redundant.  It no longer provides any benefit to people with
> disabilities and should not be enforced or required for accessibility.
>


-- 
*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"