Re: Gail next steps (was Re: GTK and ATK)

[Benjamin Otte <otte gnome org>]

Piñeiro <apinheiro <at> igalia.com> writes:

> 
> On 06/07/2011 05:06 PM, Emmanuele Bassi wrote:
> >
> >> 5) figure out new interfaces for GTK to expose necessary features to
> >> a11y (and other consumers, such as IM and OSK)
> > we should probably establish some common interfaces so that Clutter can
> > expose the same functionality for its own items — and so that embedding
> > a GtkWidget inside a Clutter scene graph doesn't break the AT tools.
> 
> Well, I thought that this common interface was ATK ;)
> 
Just to make my point very clear about what I mean here:

Nobody I know is using ATK to handle cursors and word detection inside a
PangoLayout. Nor should they. In fact, nobody should use ATK for anything but
implementing accessibility. Because, as it turns out, ATK does not do anything
but define such an interface.


Also, the point (5) you were looking here is about a fundamental problem with
how application developers handle accessibility. Hrm, I guess I'll try to use
ASCII art to explain it.
So this is my view about how it should work in the future and how I think most
developers see accessibility:

glib
 ^
 |
gtk/clutter -> atk/accessibility
 ^
 |
app

And this is how it works today and how I think most accessibility developers
think people develop applications:

glib
 ^
 |
gtk/clutter -> atk
         ^     ^
          \   /
           app

They expect application developers to interact with ATK directly and attach
useful properties to the accessible objects of the widgets they are using. 
This is how ATK works today.


Now, this is a fundamental difference. Because one approach assumes developers
must be knowledgeable about accessibility and actively handle it and the other
assumes they can usually be ignorant of it and pretend it will just work.

It would of course be nice if we could have the second approach because it 
leads to a way higher code quality. But it's also way worse in a non-ideal 
world where developers only care very little, like the current world. Because 
in this world an automatic accessibility framework could at least present an 
"ok" view of the app.


To give an example for what I mean:
It might be useful to add a function like gtk_label_set_is_labelling (label,
entry); might be useful. It would let people say "this label is labelling this
widget". And it would then proceed to do set the right relation automatically
behind your back.
Or we could have a gtk_widget_class_add_remote_action (switch_class, "toggle",
gtk_switch_toggle) which would allow this widget, similar to key bindings, to
expose a "toggle" action to remote listeners. It would also do the right thing
automatically using AtkAction.

What this would do, is to let people continue to be ignorant of accessibility,
but provide them with functionality inside GTK that they will probably find
genuinely useful for various things. And instead of painting this stuff into 
an accessibility corner, it'd be in the GTK corner. And people would find out 
about it when reading GtkLabel/GtkWidget docs, which they are a lot more 
likely to do than reading ATK docs.

Benjamin