My answers for the wcag process and cryteria survey

Here are my answers for https://www.w3.org/2002/09/wbs/35422/wcag22process2/



Note we only have one day left to complete the survey!! 



If we do not have enough comments then this is the possess for wcag 2.2


for question 2 - 2. WCAG 2.2 Working Process



My main issue is it is two easy to object. Each objection need to be publicly logged  - maybe as an issue, so public and the taskforce can publicy answer the issue. you should not be able to rais an objection just before the "time out".

Objections should directly relate to an acceptance criteria.

Objections should be verified as true. In otherwords an objection will not stand because someone does not understand the user need or the technology involved.

I dont think a two week sprint is enough. 1 every two weeks will be hard enough. 

There needs to be a commitment from the working group to address the user need. not just throw them out. I dont think the next draft should be released without addressing user needs adequately




for 3. WCAG 2.2 Success Criterion Acceptance Criteria





Avoid creating a requirement for something that is already required by an existing Success Criterion. - this should be changed to 

Avoid creating a requirement for something that is already fully required by an existing Success Criterion of the same conformance level or higher.



Provide consistent results from different testers. This can be assessed through inherent logic or proven through examples.

should be

Provide typically consistent results from a majority of diffrent testers. This can be assessed through inherent logic or proven through examples.

(we should not require a higher standard for this round then for 2.0 - espicaily as coga was not included)



Be testable through an automated process or by a manual process conducted by an individual evaluator, and any tools required to test it are available prior to Candidate Recommendation stage.

This is impossible becuse people will only invest in tools if they know that it will be in the specification!

So it should be

Be testable through an automated process or by a manual process conducted by an individual evaluator, and any ALGORITHM  tools required to test it are available prior to Candidate Recommendation stage.



Apply to all content across all websites unless preconditions for the application of the success criteria are explicitly identified (e.g. "except interruptions involving an emergency").

should be



Apply to the vast majority of content across all websites unless preconditions for the application of the success criteria are explicitly identified (e.g. "except interruptions involving an emergency").

(IE we dont though out a user need becuse of "self programible routers!)



Apply across technologies to the greatest extent possible

should be

Apply across technologies to the greatest reasonable  extent possible



When a Sc is removed a new one SHULL be created to adress the user need!



I dont realy agree with the approach. We need the focus on making sure we include the user need for accessible content, not on why we reject them





This section should be removed... A New Success Criterion can be added to the Editor's Draft when the following are met and approved by the Working Group - it is a ton of work when you might just exclude it!



Not require testing that is believed to require very large manual efforts. should be

Not require testing that is believed to require very large manual efforts that can not be replaced by a known algorithm or tool (The tool does not need to be ready at the time we go to CR)





All the best



Lisa Seeman



http://il.linkedin.com/in/lisaseeman/, https://twitter.com/SeemanLisa

Received on Monday, 8 April 2019 10:15:29 UTC