RE: 4.1.1 Parsing in WCAG 2.0 and 2.1 - take 2

Hi Andrew, thank you for sharing. If we take this approach we should then make sure to be clear that while WCAG 2.2 may be functionally backwards compatible – from a technical standard approach WCAG 2.2 is not completely backwards compatible because of the removal of 4.1.1 and that if you need to meet WCAG 2.0/2.1 you would need to reference 4.1.1 from those standards.

Jonathan

From: Andrew Kirkpatrick <akirkpat@adobe.com>
Sent: Thursday, March 16, 2023 9:13 AM
To: Wilco Fiers <wilco.fiers@deque.com>; Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Re: 4.1.1 Parsing in WCAG 2.0 and 2.1 - take 2

For what it’s worth, I had a conversation with Tim Creagan from the Access Board at CSUN this week and I asked him to share whether had had concerns about removing 4.1.1 in either the upcoming or previous versions of WCAG, and whether I could share that conversation with the group – he said yes so I am.

Tim didn’t really say yes or no to removing 4.1.1 in WCAG 2.2 as he isn’t up on all of the details of the decision, but what he was very clear about is that he wouldn’t want to see it gone if there was a negative impact to users, and that he would be happy to see it gone if it didn’t impact users and it simplified the efforts associated with conformance.

For WCAG 2.0 and 2.1, Tim confirmed the Access Board specifically references the Dec 11, 2008 version of the standard, so any re-release which has a different date would not be part of Section 508. At some future date the Access Board will probably refresh the standard (no dates specified for that) and they could choose to use WCAG 2.2, 2.1, 2.0 (updated), 3.0, or whatever made the most sense.

So, for this this confirmed what I believed and is (not surprisingly) very consistent with what Bruce reported. I mention this conversation and had this conversation with Tim because the idea that the WG hasn’t done enough to work with policy makers seems to resurface occasionally in this debate.

My take away is that we need to keep doing our job the way we have in ensuring that the WCAG standard is expressing the best current advice of the group, and the policy makers will still be able to use WCAG 2.0 (Dec 11 2008) or WCAG 2.1 (June 5 2018) as they have so far.

I think that we should:

  1.  Stay the course with removing 4.1.1 from WCAG 2.2.
  2.  For WCAG 2.0/2.1:
     *   Add information in the Understanding document to clarify that it has been removed in WCAG 2.2
     *   We could add an informative note to 2.0/2.1 to point to that Understanding note
     *   Mark WCAG 2.0 and 2.1 as Superseded. This doesn’t mean that they can’t be used or referenced, just that a newer version exists. We would clarify the details of this in the announcement (much as was done for WCAG 1.0: https://lists.w3.org/Archives/Public/w3c-wai-ig/2018JulSep/0166.html). The W3C definition of superseded states: “A superseded specification is one that the W3C community has decided that a newer version should be recommended for new adoption instead.” As I don’t think that we are recommending WCAG 2.0 for NEW adoption, and soon won’t be recommending WCAG 2.1 for NEW adoption, this makes sense to me.

Thanks,
AWK

Andrew Kirkpatrick
Director, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk



From: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>
Date: Thursday, March 16, 2023 at 7:41 AM
To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Cc: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: 4.1.1 Parsing in WCAG 2.0 and 2.1 - take 2
Resent-From: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Resent-Date: Thursday, March 16, 2023 at 7:40 AM


EXTERNAL: Use caution when clicking on links or opening attachments.


Hey Alastair,

First up, thank you for putting this together!

Can you clarify if what you are proposing applies to WCAG 2.2 as well, or if you are proposing this only for WCAG 2.0 and 2.1. Assuming we're revising WCAG 2.2 CR to also use this approach then this is something I support.

One question I have is why we wouldn't explicitly label SC 4.1.1 as obsolete or deprecated, in addition to the note you're suggesting. From the conversations I've seen there does seem to be some support for that, and I haven't seen any disagreement.

On Wed, Mar 15, 2023 at 4:22 PM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Hi everyone,

This following is a summary of the previous threads followed by a proposed alternative to the previous CFC. If that gets traction, we will re-issue the CFC.

It seems that (almost) everyone agrees that 4.1.1 is no longer useful and is often detrimental to practical accessibility by creating "busy work" with no accessibility benefit.

After discussing various options, the one with the most support (from those participating at the time) was to take the same approach as WCAG 2.2: Remove the SC text and include a note.

When that option went to CFC the concerns raised were:

  *   We should not substantively change a previously published versioned recommendation at all because:

     *   It might be seen as earlier claims of non-conformance to WCAG 2.0 or 2.1 are no longer valid.
     *   It may have knock-on impacts to legislated requirements around the world, which could have a negative reflection on the W3C.
     *   It would impact translated versions which would also need updating.
     *   We may need to reach out to various standards orgs which have taken in WCAG verbatim.

Points made in response:

  *   Consistency between 2.0/2.1/2.2 is worth pursuing.
  *   The SC is creating false-positive tests results. If the goal is to increase accessibility - then we should change it so that people stop wasting time fixing something that is not broken.
  *   Many standards get revised (without re-numbering), which is why regulations often include the standard and date of that standard.

Concerns raised which I think have been answered:

  *   Q: What impact will this change have if you’re required to follow the ISO version of 2.0? Will it be updated, as well, or will this fork the standards?

     *   A: ISO is planning an update based on 2.2, as is the EU.
In general, if you follow a dated version it doesn’t change. If you follow the latest version you have one less thing to report on.

  *   Q. What if we use the term deprecation rather than obsolete.

     *   A: This approach for 2.0 and 2.1 is not following a deprecation process, which would mean leaving older recs alone and marking as deprecated in the new one. Either it’s recommended success criteria, or it’s not.

Suggested alternatives:

  *   Create a 'dot release' of 2.0 and 2.1, e.g. 2.0.1 and 2.1.1 with the removed SC.

     *   Provides a different target for companies to comply with, although that probably doesn't affect people under regulations that point to the 2.0 version.

  *   Since the reason behind the SC is automatically taken care of by new technology (since 2.0), the provision is automatically met. Therefore we can just add a note to that effect.

     *   The understanding document could be consistently updated across all versions.
     *   We could add a technique for 4.1.1 such as "Use an accessibly supported markup language that defines how user agents must behave when a parser error occurs, such as HTML”


  *   Move 4.1.1 to AAA in a second edition.


The option I have seen with the most support so far is adding a note to the effect that: This SC is automatically met.

Something like:

“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.”

Points on this approach from the thread:

  *   This is not 'deprecation' and would not require an update to section 5.2. It is saying that it is automatically met (at least in HTML technologies).
  *   On the question of whether “specifications allow these features”, they may not be explicit, but the specs do define which IDs and attributes to use if there are duplicates. That could be read as 'allowing'.

It doesn’t go as far as some people would like (removing the SC text), but it does convey the intent of the group (ignore this SC).

Is that a compromise you can live with?

Kind regards,

-Alastair


--
Wilco Fiers
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]