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
begin:vcard
fn:Mike Elledge
n:Elledge;Mike
org:Michigan State University;Usability & Accessibility Center
adr:;;55 South Harrison Road;East Lansing;MI;48824-1022;USA
email;internet:[EMAIL PROTECTED]
title:Assistant Director
tel;work:5173538977
tel;fax:5174329541
url:http://usability.msu.edu
version:2.1
end:vcard
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
