Re: FileChooser's path bar and re-rooting

[Bill Haneman <Bill Haneman Sun COM>]

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