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

+1
I agree with the proposed language.

Kind regards,
Laura

On Wed, Mar 15, 2023, 10:22 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
>