Designing for assistive technologies (was Re: Screen Reader Testing Needed)
colin.clark at utoronto.ca
Wed Sep 10 18:22:33 UTC 2008
The guidelines Allison cites below are a nice starting point for
thinking about information architecture. They don't really cover
behaviour, however, which is central to Fluid components. Real
interaction design thinking is still very new on the Web. There's a
real opportunity for us to think deeply about the design of accessible
interactions, and to really innovate.
Spending time with a variety of assistive technology users will be
immensely useful for the design team. You'll get a feel for the broad
range of needs, styles, and approaches. We've also got a number of
experts lurking on this list who can offer their advice.
At its heart, Fluid's philosophy for accessibility is to ensure users
can tailor their environment for their unique needs. Consider the
range of different users and technologies out there. By nature,
assistive technologies are design to re-work or re-present your user
interface in all sorts of different ways. So when you're designing for
accessibility, you're not just designing for one screen reader or
You can't control the experience in quite the same way that you might
be accustomed to. Your UI may get transformed, modified, or adapted
after you've created it. So for a screen reader, you can't script the
word-by-word experience. Think instead about the information and
options that your user interface offers, and how you can ensure that
they are available and clearly communicated in a variety of modes.
Designing keyboard navigation is an interesting topic. I think the
best approach is to design in layers, because there are several
different use cases to juggle simultaneously. Screen reader users tend
to navigate with the keyboard as a means to explore the user
interface. Keyboard focus becomes a way to say "What's here? What can
I do with this user interface?" On the other hand, sighted users who
rely on an on-screen keyboard may have a heightened concern for
efficiency. They want to get at their target quickly. These two modes
are often at odds in the design process, and no one way is better for
all. We have an opportunity to innovate by letting users customize
their choice of keyboard navigation style, and this is a feature I
hope to offer within PreferAble for Infusion 0.6.
One interesting resource to check out: the DHTML Style Guide. This is
created by a group related to the ARIA effort, and specifies keyboard
interactions for dynamic widgets on the web. Here is the current draft
of their style guide:
Fluid is represented on the Style Guide committee through Joseph
Scheuhammer's involvement (thanks Joseph!). I will be honest in saying
that I have some reservations about the work of the committee so far,
since it's dominated by technologists rather than designers. They tend
to work too quickly, making decisions based on the status quo; usually
how it's done in Windows. Nonetheless, it's a hard and unenviable job
to create a style guide that pleases everyone, and I think they're
doing a good job.
I'd recommend that we use the DHTML Style Guide as a baseline for
coming up with Fluid component keyboard interactions. But there's huge
room for creative thinking and innovation, so we should ask questions
and do some quick testing of their recommendations. It's really
important for Fluid to take a leadership role in thinking through
great new interactions for people with disabilities. I think the
Reorderer was a first example of how, when we think about context,
drag and drop can be made significantly easier.
I hope this helps,
On 9-Sep-08, at 8:48 PM, Allison Bloodworth wrote:
> Guideline 1. Write for the web.
> Guideline 4. For designers and developers of Web sites: Make the
> site structure clear and obvious.
> Guideline 6. Write "home page" as two words.
> Guideline 7. Do not make up unusual names for products, services, or
> elements of a Web site. Do not combine two or more words into one
> Guideline 10. Include a "skip" link at the top of every Web page.
> Name it "Skip to main content."
> Guideline 11. Make links descriptive. Be sure that the link will be
> useful by itself, with no surrounding text. Do not use "click here,"
> "more," "answer," or other repetitive words or phrases as links.
> Guideline 12. Start links with relevant keywords.
> Guideline 13. Try not to have many links that start with the same
> word or phrase.
> Guideline 14. Start question headings with a keyword followed by the
> question. (e.g. Literacy – What is it?)
> Guideline 15. Pay attention to the wording on pages and be sure that
> keywords that users would look up are actually on the page.
> Guideline 16. Make sure that the keywords are not in images.
> Guideline 20. Use anchor links when a page has several topics.
> Guideline 22. Encourage authors to use many headings in their
> content and to be sure that those headings are clear, meaningful,
> and parallel.
> Guideline 24. Put the keyword at the beginning of the heading. If
> many headings are about the same thing, differentiate them in
> meaningful ways.
> Guideline 25. Do not put a lot of text on the same page as a form.
> Guideline 26. Do not put a form far down on the page or far to the
> Guideline 28. In addition to checking your site with an automated
> tool like Bobby or LIFT, listen to it with a screen reader.
> Guideline 29. Do not put information between fields on a form.
> Guideline 30. If the user has an option of filling out either of two
> fields, and they are mutually exclusive, inform the user with the
> label of the first field.
> Guideline 31. Do not exclude labels from fields.
> Guideline 32. Avoid making pages refresh.
> From: "Usable Accessibility Group" Tutorial (created a group of i-
> Schools students at UC Berkeley -- much more specific info is found
> under the link to each point)):
> 4. Provide a "skip" link to bypass repetititve page content such as
> a navigation menu
> 5. Make link names more informative than "click here"
> 6. Provide high color contrast for students with low-vision
> 8. When designing a form, ensure that the prompt precedes the input
> 9. Segment long lists using structured and consistent headings
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
More information about the fluid-work