Accessibility Considerations for Design Patterns

[Michael S Elledge]

Hi Greg--

Thanks for the good comments and for posting them on the wiki. My 
thoughts below.

Mike

Greg Gay wrote:
> Hi Mike
>
> Some coments regarding form accessibility, in addition to those listed
> on the Sakai wiki: http://confluence.sakaiproject.org/confluence/x/xn0
>
> Optional form focus is a great usability feature for AT users, provided
> it is used carefully, and is optional should a user decide not to want
> it. When the primary content of a page is a form, and the user is
> expecting a form, position the focus in the first field.
>   
This is new to me. Tell me more about optional form focus.
> Mike, do you mean left to right, top to bottom,  for the tab order?
>   
Yes.
> Careful with accesskeys, this is an ongoing issue, to which some
> accessibility advocates think they should be eliminated alltogether. 
> Really, only numbers are safe to use as accesskeys to ensure they won't
> conflict with AT or browser keys. The problem is really in the design or
> implementation of the HTML accesskey element, which should allow user
> agents (browsers or AT) to be distinguished from Web applications.  I'm
> currently doing a review of Plone. They have created accesskeys that use
> both the ctrl and alt keys, in addition to the assigned key, which seems
> to get around the problem of conflicting keys
>   
Accesskeys are indeed an open issue, and I'm torn about their 
usefulness. There is a set of numerical keys that's been proposed by the 
UK Gov't e-Commerce group, but they target general content areas (like 
Help and News) and don't address controls. It's too bad there isn't more 
consistently in how browsers treat them; you can avoid the conflict in 
IE by pressing alt + letter concurrently for the web page. Alt + shift + 
the letter works for Firefox. Pressing alt + letter separately for the 
browser works for both. But I don't know how many screen reader users 
know that. You can also go to buttons on a page by pressing "b" with 
JAWS, but likewise don't know how many screen readers know that. <sigh> 
Suggestions on how to proceed with this?
> Rather than listing the accesskeys early in the page, which requires
> memory, include the accesskey in the title text associated with a
> control.  Some people with cognitive or learning disabilities may not
> otherwise be able to remember the keys after a few moments.
>   
Absolutely right; should be part of the accessibility list and standard 
operating procedure.
> Re Daphne's note: I might add to Daphne's comment about using coloured
> form fields,  to change the colour when a field recieves focus, so for
> low vision users its easier to find ones place in the page by finding
> the field whose colour differs from the others. This strategy can also
> be used for links, to make it easier to follow the cursor as one tabs
> through the page.
>   
Good suggestion.
> Re Kathy's note about feedback, this is an important part of making
> forms usuable for screen reader users. Both error and success feedback
> needs to be provided. Error feedback is obvious. If a required field is
> left empty for example,  a screen reader needs to know this early when
> the page reloads after submitting the form (or before using js alerts
> etc). There are a variety of ways to deal with error feedback, but most
> universal is dynamic tabindex, the first leads to the feedback message,
> the second to the first incorrect field, the second to the second
> incorrect field, etc. Or, focus could be sent directly to the problem
> field which would include the appropriate error message as title text
> for the form element. There are lots of other means of making error
> feedback usable by AT, but the gist is make the feedback and the problem
> field easy to navigate to.
>
> It's also important to include success feedback after a form has been
> submitted without errors. Without it AT users can be left wondering if
> the form was successfully submitted. Without success feedback it can be
> a labourious job for an AT user to confirm the form submission was
> successful.
>   
Absolutely!
> greg
>
> PS. I've added these suggestions to the Sakai wiki as well.
>   

Thanks for these great comments; please keep them coming!

Mike
> Michael S Elledge wrote:
>
>   
>> Hi Everyone--
>>
>> I've started reviewing and supplementing accessibility information for
>> the design patterns. I'm pursuing it at two levels, for categories
>> like Forms and Navigation (
>> http://confluence.sakaiproject.org/confluence/x/xn0) and for
>> individual patterns like Drag and Drop
>> (http://confluence.sakaiproject.org/confluence/x/Xrc). I've also added
>> a Design Pattern  Accessibility page
>> (http://confluence.sakaiproject.org/confluence/x/BgAX) that will
>> contain a full list of accessibility recommendations, with links from
>> the Design Pattern Format and design pattern pages.
>>
>> I'll keep plugging away off and on, but it would be great to have your
>> feedback in the meantime, when you have a chance. My apologies if I've
>> misinterpreted an earlier addition.
>>
>> Thanks!
>>
>> Mike
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>>  
>>
>>     
>
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070815/148b15c9/attachment.vcf>