- 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<inclusivethinking@gmail.com> 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. 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, Twitter ---- On Sun, 11 Sep 2016 03:47:07 +0300 Thad C<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 Monday, 12 September 2016 07:20:59 UTC