W3C home > Mailing lists > Public > public-uaag2-comments@w3.org > February 2014

UAAG 2.0 review

From: lisa.seeman <lisa.seeman@zoho.com>
Date: Wed, 05 Feb 2014 09:36:07 +0200
To: <public-uaag2-comments@w3.org>
Cc: Kelly Ford <Kelly.Ford@microsoft.com>, "jeanne" <jeanne@w3.org>, "Jim Allan" <jimallan@tsbvi.edu>, "public-cognitive-a11y-tf" <public-cognitive-a11y-tf@w3.org>
Message-Id: <14400ed63a3.7059438041027986252.-6612146242344111066@zoho.com>
Hello UAAG.

Here the review of UAAG 2.0 "Principle 3" from the Cognitive Accessibility Task Force. 

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 and is supported, then 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 then 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.  Tooltip 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 tooltips on all icons, jargon and shortened forms such as abbreviations. Typically these tooltips should be one or two words long. Tool tips in HTML can be provided via the title tag. 
 (You many also want to indicate that the tooltip should be or at least include the accessible name, so that those who use voice control can use the tooltip to discover the accessible name)


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








All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter
Received on Wednesday, 5 February 2014 07:39:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:39:39 UTC