Jaws and the Generic Lightbox Demo

Colin Clark colin.clark at utoronto.ca
Fri Aug 1 03:47:18 UTC 2008

Hey Mike,

On 31-Jul-08, at 10:47 AM, Michael S Elledge wrote:
> I'm not sure if there is a conventional way of identifying  
> contextual accessibility information--maybe all that's needed is the  
> "i" logo, with it being identified as "Accessibility Information" in  
> alt text and a title tag, or a help icon with similar treatment. Do  
> you think one or the other would be better?
> I guess this also raises the possibility of Fluid creating a special  
> icon for accessibility instructions if that's a road we want to go  
> down, although there seems to be a proliferation of symbols out  
> there already for other things that adds to clutter.

This is an interesting point. As our components get more complex,  
we're building in new and optimized experiences for assistive  
technology users. But with this comes a burden to help explain how to  
operate the controls. There's always a tension between doing it in the  
"standard" way and innovating, and it's always a judgement call. Easy  
access to help is one of the ways we can help graduate users into  
using the newer interactions.

It makes me wonder if we may eventually want to consider an inline  
help "meta-component" (to use Antranig's terminology), which can wrap  
other components and provide contextual help for them. Again, you'd  
want to be careful to make sure this was not too intrusive... I wonder  
how many people miss Balloon Help from the old System 7 days?

> Of course, having all the components behave consistently with  
> respect to keystrokes and functionality offers the greatest  
> potential for improving user experience. Maybe we should put  
> together a table that summarizes the keys, commands and  
> functionality for the Fluid components?

Consistency is definitely important. So is configurability. I really  
hope that we'll be able to offer users the ability to reconfigure  
keystrokes on the fly in the case of conflicts. The Reorderer's  
underlying code supports this currently, and it is slated to be a  
common feature of our component API in the 0.5 release.

PreferAble 2.0 will potentially provide the user interface for  
configuring keystrokes. I also hope that Greasemonkey or Accessmonkey  
might play a role in on-the-fly configuration of components for more  
technically-savvy AT users.

Just thinking aloud here,


Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto

More information about the fluid-work mailing list