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

Re: Clarification on Minimize User Errors and Associated SC

From: lisa.seeman <lisa.seeman@zoho.com>
Date: Mon, 12 Sep 2016 10:20:29 +0300
To: Thad C <inclusivethinking@gmail.com>
Cc: "public-cognitive-a11y-tf" <public-cognitive-a11y-tf@w3.org>
Message-Id: <1571d42eba6.10f85765823025.462190191397552155@zoho.com>
Thanks Thad!

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Sun, 11 Sep 2016 19:45:29 +0300 Thad C&lt;inclusivethinking@gmail.com&gt; wrote ---- 

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.
 On Sep 11, 2016 9:35 AM, "lisa.seeman" &lt;lisa.seeman@zoho.com&gt; 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, Twitter

---- On Sun, 11 Sep 2016 03:47:07 +0300 Thad C&lt;inclusivethinking@gmail.com&gt; 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.



Received on Monday, 12 September 2016 07:20:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 12 September 2016 07:21:00 UTC