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

[Piñeiro <apinheiro igalia com>]

On 06/06/2011 04:33 PM, Matthias Clasen wrote:
> On Sat, Jun 4, 2011 at 8:44 PM, Piñeiro<apinheiro igalia com>  wrote:
>
> > About this specific case it is about improve the documention:
> >
> > http://developer.gnome.org/atk/stable/AtkObject.html#AtkObject--accessible-name
> >
> > Or something else?
> Well, more than that, really.
>
> We need to know for each widget what the property is supposed to
> contain. I guess this also requires coming to grips with the somewhat
> haphazard way in which the acessible tree is different from the widget
> tree: sometimes there is a single accessible that 'wraps up' a whole
> widget subtree, e.g a button accessible 'hides' the image and label
> children of the widget, and instead implements corresponding
> interfaces itself. And the same is very much true for the
> ::accessible-name, which is often taken from 'somewhere below'.

Ok, thanks for the explanation. In summary you are proposing to somehow 
make current heuristic practices more homegeneous. Well, in the end this 
is also documentation, and providing a proper "good practices document". 
Because in the end, as an abstracted interface, what ATK needs to expose 
is a coherent model of the original hierarchy. Although I would need to 
see it in further detail, I guess that exposing the full subtree would 
be also OK, and that in this case, original developer concluded that was 
more clear in this way. But as you say, it would be good to having a 
document explaining good practices, instead of trying to reinvent the 
wheel over and over.

We always said that current accessibility documentation is just bad. And 
this is a bigger problem taking into account that original ATK 
developers seems to be out of this planet. This was also a problem on 
the ATK hackfest, as some of the things that we discussed started with 
"I don't understand why they did this in that way, but it would be odd 
if they didn't have a reason to do that ..."

> > 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.
> I don't think we can treat that as a first step and hold off on doing
> any other fixes until that migration is done.  The migration is a
> significant undertaking, and will not be finished for 3.2.

Sorry, I didn't want to say that we should hold off any other fix and 
focus just on the migration. Just trying to focus on the current big 
task defined as much as possible.

> > > 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.
> I would say not even that, unless you mean just the handful of a11y
> developers. I can't even turn on toolkit-accessiblity on my system;
> evolution crashes as soon as I switch to the calendar..

Yes, specifically a11y developers. You already mentioned that it is a 
problem that a11y developers are perceived as a different group than 
developers in general, right?

About the evolution thing, in this case there is a real-life usage, as 
probably is this bug:

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

Fixed recenly, although AFAIU comment 154, it is just a workaround ("If 
ever we get someone to update our accessibility code then we can bring 
this back and let him/her try and debug the crash"). Which is valid 
right now. AFAIK evolution right now is not really accessible friendly, 
in general, gtkhtml is not really accessible friendly. Lets hope the 
situation improves with the WekkitGTK move:

https://live.gnome.org/Evolution/Planning32

BR

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