Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

I also meant to note that adding a note alone, without changing the
conformance requirement, will likely result in the problem issues (drive-by
reporting and busy work) not being addressed - the Conformance requirement
would remain that ALL of the A (or AA, or AAA) requirements are
successfully met.

So a Note alone is insufficient to my current way of seeing this: it also
impacts conformance reporting.

JF

On Thu, Mar 9, 2023 at 1:08 PM John Foliot <john@foliot.ca> wrote:

> Hi Alastair,
>
> I'd be OK with adding a note, but we'd likely also need to make a
> change/note to the conformance section (5.2) as well.
>
> I believe someone else had suggested deprecating 4.1.1 (via the note), and
> then modifying the Conformance requirement to state:
>
>    - 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 <ins>
>    non-deprecated</ins> Level A Success Criteria, or a conforming
>    alternate version
>    <https://www.w3.org/TR/WCAG21/#dfn-conforming-alternate-version> is
>    provided.
>
> (We'd likely also have to add that to the same statement regarding AA and
> AAA conformance.)
>
> To my mind however, that still differentiates what would now be two
> different versions with a nuanced change, and continues to suggest
> "overwriting" a stable and fixed standard - so again I personally think the
> dot-extension mechanism should be used here to distinguish which version is
> which: I CANNOT live with the ambiguity of not clearly identifying which
> version is which (pre-Note or post-Note).
>
> >  then we’d need to go through the whole publishing process from Working
> Draft to Rec, which would take months
>
> Outside or requiring some patience, I don't see a downside there. Given
> that the change is specific and nominal, getting it through the publishing
> process should be relatively easy. But taking months (as opposed to
> hustling it through the process via CFC alone) allows for the wider
> community to review this and provide their feedback as well, which is part
> of the W3C Process intent anyway. It also provides the opportunity to
> address any questions about the differences between the versions in a more
> public forum (a concern Wendy Reid alluded to when noting that some may not
> understand what 'deprecation' means).
>
> >  we’d need to decide whether the default URI (w3.org/TR/WCAG21) went to
> the new version.
>
> ...or, what about w3.org/TR/WCAG211 so that third party requirements
> (tooling, reporting, etc.) can accurately point to the correct version used?
>
>
> JF
>
> On Thu, Mar 9, 2023 at 12:33 PM 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"
>


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