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
https://www.w3.org/WAI/GL/wiki/WCAG_2.2_Success_criterion_acceptance_requirements


G

*glenda sims* <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> 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
>
> [image: Minnesota IT Services Logo]
>
> [image: Facebook logo] <https://www.facebook.com/MN.ITServices>[image:
> LinkedIn logo] <https://www.linkedin.com/company/mn-it-services>[image:
> Twitter logo] <https://twitter.com/mnit_services>
>
>
>
>
>
>
>
> *From:* John Foliot <john.foliot@deque.com>
> *Sent:* Thursday, March 7, 2019 11:26 AM
> *To:* Alastair Campbell <acampbell@nomensa.com>
> *Cc:* lisa.seeman@zoho.com; Delisi, Jennie (MNIT) <
> jennie.delisi@state.mn.us>; COGA TF <public-cognitive-a11y-tf@w3.org>;
> Silver TF <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>
> 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>
>
>
>