Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

Hi Gregg,

If I might, I think part of the problem is which version of WCAG we are
talking about.

For the next version (2.2) a note added to 4.1.1 (as I think you are
suggesting, and as I perceive is Wilco's preference as well) gets us to
what I consider roughly 80% there: the outstanding issue of Section 5.2
which states that ALL SC must be met currently does not match the "This can
safely be ignored" proposal you have brought forward. (If it is ignored,
and does not "pass", then you cannot meet 5.2's requirement for passing ALL
of the SC. I generally like that language of the Note however, and could
fully support that in WCAG 2.2 - WITH the additional modification to the
Conformance Model.)

A simple modification to your proposed Note would assist there:

NOTE: *This SC has been deprecated.* It 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 in itself and should not
be enforced or required for accessibility.

*(To Wendy's concern that not everyone knows what deprecated means: your
extended note essentially defines what it means - at least in THIS context,
which then would facilitate the Conformance Section with my proposed minor
edit there.)*


But the issue is what to do with this SC retroactively in 2.0 and 2.1?

There, I am opposed to simply "removing" (or obsoleting, deprecating) the
requirement and republishing under the same version number, which is/was
what the CFC was calling for ("...what to do with 4.1.1 Parsing in WCAG 2.0
& 2.1 now that it has been removed from WCAG 2.2.").

I can live with a similar note being added (which, by my reading, *IS*
deprecation: "*This SC can therefore be ignored as being redundant*." - not
removed, but "ignored") for 2.0 and 2.1, as long as the "republished"
version is 100% unambiguous that it is NOT the same as its parent source:
removing (or deprecating) that SC from 2.0 and 2.1 and then republishing is
creating a derivative work, and that should be crystal clear to all. The
dot-extension model allows for that (and elegantly as well IMHO).

Again, I am not conceptually opposed to doing that, as long as (once again)
it is clear that this version of 2.0 is different from that version of
2.0:  it is with some irony that I note that this SC is in part about
duplicate ID values, and yet the currently proposed solution is to have 2
different versions of both the 2.0 & 2.1 Recommendations with the same name
(value).

Unlike browsers, I do not see policies, "dead tree" printed versions of
content, and other dependencies that references the Formal Recommendation
having the ability to "Fix it in the mix" as browsers do with "bad code"
today.

JF

On Thu, Mar 9, 2023 at 2:24 PM Gregg Vanderheiden <gregg@vanderheiden.us>
wrote:

> Hmmm
>
> That note is kind of confusing and unclear what it means.
>
> I still think the clearest thing is to proceed as proposed earlier and
> remove it with a note.
>
> But if all we can agree on is adding a note I would make it much clearer
> as follows. (Or else it will not solve anything and will just spur new
> debates and confusion and still leave people having to do the work to be
> sure.)
>
>
> “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 in itself and should not be enforced or required for
> accessibility.
>
>
> RE John F’s suggestion.  Since we do not use the word Deprecate anywhere
> in the note — his suggested edit to the conformance statement is un-needed
>  (and would have no effect anyway since it only relates do provisions we
> label as deprecated).
>
>
> gregg
>
> ------------------------------
> Gregg Vanderheiden
> gregg@vanderheiden.us
>
>
>
> On Mar 9, 2023, at 9:33 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> Hi everyone,
>
> I wanted to follow up on the process aspect and ask those who +1ed the CFC
> whether they would object to the alternative below.
>
> The processes for the options are different:
>
> *Removal:*
> If the SC text is removed, or stated as not required, I’m calling this the
> ‘removal’ approach. I was mistaken on the errata aspect, the removal
> approach would mean 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. It would require a public review (and Patent Review draft),
> probably of 60 days (although that isn’t specified).
>
> *Adding a note:*
> If the SC is left as a requirement but a note is added, this would be an
> editorial change. We’d need director approval, but there’s not requirement
> for public review.
>
> *Using a dot-version:*
> If we made an update and called that WCAG 2.0.1, or 2.1.1, then we’d need
> to go through the whole publishing process from Working Draft to Rec, which
> would take months. Also, we’d need to decide whether the default URI (
> w3.org/TR/WCAG21) went to the new version. In which case, would anyone
> notice the difference in number?
>
> We had considered the ‘adding a note’ approach during the github threads,
> survey and discussions leading up to the CFC. It had not garnered much
> support which is why the CFC was not on that option.
>
> If we did take that approach then we’d add a note after the SC text.
> Working from a previous suggestion
> <https://github.com/w3c/wcag/pull/2823/files>, that could be:
>
> “*NOTE*: Modern web technologies have standardized how user agents parse
> incorrect markup. Any invalid markup is therefore allowed under 4.1.1
> Parsing for technologies such as HTML 5 and CSS 3. This success criterion
> is always satisfied for these technologies.
> 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.”
>
> For those people who +1ed the removal approach, would you object to this
> approach?
>
> Kind regards,
>
> -Alastair
>
> --
>
>
> @alastc / *www.nomensa.com* <http://www.nomensa.com/>
>
>
>

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