On Wed, May 6, 2009 at 6:37 PM, Matthias Clasen <[email protected]> wrote: > Adding gnome-accessibility-devel back to the CC... > > On Wed, May 6, 2009 at 10:15 AM, Eitan Isaacson <[email protected]> wrote: > >> There is the Firefox awesomebar, but I can't figure out how to activate >> the star/unstar and "subscribe to feed" functions through the keyboard. >> Does anybody? > > Well, the action is 'Bookmark this page', so Ctrl-D will work. I guess > that means they subscribe to the 'make the action available by other > means' as well... >
Yeah, but I wouldn't say they completely came through with that approach, since the subscribe icon does not have a keyboard shortcut. I am still waiting to hear from know-hows about any secret keyboard navigation tricks :) >> Although it might not be very sexy, I would consider putting the icons >> in the tab focus order. The example I draw from is an editable >> GtkComboBox. From a screen-reader perspective that is optimal since it >> wouldn't have to have special presentation exceptions, it will simply >> work by tracking focus as usual. >> >> This would of course entail the same implementation hardships as >> exposing them as accessible objects, since they are not widgets. > > Yeah. It is not inconceivable to let the entry have multiple focus > locations (like I did for the url label stuff), where you can tab from > the entry itself to the icons. > But it is not immediately clear to me that that would help the > screenreader, since from the outside it still looks like the same > widget has the focus, no ? > That is why I suggested a composite widget, each icon would be backed by a widget and accessible object. So the screen-reader would receive "focus:" events from accessibles with such names as "clear" and "search", and "push button" as roles. That way we could keep the same visual appeal, and ATs would be dealing with a very familiar animal (distinct push buttons in the conventional focus order). Another option would be having the icons be managed descendants of the entry object. This would mean finding a sensible keyboard gesture for navigating within the entry (first icon, text, second icon). Where the entry object would fire 'object:active-descendant-changed' events. Not unlike GtkTreeView's cursor navigation. I don't really think this option is great, just because it will be virtually indiscoverable to most users. >> >>> One idea I had in mind was to basically do this via guidelines: >>> >>> If you make an action available via an embedded icon, you should also >>> make it available in some other way, e.g. via the regular context menu >>> of the entry. >>> >>> We could also just do that automatically, I guess. >>> >>> Opinions ? >>> >> >> I like that. > > Ok, I can explore that idea. Filed as > http://bugzilla.gnome.org/show_bug.cgi?id=581605 > for now. > In my opinion having this would put us in pretty good shape. Although in the long run we should consider the options above. >>> > As to how it is exposed in GAIL, I think the icons should be exposed >>> > as children of the entry. Don't know how easy that would be since they >>> > are not backed by actual widgets. The reason for this being that each >>> > icon will need to expose it's state, alternative text, image interface >>> > and actions separately. >>> > >>> > A hackish alternative would be to give the entry more actions via the >>> > action interface that would be named after the tooltip of the icons. >>> > Besides being partial, this would also not meet the convention of not >>> > naming the action by it's result (an action should be called "click", >>> > not "search"). >>> >>> Would "click primary icon" and "click secondary icon" meet that condition ? >>> >> >> I think those two additional actions should be added to the entry's >> action interface in any case, with your suggested names. >> >> Where would the alternative text and tooltip string appear? "click >> secondary icon" alone would not be enough. > > Currently, the icons (optionally) have a tooltip, no 'alternative > text' or 'name'. We could add a property for that, if it would help > making these actions useful. > When you use stock icons in other places in GTK+ (like "gtk-print"), you get localized names for free in the accessible objects. So I guess they should be used, if available, in this API too. _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
