[webkit-efl] Support for WAI-ARIA standard.

[Piñeiro]

Although already explained by Krzystof Czech in a different thread. Some
comments below:

On 10/11/2012 01:12 PM, Raphael Kubo da Costa wrote:
> Krzysztof Czech <k.czech at samsung.com> writes:
>
>> We consider usage of Accessible Toolkit (ATK) library. ATK describes
>> sets of independent
>> interfaces that can be adopted by application's widgets to be accessible.
>> What are pros and cons of such a solution.
> Please consider I'm a complete layman in terms of accessibility. What's
> the relationship between ATK and at-spi2? Is the latter used by the
> former? 

at-spi2 is a library that includes the client-side library (libatspi)
and the DBUS daemon.

ATK is one of the possibles server-side library (at this moment there
are only two, ATK and QtAccessible).

Just in case, to clarify the terminology. From the point of view of the
accessibility, the client is the accessibility tool (AT) like a screen
reader. Server is the application (ie: a webkit based browser) as is the
one providing the information to the AT, and the user in general.

In order to expose the information from the server to the client, DBUS
is used. So it is required a library doing those DBUS calls between the
server and the client. A bridge. For the case of GNOME, in order to
avoid to have a bridge for each toolkit, each toolkit implements the ATK
headers and a ATK-bridge (or adaptor) was created. This bridge uses ATK
API in order to know how to expose the information. Some examples of
libraries/applications using ATK:
  * GTK
  * Clutter
  * Firefox
  * WebkitGTK (although it could be moved to a more general place see
https://bugs.webkit.org/show_bug.cgi?id=99578)
  * Unity3D
  * LibreOffice
  * etc

The atk-bridge is something shared by everyone. Obviously one option
would be create a bridge for each specific toolkit. But most of them
would be really similar, as the bridge mostly focuses on emit
at-spi2-complaint DBUS calls based on the information provided by the
toolkit. In summary the bridge is a library created to be reused.

> I remember at least Qt is using at-spi directly, so it seems to
> be more platform-neutral than ATK itself.

ATK is already toolkit independent. In fact was created with that
purpose. Although the most common know implementation is GTK, is not
tied to it. Firefox ATK implementation have some nits of GTK, but this
is because Firefox is already using GTK on Linux. I implemented the ATK
support for Clutter, and it doesn't have any GTK reference at all.

About Qt. When Qt started to implement a linux accessibility support,
they already had several accessibility related headers, related with the
Windows and other OS support. So instead of creating atk wrappers for
their accessibility headers, they decided to create a new bridge based
on their already existing qt accessibility headers.

But the case of webkit is different. Thanks to the work done on
webkit-gtk webkit already have a lot of ATK implementation done. And the
bridge works fine (both for webkit1 and webkit2). Implementing a new
bridge (something like webkit-bridge) seems like an overkill to me.

Best regards

-- 
Alejandro Piñeiro Iglesias