Re: [g-a-devel] Coming to grips with the state of a11y in gtk

[Matthias Clasen <matthias clasen gmail com>]

On Thu, Feb 17, 2011 at 11:22 AM, Piñeiro <apinheiro igalia com> wrote:
>
> Ok, so you are proposing a change more deep that I thought.
>
> You are proposing to forget this "proxy" approach on the accessibility
> support. As far as I understand you are proposing to implement the ATK
> interfaces directly on GTK, so instead of having a GTK widget and his
> accessible equivalent, just having a GTK widget implementing the
> proper ATK interfaces, right?

First and foremost, I am proposing that we need to have the widget
implementation and the a11y object implementation share a bed, so to
speak. They need to have access to each others private parts. Even
more so, now that we've sealed gtk to make access from the outside
harder / more controlled.

> I already talked about that in the past (ie [1][2]), but summarizing
> the reasons to avoid that:
>
>  * Right now AtkObject is a different object, not a interface
>   (although this could change with a new API if we decide that
>   worths)
>
>  * Allow to define a11y objects not related with a specific toolkit
>   object (ie: fly weight objects on the tree view).
>
>  * Allow to not define a11y object for any toolkit object (ie: I do
>   not do that right now, but I always thought that it was not
>   required an a11y object for a ClutterEffect).
>
>  * ATK tries to be as abstract as possible, so abstract that could
>   expose a11y support for non-glib toolkits. IE: WebKitGTK a11y
>   support. It exposes ATK objects for internal webkitcore objects,
>   that are C++ classes.
>
> In summary, being able to expose a a11y object hierarchy different
> from the toolkit object hierarchy/technology if necessary.

All these are great reasons in theory, which have failed miserably in
practice, if you ask me.