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

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:

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

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:


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

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