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

[Matthias Clasen <matthias clasen gmail com>]

On Wed, May 6, 2009 at 4:39 AM, Eitan Isaacson <eitan ascender com> wrote:

>
> Wow, it's an entry that does everything!

Indeed. I had toyed with the idea of codenaming 2.16 "big entry" ...

> The first question I have is, does it have keyboard support?

Not really. What kind of keyboard support would you envision, keybindings to
- activate the first icon
- activate the second icon
- open the first icons menu
- open the second icons menu
?
I didn't anything for that yet. Is there any prior art for keynav of this kind ?
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 ?


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


> If the link is an actual URL that a browser opens, a hypertext
> interface with a list of offsets and URLs would be good enough. If on
> the other hand a link could fire an arbitrary callback, we might have
> to have a separate action interface for each link, which means
> breaking up the label accessible into child link accessibles, sort of
> how firefox does it.

The default action is to run an external handler via gtk_show_uri, but
you can intercept the ::uri-activate signal and do your own custom handling
if you need. Not sure what that means in terms of a11y interfaces.

In general, I think hypertext sounds about right. I think I got the
keynav for this about right, similar to caret browsing in firefox.

> This reminds me of a bug[1] I filed a while ago about hyperlinks in
> GtkTextView, in general they are made from scratch by devs. It would
> be nice if like GtkLabel, they would be part of the toolkit, so that
> we could provide the proper a11y hyperlink interfaces. Matthias, you
> suggested a derived class, and I agree.

Yeah, it is funny that gtklabel will have much better hyperlink
support than gtktextview when that patch lands. One of the future
improvements is to make it less hackish by making pango marking
extensible and define a 'link' attribute. When that happens, it should
be possible to make gtktextview support 'link' attributes out of the
box, too.

Matthias