Re: FileChooser's path bar and re-rooting
- From: Bill Haneman <Bill Haneman Sun COM>
- To: gtk-devel-list gnome org
- Subject: Re: FileChooser's path bar and re-rooting
- Date: Tue, 16 Mar 2004 10:54:55 +0000
Without repeating a lot of points that have already been made, I do want
to say that a number of accessibility (actually accessibility/usability
concerns) have arisen about the new file chooser from the POV of a11y
folks I've been talking to.
I think the main problems are with discoverability (the "familiarity"
issue of diverging from previous practice is important too, but not the
overriding concern).
I believe (at least I sincerely hope!) that we are agreed on the need to
enable an entry box in the file chooser, and to enable distinction
between different "sub paths" when descending into directories; these
are key capabilities which need to be retained even if they no longer
form the dominant user model.
So the issue is discoverability; relying on keyboard shortcuts or
configuration settings is not IMO sufficient. In our GUI environment we
rely on clues (visual and otherwise) to remind/inform the user that
supplementary or alternative presentation or interactions are
available. This is important for accessibility too; "hidden" options
tend to be not-very-accessible ones.
How to fix this? For instance
* instead of exposing the text entry only on key-shortcut, provide a UI
element (button, etc.)
that invokes drop-down
* provide a toggle-able UI element that exposes the "whole" path, either
literally or via some virtualized
labelling system
(i.e. instead of /export/home/joe and /dev, "Joe's Home" and
"System/Devices"
if you really want to get away from literal paths).
* put these UI elements into the focus chain, so that they are readily
discoverable by blind users
* either subclass them from existing GtkButton/etc. or implement
AtkAction on them, so that
assistive technologies like GOK can provide direct access to their
feature.
I believe this would be better for all users since it would
* extend the point-and-click metaphor to the "full path" and even
(except for the text entry process itself) the entrybox features;
* make the features "self documenting" (not sure I really believe in
that term, but OK... ;-)
* make the features more accessible and consistent with the rest of the
accessibility support structure.
The only downside that I see is that adding these buttons would extend
the TAB chain, but I think the existing shortcuts would mitigate any
impact on keynav efficiency, and good labeling of the UI elements could
make those shortcuts more easily discovered.
- Bill
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]