W3C home > Mailing lists > Public > public-cognitive-a11y-tf@w3.org > September 2016

Re: Clarification on Minimize User Errors and Associated SC

From: Thad C <inclusivethinking@gmail.com>
Date: Sun, 11 Sep 2016 09:45:29 -0700
Message-ID: <CAOh2y+9rhtfLusBrd_rz+1wL=mzAHGt0_kbYRewRxOeaTyr_3w@mail.gmail.com>
To: "lisa. seeman" <lisa.seeman@zoho.com>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
Thanks for the feedback. I also made a Pull Request this morning that
resolved some of the typos and gave more info than this attached version. I
will incorporate your feedback in a new Pull Request this evening.

Best,
Thad
On Sep 11, 2016 9:35 AM, "lisa.seeman" <lisa.seeman@zoho.com> wrote:

> Thanks Thad. Great work
>
> Can everyone writing an SC read this feedback -- I think it will effect a
> lot of the proposals.
>
> *Issues 1: Take all the relevant info from the techniques document: *
>
> Did you look at the techniques document https://rawgit.com/
> w3c/coga/master/techniques/index.html
>
> there are lots of really good information and relevant techniques such as
>
> - Accept as many formats as possible, such as different ways of writing a
> phone number and date formats
> - Correct errors in the back-end, such as the post code being written in
> the text field with the city or state information
> Tests can then include ideas like:
> - conform that all common different ways of writing the information are
> accepted
>
> There are also pass and failure examples that are relevant and  also check
> the  Sources/research section
>
>
> *Issue 2: The benefits section must fully make the case for the change.*
>
> Also I do  NOT think we should re-iterate the  old information and
> benefits form wcag. We need to focus on  explaining the new material to
> them and explain why changes were needed. (You do not need to delete what
> you have copied but you do need to explain our position clearly as the main
> content of this section) For the next one, I would avoid coping over the
> benefits from WCAG as they already know that and it makes it less likely
> that we will fully explain our proposal.
>
> we have good evidence that usability studies shown people giving up when
> they receive too many errors, and the user  believe they can not complete
> the task.
>
> I think this is the key information  for the benefits section
>
> I would also remove the example on spelling as most users can handle that
> as a browser plugin, and so that is not a confincing example of why we need
> this
>
> Thanks again for all the hard work - the first ones are always the test
> cases...
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Sun, 11 Sep 2016 03:47:07 +0300 *Thad
> C<inclusivethinking@gmail.com <inclusivethinking@gmail.com>>* wrote ----
>
> Hi Lisa,
>
> I am working on splitting "Prevent the user from making errors" into three
> success criteria as noted on the volunteer page. I am clear on the first -
> Minimize User Errors (draft attached). Can you confirm that I am reading
> the reword table correctly and that the other two are:
>
> - Labels or Instructions
> - Identify Charges
>
> Thanks for your help.
>
> Thaddeus
>
>
>
>
>
Received on Sunday, 11 September 2016 16:46:39 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 11 September 2016 16:46:40 UTC