- From: Liddy Nevile <liddy@sunriseresearch.org>
- Date: Wed, 5 Feb 2014 07:23:51 +1100
- To: "lisa.seeman" <lisa.seeman@zoho.com>
- Cc: "public-cognitive-a11y-tf" <public-cognitive-a11y-tf@w3.org>, Kelly Ford <Kelly.Ford@microsoft.com>, "jeanne" <jeanne@w3.org>
looks very good :-) Liddy On 04/02/2014, at 5:42 PM, lisa.seeman wrote: > > Here is the new draft for the review of UAAG 2.0 "Principle 3". See > http://www.w3.org/TR/UAAG20/ If we do not have any objections we > will submit this as our recommendations in 24 hours. > > We have done the review by each guideline. > > Guideline 3.1 - Help users avoid unnecessary messages > Recognized messages that are non-essential or low priority > > We think this is excellent but can be open to misinterpretation. > Authors will add content that is important to them (the author) but > not important to the user, > Examples include: Additional offers; how to upgrade to a more > expensive option; downloading a toolbar etc. > It should also be broader such as: > > Help users avoid and identify content that is not necessary to the > task they are trying to perform. > > > 3.1.1 Reduce Interruptions: > > The user can easily avoid or defer: > • Messages and content that are non-essential or low priority for > the user > • Messages, features and content that are not part of the core use- > cases for the content. > • Information in the user agent user interface that is being > updated or changing > • Rendered content that is being updated or changing > > Also we think it needs to be easy to do this - not just possible. So > maybe add > To ensure that it is easy to avoid or defer this content it should: > • Be not more then two steps, Such as: One step to select avoid or > defer them and a conformation step. > • Only simple and clear text and symbols should be used in controls > to avoid or defer this content > • Controls to avoid this type of content should be positioned above > or next to the content that it refers to. > > Also the group is working to identify semantics that would make it > possible to handle this as an adaptive interface at the user end. If > this becomes possible that it would be an acceptable alternative to > make sure the Messages and content that are non-essential or low > priority for the user and Messages, features and content that are > not part of the core use-cases for the content can be > programmatically identified. > > Guideline 3.2 - Help users avoid and correct mistakes > > Suggestion : > Filling in information is much slower and harder for people with > cognitive disabilities. Therefore: > > Information should be easily retrievable such as via automatically > saving the work so far. > The user should be able to go back a step without losing what they > have submitted. People with cognitive difficulties often have very > low confidence in the accuracy of what they are submitting and > therefore the ability to review and amend easily is important. > > Also authors and agents should never try to confuse the user. For > example, the users original selection / choice / offering should be > selected by default not switched to the item they want to up-sell , > such as expensive options being placed before the cheaper option > that the user thinks they are selecting. (Obvious but worth > spelling out anyway...). An example of this would be AVG antivirus > that switches the user to premium edition and leaves it to the user > to switch back. > > We would like to include: > • The original offering/selection should be selected by default and > should not be switched automatically to an alternative > > If this is not acceptable maybe include: > > Label any alternatives clearly > Make it easy to select the original offering: > • The original offering should be positioned above or next to the > alternative > • The original offering should be sized the same or bigger then the > the alternative > In the future we may have the semantics that would make it possible > to handle this as an adaptive interface at the user end. If this > becomes possible that it would be an acceptable alternative to make > sure the original selection can be programmatically identified. > > Guideline 3.3 - Document the user agent user interface including > accessibility features > > Firstly , it should always be easy to ask / get help. Therefore: > > • Help icon should be available to every screen that takes the user > directly to relevant "how to use these features" or instructions > • Symbol for help should be used (such as a question mark) or the > world "help" > • Getting help should not be hidden. For example it should not be > under a menu of options. Any steps needed to get to help should have > the word help or the question mark symbol clearly in it (such as > "options and help"). > Help text for core user tasks and main or essential features should > be easy to understand. > • Help should be available in simple and clear text. > • Each step should be identified and labeled. > • Pictures that clarify what to do are recommended . > We also would want to see a layered approach to help. Tool tip help > is a wonderful memory aid for clarifying what user features are and > particularly useful for people with an impaired working memory. We > would add: > > Include short tool tips on all icons, jargon and shortened forms > such as abbreviations. Typically these toll tips should be one or > two words long. Tool tips in HTML can be provided via the title tag. > > Finally We are just starting the task force and do not have > consolidated advice yet. We are anticipating identifying semantics > for the user to be able to use their preferred symbol set across > multiple applications. Therefor, if possible, recommend that > > • When possible make, sure the meaning and role of all interface > components can be programmatically identified > • Additional proposals by the cognitive accessibility task force > be incorporated. > > > > All the best > > Lisa Seeman > > Athena ICT Accessibility Projects > LinkedIn, Twitter > >
Received on Tuesday, 4 February 2014 20:24:30 UTC