Accessibility Considerations for Design Patterns
g.gay at utoronto.ca
Wed Aug 15 14:14:55 UTC 2007
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.
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
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.
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.
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
PS. I've added these suggestions to the Sakai wiki as well.
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.
>fluid-work mailing list
>fluid-work at fluidproject.org
More information about the fluid-work