Re: New draft of the review of UAAG 2.0

Thanks!

All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter




---- On Tue, 04 Feb 2014 22:23:51 +0200 Liddy Nevile<liddy@sunriseresearch.org> wrote ---- 

 > 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 Wednesday, 5 February 2014 06:41:23 UTC