- From: Steve Lee <stevelee@w3.org>
- Date: Fri, 8 Mar 2019 08:38:11 +0000
- To: public-cognitive-a11y-tf@w3.org
[@Goodwitch nice to have you back ] +1 That's crystal clear and seems fair. I agree that some large pages, especially infinity scrollable ones, require testing shortcuts such as a sample of elements that represent possible the "styles". Otherwise any testing will hit realistic time constraints. Nit: 'ELEMENT' might not be the right word given it's quite specific use in HTML. But I don't have a better suggestion; component is also overloaded. Steve On 07/03/2019 21:02, Glenda Sims wrote: > 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: > o Automated - an automated testing tool exists that quickly and > accurately determines if the criteria is met or not. > o Assisted - a software tool exists that makes it more efficient > for a tester to accurately determines if the criteria is met or > not. > o 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 > https://www.w3.org/WAI/GL/wiki/WCAG_2.2_Success_criterion_acceptance_requirements > > > G > > *glenda sims* <mailto:glenda.sims@deque.com>, cpacc > <http://www.accessibilityassociation.org/certification> | team a11y lead > | 512.963.3773 > deque systems <http://www.deque.com> accessibility for good > > > On Thu, Mar 7, 2019 at 1:31 PM Delisi, Jennie (MNIT) > <jennie.delisi@state.mn.us <mailto:jennie.delisi@state.mn.us>> wrote: > > Hello,____ > > 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____ > > __ __ > > *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/ | mn.gov/mnit > <http://mn.gov/mnit>____ > > Minnesota IT Services Logo____ > > Facebook logo <https://www.facebook.com/MN.ITServices>LinkedIn logo > <https://www.linkedin.com/company/mn-it-services>Twitter logo > <https://twitter.com/mnit_services>____ > > __ __ > > __ __ > > __ __ > > *From:*John Foliot <john.foliot@deque.com > <mailto:john.foliot@deque.com>> > *Sent:* Thursday, March 7, 2019 11:26 AM > *To:* Alastair Campbell <acampbell@nomensa.com > <mailto:acampbell@nomensa.com>> > *Cc:* lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>; Delisi, > Jennie (MNIT) <jennie.delisi@state.mn.us > <mailto:jennie.delisi@state.mn.us>>; COGA TF > <public-cognitive-a11y-tf@w3.org > <mailto:public-cognitive-a11y-tf@w3.org>>; Silver TF > <public-silver@w3.org <mailto:public-silver@w3.org>> > *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.____ > > __ __ > > JF____ > > __ __ > > On Thu, Mar 7, 2019 at 10:52 AM Alastair Campbell > <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> 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.____ > > ____ > > Cheers,____ > > ____ > > -Alastair____ > > ____ > > ____ > > 1] Accessibility example for what should be a ‘simple’ thing, > the naming algorithm.____ > > https://www.linkedin.com/pulse/future-accname-spec-planning-strategy-functional-using-garaventa/ > <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fpulse%2Ffuture-accname-spec-planning-strategy-functional-using-garaventa%2F&data=02%7C01%7Cjennie.delisi%40state.mn.us%7C2a94ca2523bb46a0bdd208d6a321fd94%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875763714627907&sdata=VCYgFIjR5CMjFxunizRlfRp8QYNbGpWZR8Sb6OmhcQI%3D&reserved=0> > ____ > > > ____ > > __ __ > > -- ____ > > ***John Foliot* | Principal Accessibility Strategist | W3C AC > Representative > Deque Systems - Accessibility for Good > deque.com > <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdeque.com%2F&data=02%7C01%7Cjennie.delisi%40state.mn.us%7C2a94ca2523bb46a0bdd208d6a321fd94%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875763714637908&sdata=GG0O3iMQp%2F8PHf6p8EWzegAcg%2FBpQuuSttIJLwi6EbA%3D&reserved=0>____ > > __ __ >
Received on Friday, 8 March 2019 08:38:14 UTC