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

[Piñeiro <apinheiro igalia com>]

On 06/03/2011 06:01 PM, Matthias Clasen wrote:
> On Wed, Jun 1, 2011 at 7:48 PM, Piñeiro<apinheiro igalia com>  wrote:
> > On 05/10/2011 04:28 PM, Benjamin Otte wrote:
> > In fact, IMHO, some of the issues pointed by Benjamin would be solved by
> > this [2] and the gail migration, but lets not talk about it. As I said,
> > those are long term tasks, and the fact is that the current accessibility
> > status needs to be improved also in the short and medium term.
> >
> > I also planned to define those short-medium tasks, but after reading again
> > some mails, Matthias already did it in this mail [3], so I will not repeat
> > that. I will just include that as task 1.5 I would include refactoring
> > gailtreeview, one of the big problems related to performance that prevents
> > having a11y enabled as default [5]
> For making things work better in the short/medium term (ie before we
> land a complete refactoring/rewrite of gail), I think two things are
> essential:
>
> 1. Define the atk interfaces to a testable level.
>
> One example that I have run in recently is
> the 'name' property of AtkObject - it is not really defined at all
> what this is supposed to contain, and how it is supposed to be used.
> It turns out a change that I committed last September made menu
> accessibles not have names - it turns out that that breaks ATs which
> expected those names to be taken out of the labels contained in the
> menuitems. This needs to be specified somewhere, so that we can then

About this specific case it is about improve the documention:

http://developer.gnome.org/atk/stable/AtkObject.html#AtkObject--accessible-name

Or something else?

You could also try to create a bug to debate it, or include it as a item 
on the a11y weekly.

Anyway, I thought that the first step here was to migrate the current 
gail (with their virtues and drawbacks) to gtk. And although things 
would be easier with a good atk documentation, Im not sure if this is a 
blocking here.

> 2. Test that the accessible implementations actually follow that spec.
>
> I want to be able to have a unit test in the GTK+ repository that
> instantiates a widget, gets the corresponding accessible, and then
> verifies that it has the expected properties. If we had such
> testcases, it would not have taken 9 months from me committing the
> breaking change to me committing the fix. On the other hand, the fact
> that nobody filed a bug maybe tells us something about the amount of
> real-life usage that the gnome3 accessibility stack currently gets...

Real-life usage is mostly done by users. GNOME 3 is not accessible, or 
at least was announced as not accessible. In general most of the tests 
done by the users were mostly a disappointment  (ie: [1][2][3][4]). In 
summary: there is no real-life usage of the gnome3 accessibility stack. 
For the moment GNOME 3 accessibility stack is mostly developers tested.

BR

[1] https://mail.gnome.org/archives/orca-list/2011-May/msg00307.html
[2] https://mail.gnome.org/archives/orca-list/2011-May/msg00165.html
[3] https://mail.gnome.org/archives/orca-list/2011-May/msg00048.html
[4] https://mail.gnome.org/archives/orca-list/2011-May/msg00143.html


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