Re: 4.1.1 Parsing in WCAG 2.0 and 2.1

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"