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

[Matthias Clasen <matthias clasen gmail com>]

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

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

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

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

>> In general, I think hypertext sounds about right. I think I got the
>> keynav for this about right, similar to caret browsing in firefox.
>
> So the hyperlinks are activated by arrowing to them and pressing return?
> No tab focus? That is probably a good thing, for simplicity.

You can use cursor navigation to move the text cursor into a link (for
selectable labels only, since there is no text cursor in
non-selectable labels). You can also
tab-navigate through the links. That works, regardless of selectability.