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

[Eitan Isaacson <eitan ascender com>]

I didn't find any bugs open for these. I would be happy to play with a
few patches.

On Tue, May 5, 2009 at 11:39 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> On Tue, May 5, 2009 at 4:32 PM, Willie Walker <William Walker sun com> wrote:
>> Hi Matthias:
>>
>> Many thanks for being proactive about accessibility.  Do you have a small
>> demo app that shows these new features?
>
> Lets see, gtk-demo in GTK+ 2.16 has an example that covers many of the
> entry icon features, under  Entry > Search Entry.
>

Wow, it's an entry that does everything! The first question I have is,
does it have keyboard support?
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").

As for the embedded progress bar, I think adding a value interface to
the entry would be enough.

> For scale marks, you can look at the new pulseaudio-based
> gnome-volume-control in gnome-media 2.16. I don't think we have a
> readily available demo for that in GTK+ itself (I should fix that).
>

Need to look at that too.

> For label urls, I'll make sure to add an example when I merge that patch.
>

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.

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.

1. http://bugzilla.gnome.org/show_bug.cgi?id=417963

>
> Matthias
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>