Re: [g-a-devel] accessibility of new GTK+ features

[Eitan Isaacson <eitan ascender com>]

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
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.