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



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)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]