Re: This is significantly different from what was agreed. - was Re: CFC: Manual testing processes

I'm a little concerned that this discussion could unnecessarily get out 
of hand.
Just to recap. The original CFC originated after a WG discussion that 
centered on pushback around making user testing a requirement. While the 
chairs are (often painfully) aware of unintended consequences I still 
fail to see what the problem is with this CFC.

Lisa said (referring to a comment from AWK):
"that if the only way to test a success criteria is to conduct user 
testing, then that is not “testable” with regard to WCAGT 2.1. "

In terms of our standard this is correct and should be maintained, 
however it may not always be proven to be true - especially as 
technology progresses. For example,  taking the context of Lisa's 
example of passive vs active voice. This is something that may have 
required testing in the past - and ideally should be tested with real 
users but, it could be tested with (nascent) AI tools etc a la Watson etc.

<chair hat off>

As an aside, IMO these kinds of suggested SC around active/passive voice 
could be better as a recommendation and not an SC requirement in the 
first place.

Also I'm thinking that user testing spans many disability groups/cohorts 
and not just COGA. So actually this discussion has piqued a vague 
concern about an unintended potential negative bias against user testing 
with other groups. I'd hate that would happen as a result of something 
that may be better as a best practice or recommendation - and not an SC 
in the first place.
</chair hat off>

Thanks

Josh



> Alastair Campbell <mailto:acampbell@nomensa.com>
> 15 February 2017 at 15:48
>
> Hi Lisa,
>
> I haven’t seen the note, presumably that outlines how to do it well?
>
> I don’t think it can address the point that including 
> usability-testing for exceptions essentially means it is included. 
> Logically, you cannot use the exception unless you can stop and do 
> usability testing.
>
> If anyone assumed that this CFC didn’t include exceptions, please 
> speak up, otherwise there’s no point going through 20 +1s again…
>
> -Alastair
>
> *From: *"lisa.seeman" <lisa.seeman@zoho.com>
>
> Hi Alistar
>
> We had an note on user testing. we ran into some copyright questions 
> but we will get it published soon. We completely need to recommend 
> what is included in user testing - but we were hesitant to make that a 
> normative definition.
>
>
>
> lisa.seeman <mailto:lisa.seeman@zoho.com>
> 15 February 2017 at 14:57
> Hi Alistar
>
> We had an note on user testing. we ran into some copyright questions 
> but we will get it published soon. We completely need to recommend 
> what is included in user testing - but we were hesitant to make that a 
> normative definition.
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter 
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Wed, 15 Feb 2017 16:51:56 +0200 *Alastair 
> Campbell<acampbell@nomensa.com>* wrote ----
>
>
> Alastair Campbell <mailto:acampbell@nomensa.com>
> 15 February 2017 at 14:51
>
> > The resolution implication is different to what was discussed. We CAN 
> NOT pass the resolution if this implication does not allow for 
> exceptions via user testing
>
> I had assumed that it applied to exceptions.
>
> Even if you didn’t, that is how it would apply in practice as 
> otherwise you would have to run usability testing anytime you 
> **might** need to use an exception.
>
> In the case of the Plain Language SC, the effect is that you have to 
> use the active voice unless you are prepared to run usability testing.
>
> And that doesn’t even get into the issues of running a good session to 
> prove a particular point.
>
> E.g. You can’t ask a participant whether they understand the passive 
> voice version, you need to ask them to complete a task that requires 
> that they understand the passive voice in that instance. Then you need 
> to work out if it was the text or other factors of the interface that 
> mattered, and whether you have representative participants, and how 
> many people is enough…
>
> -Alastair
>
> lisa.seeman <mailto:lisa.seeman@zoho.com>
> 15 February 2017 at 13:15
> The resolution implication is different to what was discussed. We CAN 
> NOT pass the resolution if this implication does not allow for 
> exceptions via user testing at least without a real discussion so we 
> all understand what is at stake
>
> We agreed we were not making user testing a requirement for conformance.
>
> This implication is significantly different and changes things.
>
> User testing was ok to enable an exception. In other words it is not 
> required, but you can claim an exception via use testing.
> For example use active voicing unless user testing with five people 
> with cognitive disabilities has shown passive voicing to be clearer.
>
> This implication has not been discussed . The vote is meaningless if 
> this "implication" has nt been fully understood by everyone voting
>
> This add be shown to be
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter 
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Wed, 15 Feb 2017 08:59:19 +0200 
> *Chakravarthula<srchakravarthula@informatica.com>* wrote ----
>
>
> Chakravarthula, Srinivasu <mailto:srchakravarthula@informatica.com>
> 15 February 2017 at 06:59
> +1
>
> Regards,
> Srinivasu Chakravarthula | Informatica | @CSrinivasu
> Sent from my iPhone
>

-- 
Joshue O Connor
Director | InterAccess.ie