Accessibility Considerations for Design Patterns

Michael S Elledge elledge at
Wed Aug 15 15:28:14 UTC 2007

Hi Greg--

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


Greg Gay wrote:
> Hi Mike
> Some coments regarding form accessibility, in addition to those listed
> on the Sakai wiki:
> 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?
> 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.
> greg
> PS. I've added these suggestions to the Sakai wiki as well.

Thanks for these great comments; please keep them coming!

> 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 (
>> and for
>> individual patterns like Drag and Drop
>> ( I've also added
>> a Design Pattern  Accessibility page
>> ( 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <>

More information about the fluid-work mailing list