Jaws and the Generic Lightbox Demo

Michael S Elledge elledge at msu.edu
Fri Aug 1 14:55:57 UTC 2008

Hi Colin--

Colin Clark wrote:
> 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?
I think you're on the mark about contextual help. Generalized help 
screens are a real pain for persons with disabilities, since they are 
yet another page to be read or searched. The more often we can provide 
the information people need at the moment they need it the better.
>> 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.
I don't know how often AT users re-configure their keystrokes; my hunch 
is that it isn't very often except among expert users. Instead I've 
observed they pound away, trying out different techniques (tabs, arrows, 
virtual cursor on/off) to try to get something to work. Nonetheless, if 
we're able to make it easy for them to tailor our application to their 
AT (JAWS, Window-Eyes, ZoomText) it would be a big win. How about 
putting a switch in PreferAble (or whatever "holds" the widgets) to 
enable them to employ familiar keystrokes from their ATs to use the 
widgets? This could also be helpful for persons not wanting to fully 
customize their environment.
> Just thinking aloud here,
> Colin
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080801/00ef95d2/attachment.vcf>

More information about the fluid-work mailing list