Re: Removing 4.1.1

Hmmmm
This seems to imply that removal in 2.0 and 2.1 is to ensure backwards compatibility.   That may be a perceived byproduct (it is actually backward compatible if you didnt) - but that is not the reason for removing it.  I would stick with the rationale (one of the versions) that states that it is no longer needed for accessibility and is therefore removed - for that reason.   We could add that it is also causing other problems but that would generate endless discussion so — we can skip that.) 

best

gregg

 

> On Dec 13, 2022, at 2:32 PM, Jonathan Avila <jon.avila@levelaccess.com> wrote:
> 
> I would recommend we add onto this note something like:
>  
> “Note: In a more recent version of this standard WCAG 2.2 this SC has been removed as ... “
> followed by “With the removal of the criterion, this criterion is now marked obsolete in this standard effectively removing it as a requirement which ensures the more recent version of WCAG is backwards compatible with this standard.”
>  
> Jonathan
>  
> From: Chuck Adams <charles.adams@oracle.com <mailto:charles.adams@oracle.com>> 
> Sent: Tuesday, December 13, 2022 2:54 PM
> To: Bradley-Montgomery, Rachael <rmontgomery@loc.gov <mailto:rmontgomery@loc.gov>>; Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>>; WCAG list (w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Subject: RE: Removing 4.1.1
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>  
> I would update and propose:  Note: In a more recent version of this standard WCAG 2.2 this SC has been removed as the browsers have addressed this issue.
>  
> Regards,
> Chuck
>  
> From: Bradley-Montgomery, Rachael <rmontgomery@loc.gov <mailto:rmontgomery@loc.gov>> 
> Sent: Tuesday, December 13, 2022 12:48 PM
> To: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>>; WCAG list (w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Subject: [External] : Re: Removing 4.1.1
>  
> Hello,
>  
> During the call, Katie suggested some alternative language for a note in  2.0 and 2.1: "Note: In a more recent version of this standard WCAG 2.2 this SC has been removed as the browsers have addressed this problem."
>  
> Kind regards,
>  
> Rachael
>  
>  
> From: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>>
> Date: Tuesday, December 13, 2022 at 1:42 PM
> To: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Subject: Removing 4.1.1
> Resent-From: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Resent-Date: Tuesday, December 13, 2022 at 1:42 PM
>  
> Hi everyone,
>  
> In the discussion today <https://urldefense.com/v3/__https:/www.w3.org/2022/12/13-ag-minutes.html*t13__;Iw!!ACWV5N9M2RV99hQ!JV8kNYrfHyBljzhMdpAN5XqPcjXidIl2X5dmAtkLwgfp3oYvQU6Qsogipf7PmV6z_G9DtIgavBad2KffgKkefYgO$> we decided (again) to remove 4.1.1 from WCAG 2.2 and include a note.
>  
> We also got towards agreeing to do the same in WCAG 2.0 and 2.1. That would involve creating an errata, then re-publishing the specs to include the errata.
>  
> Areas of agreement:
> We don't want people to be required to test or report on 4.1.1.
> Any issues that impact end-users that are caught by other SC, so a fully conforming 2.2 site would conform to 2.1/2.0 for those meaningful issues (even if it still included 4.1.1).
>  
> The rest of the discussion was how to implement it.
>  
> Looking at the current editor’s draft, it would be like this:
> https://w3c.github.io/wcag/guidelines/22/#parsing <https://urldefense.com/v3/__https:/w3c.github.io/wcag/guidelines/22/*parsing__;Iw!!ACWV5N9M2RV99hQ!JV8kNYrfHyBljzhMdpAN5XqPcjXidIl2X5dmAtkLwgfp3oYvQU6Qsogipf7PmV6z_G9DtIgavBad2KffgOqvf6Fe$>
>  
> But with an additional note. Gregg suggested:
> “NOTE: This was originally adopted to address problems that Assistive Technology had directly parsing HTML. This is no longer true so this criterion no longer solves that problem and is removed.”
> That is in https://github.com/w3c/wcag/pull/2840/files <https://urldefense.com/v3/__https:/github.com/w3c/wcag/pull/2840/files__;!!ACWV5N9M2RV99hQ!JV8kNYrfHyBljzhMdpAN5XqPcjXidIl2X5dmAtkLwgfp3oYvQU6Qsogipf7PmV6z_G9DtIgavBad2KffgHa9oWFH$>
>  
> There is also a section at the top of the understanding document explaining the rationale. https://w3c.github.io/wcag/understanding/parsing.html <https://urldefense.com/v3/__https:/w3c.github.io/wcag/understanding/parsing.html__;!!ACWV5N9M2RV99hQ!JV8kNYrfHyBljzhMdpAN5XqPcjXidIl2X5dmAtkLwgfp3oYvQU6Qsogipf7PmV6z_G9DtIgavBad2KffgIL35gDv$>
> (I need to work out how to get the old SC text to appear on the understanding doc, remove the “new in wcag 2.2” bit, and add the mapping table.)
>  
> So the question for 2.0/2.1 is whether to do exactly the same thing?
>  
> Pertinent comments from the meeting included:
> Removing it from early specs feels like re-writing history.
> Keeping them consistent means that you maintain inter-version compatibility.
> Keeping the SC text in allows the worst aspects of 4.1.1 to continue (e.g. drive-by legal threats).
> We could maintain the SC text and add a note saying (strongly) not to report on obsolete SCs.
> Regulations tend to use specific dates of a standard, so it doesn’t change regulations until they decide to do so.
>  
> Do you have any different arguments for/against removing 4.1.1 from 2.1/2.0?
>  
> Kind regards,
>  
> -Alastair
>  
> -- 
>  
> @alastc / www.nomensa.com <https://urldefense.com/v3/__http:/www.nomensa.com__;!!ACWV5N9M2RV99hQ!JV8kNYrfHyBljzhMdpAN5XqPcjXidIl2X5dmAtkLwgfp3oYvQU6Qsogipf7PmV6z_G9DtIgavBad2KffgP9I7Lti$>