Re: [g-a-devel] accessibility of new GTK+ features
- From: Eitan Isaacson <eitan ascender com>
- To: Matthias Clasen <matthias clasen gmail com>
- Cc: accessibility mailing list <gnome-accessibility-devel gnome org>
- Subject: Re: [g-a-devel] accessibility of new GTK+ features
- Date: Thu, 7 May 2009 11:31:24 +0300
On Wed, May 6, 2009 at 6:37 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> Adding gnome-accessibility-devel back to the CC...
> On Wed, May 6, 2009 at 10:15 AM, Eitan Isaacson <eitan ascender com> 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
>>> 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
> 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.
] [Thread Prev