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

Hello Alastair,

Broadly, I can live with the proposed way forward.

I would prefer to see some kind of editor note or similar attached to
Section 5.2 also noting that when using HTML (only), SC 4.1.1 "failing"
does not impact the conformance model. This world then explicitly addresses
issues related to drive-by conformance abuses by entities using an
automated conformance checker that is still reporting failures against that
SC.

Also unclear at this time is how these revised Recommendations are formally
identified, and as noted offline, I would ideally like to also see a simple
and easy-to-understand common URL for the different versions (i.e.,
.../TR/WCAG21 versus ../TR/WCAG 21REVISED (or similar)) to make it easy for
lay people to find and differentiate which normative version they would be
using. This then also facilitates "Provides a different target for
companies to <strike>comply with</strike> report against..."

JF

On Wed, Mar 15, 2023 at 11:21 AM Alastair Campbell <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
>


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