Re: FileChooser's path bar and re-rooting

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]