Re: [g-a-devel] Gail next steps (was Re: GTK and ATK)

[Piñeiro <apinheiro igalia com>]

On 06/09/2011 06:45 PM, Benjamin Otte wrote:
> Piñeiro<apinheiro<at>  igalia.com>  writes:
>
> > > > 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.

From the accessibility POV, it is required a way to get the cursor 
position and the word detention. But I agree that it shouldn't go into 
detail to PangoLayout, as ATK should be seen in a more abstracted level. 
Is this is what you are saying, in summary I agree.

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

FWIW, our ideal target is getting your first diagram with ATK. Probably 
you are saying that due this link:

http://developer.gnome.org/accessibility-devel-guide/stable/gad-coding-guidelines.html.en

As it includes some advices for app developers, using atk calls. But 
those are only required if the app doesn't some common gtk guidelines:

For example:
  * On GTK, we use the tooltip as the accessible description. So the 
guide says that if you don't provide a tooltip, you can set it by hand
  * Setting relations: a lot of atk relations are already set 
automatically (see below)

But in general, our advice is use the tools that the toolkit already 
provides.

In general, app developers will require to know about a11y/ATK if:
  * If you don't follow the common toolkit guidelines to ensure that 
your app is accessible
  * If you create a new custom widget

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

Well, yes that's the idea, but IMHO sometimes they would require to 
follow some guidelines.

I would like use OCRFeeder as an example. Joaquim made some changes to 
improve the a11y support [1][2]. On those he didn't require to add any 
atk call, just use common guidelines of how use gtk (add mnemonics, 
check keyboard navigation, check container hierarchy).

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

This is already being done, with the mnemonics. GailWidget takes the 
list of mnemonics (gtk_widget_list_mnemonic_labels) and set the proper 
relations automatically behind your back.

Not sure if the problem is that you don't agree with this approach/API. 
I guess that you want something like we added (Dan suggestion) recently 
on St:

https://bugzilla.gnome.org/show_bug.cgi?id=644253

And BTW, this is what I called before "follow some guidelines". Because 
you can have that gtk_label_set_is_labelling, but the app developer is 
not forced to use this call. The guideline would advice him to use it 
due several reasons (ie: improving a11y support).

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

Thats the idea. Implement the accessibility support on the toolkit using 
ATK, and let the application developers using the toolkit and following 
their guidelines. App developers using direct atk calls should be the 
exception not the rule.

BR

[1] 
http://git.gnome.org/browse/ocrfeeder/commit/?id=df58f8f921a19787c9a49b5e23b5642f67a9f533
[2] 
http://git.gnome.org/browse/ocrfeeder/commit/?id=6f60dc4f26e92d9c5a3e6ccdedc376018e057515

--
Alejandro Piñeiro Iglesias (API) (apinheiro igalia com)