Re: Removing 4.1.1

To avoid the chairs having to defend themselves - I would like to point out that this is not a "direction the chairs are taking"  on this.   

The chairs did not raise this — it was raised by others.  And there is near unanimity in the working group that this is a problem that should be solved before the release of 2.2

It is true that it would have been good to do this earlier — but everyone was focused on the new provisions and the problems with this one did not come up (at least to me) until others brought it up recently — including the severity and frequency of the problems it is creating. 

Even though it is no longer a problem — it is being used to market remediation products pointing to the fact that websites fail this provision (which has no effect on accessibility today) but they can be sued if they don’t buy their product to detect and fix it. 

It has also been pointed out the large amount of time that companies trying to follow WCAG waste fixing things to  pass this — when the fixed have no effect whatsoever on the accessibility of the webpages since browsers all ignore these errors and thus so does the AT that gets its information (in good form) from the brower. 

So there is good reason to act late on this.
It was not the chairs but the majority of the WG that is pushing this
It would have been good to fix earlier - but it was not brought up or its impact explained earlier. 

All the best

gregg

------------------------------
Gregg Vanderheiden
gregg@vanderheiden.us



> On Dec 13, 2022, at 2:26 PM, Wilco Fiers <wilco.fiers@deque.com> wrote:
> 
> Hey folks,
> 
> I am concerned with the direction the AGWG chairs are taking this. This would have been a fantastic thing for AGWG to work on two years ago. But to start this work now, with so little time left for us to figure out how to do this right, and when we're already in the extension period of our charter, I think it's inappropriate.
> 
> I feel that something this significant deserves to be handled with a lot of care and forethought. For example, what are even the requirements for publishing an amended WCAG 2.0 and 2.1. It's never been done. Does it need to go through formal approval? I bet someone knows, but nobody on the call today did.
> 
> Then there is bigger stuff, like what does this mean for WCAG's ISO standard. Can that be updated? What's the process for that? If it can be done, who would need to approve such a thing, and will they? Can we do it with this W3C legal entity thing going on? What about other standards like EN 301 549? Can they, and if so will they adopt a similar change? What about policy and legislation? What about WCAG 2 translations, will those be updated, or is Germany just going to keep using 4.1.1 because it was never removed from their translation? What about test methodologies like Trusted Tester and RGGA? How long will all of these things be in disagreement while they're sorting out this update?
> 
> I'm sure this stuff can all be figured out, but we should have the answers before we make the change. We can't just throw out this curve ball and hope for the best. Please understand that I want to see 4.1.1 be dropped in some way. But we have a responsibility to coordinate and communicate about these things. We haven't done that, and we don't have time for it anymore.
> 
> 
> On Tue, Dec 13, 2022 at 7:42 PM Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
>> Hi everyone,
>> 
>>  
>> 
>> In the discussion today <https://www.w3.org/2022/12/13-ag-minutes.html#t13> 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
>> 
>>  
>> 
>> 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
>> 
>>  
>> 
>> There is also a section at the top of the understanding document explaining the rationale. https://w3c.github.io/wcag/understanding/parsing.html
>> 
>> (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 <http://www.nomensa.com/>
>>  
>> 
>>  
>> 
>>  
>> 
> 
> 
> -- 
> Wilco Fiers
> Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force
> 
> 
> <deque_logo_180p.gif>