RE: WCAG 2.2 acceptance criteria

+1 Chuck


From: Glenda Sims <> 
Sent: Thursday, March 7, 2019 2:03 PM
To: Delisi, Jennie (MNIT) <>
Cc: John Foliot <>; Alastair Campbell <>;; COGA TF <>; Silver TF <>
Subject: Re: WCAG 2.2 acceptance criteria


Goodwitch magically appears after being MIA for weeks to say: 


I suggest we clarify this bullet a bit more.  I think the example is a useful example, but it isn't the only way to be "feasibly testable".  And the way the sentence is written, it is hard to parse/process.  So what if we changed from this:

Be feasibly testable through automated or manual processes, i.e. take a few minutes per page with tools available prior to Candidate Recommendation stage.

To something like this:

Be feasibly testable in a "reasonable amount of time" through automated or manual processes prior to Candidate Recommendation stage.  Examples include:

Automated - an automated testing tool exists that quickly and accurately determines if the criteria is met or not. 
Assisted - a software tool exists that makes it more efficient for a tester to accurately determines if the criteria is met or not.  
Manual - a manual process exists that makes it possible for a tester to accurately determines if the criteria is met or not.

note:  "reasonable amount of time" can be determined by a call for consensus.  


I'd suggest that if we pursue this "reasonable amount of time" angle...that it be based on "reasonable amount of time" to test an ELEMENT (not a page).  I think the variance in amount of time to test a page (when pages can endlessly scroll) will make it impossible to come up with a "reasonable amount of time" per page.


I'm not in favor of leaving the requirement as it is currently drafted at HYPERLINK "" 




HYPERLINK ""glenda sims, HYPERLINK ""cpacc   | team a11y lead | 512.963.3773 


        HYPERLINK ""deque systems  accessibility for good



On Thu, Mar 7, 2019 at 1:31 PM Delisi, Jennie (MNIT) <HYPERLINK ""> wrote:


Part of the concerns the COGA group discussed was that manual tests are often required, and the variety of time required to test different pages can vary greatly, depending on the content of that page.


One example we discussed was the current testing required to ensure that the appropriate alt text is assigned for each image used on a page. 1-2 images on a page, not a big deal to test. But, on a catalogue page, it could be significant.

The question came down to the concept that there may be manual testing that (at this time) may be the only way to truly ensure a barrier is not met by individuals with cognitive disabilities. 


I, too, work in an environment where a lot of testing occurs every day. And, we have to hold contractors, vendors, and employees to standards that can be measured. We need to be able to provide detailed and consistent feedback when a failure of a success criteria has been noted. The time taken to complete testing is definitely important. But, consideration of barriers is the whole goal, right? 


From a matter of equality standpoint, why would the testing to address the needs for one group be ok if it takes a lot of time, because they got in on the creation of success criteria at the beginning of the process; but for another group who’s needs were addressed more thoroughly later in the development of success criteria, manual testing that may sometimes require some time cannot be considered?


I would like to propose that the language about the time it takes to complete a test have an exception process, or propose a rewording of the time component, so that the barriers experienced by this group of individuals with disabilities receives fair consideration in this process.




Jennie Delisi, MA, CPWA

Accessibility Analyst | Office of Accessibility

Minnesota IT Services | Partners in Performance

658 Cedar Street

St. Paul, MN 55155

O: 651-201-1135

Information Technology for Minnesota Government | HYPERLINK ""




From: John Foliot <HYPERLINK ""> 
Sent: Thursday, March 7, 2019 11:26 AM
To: Alastair Campbell <HYPERLINK "">
Cc: HYPERLINK ""; Delisi, Jennie (MNIT) <HYPERLINK "">; COGA TF <HYPERLINK "">; Silver TF <HYPERLINK "">
Subject: Re: WCAG 2.2 acceptance criteria


Hi All,


To perhaps also put a finer distinction on it... W3C Process mandates two independent implementations of whatever new technology is being proposed - a testing activity we actually did last spring during CSUN for the 2.1 Success Criteria (where, for SC 1.3.6 @ AAA we actually used the implementations that Lisa had pointed us to). Those implementations may or may not also serve as a 'testing tool', but as the Silver discussion continues, a repeatable testing methodology will need to surface for each new requirement, whether that is via a tool (mechanical tests - see: ACT TF), or via a 'cognitive walk-though' or similar methodology (a process still to be fully defined in Silver).


At the end of the day, while it is true that our primary audience is and will always be users with disabilities (of all stripes and forms), a second important consideration is compliance requirements mandated by legislation. To clear that hurdle, we will need to ensure that both implementers and consumers have a baseline measurable & impartial (non-subjective) "test", so that entities can then claim conformance based upon the outcome of said test.




On Thu, Mar 7, 2019 at 10:52 AM Alastair Campbell <HYPERLINK ""> wrote:

Hi Lisa,


> To meet new user needs we may need new tools and reviews may need to acquire new skills and knowledge.


Which is fine, perhaps we can clarify that it means available at the time of publication?


New tools, especially if they “take a day” from a programmer would need to be available at the time of publication, for the reasons I outlined in the last email.



> Also new tools will come as soon as we know a SC will be accepted. in other word at CR. With WCAGs current history it will not come before then.


Can you point to a previous example? I.e. where a tool that didn’t exist was required to meet an SC wasn’t available until after CR? 

The closest I can think of is ARIA in WCAG 2.0, but it wasn’t actually required to meet the SCs.


It is very difficult to deal something in CR which then has to be pulled because no one has created a tool, the whole timeline goes back a step. The way the W3C prefers to work is to have working prototypes/code created prior to specs. This has been a hard-learned approach [1].


I suggest that if an SC needs a tool, we work up the SC template and go through the initial process. That could be accepted on the condition that a tool will be available. If it does not become available then the SC will be removed before CR.


It would also help to put those SC(s) first so people have more time to work on the tools, I’ll make a note of that.







1] Accessibility example for what should be a ‘simple’ thing, the naming algorithm.




​John Foliot | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good


Received on Thursday, 7 March 2019 21:32:12 UTC