Designing for assistive technologies (was Re: Screen Reader Testing Needed)

[Colin Clark]

Hi all,

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  
experience.

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:

http://dev.aol.com/dhtml_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,

Colin

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  
> name.
> 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  
> right.
> 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  
> impairments
> 8. When designing a form, ensure that the prompt precedes the input  
> selector
> 9. Segment long lists using structured and consistent headings

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org