- From: Thad C <inclusivethinking@gmail.com>
- Date: Sun, 11 Sep 2016 09:45:29 -0700
- To: "lisa. seeman" <lisa.seeman@zoho.com>
- Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
- Message-ID: <CAOh2y+9rhtfLusBrd_rz+1wL=mzAHGt0_kbYRewRxOeaTyr_3w@mail.gmail.com>
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