www/ Accessibility/ AT-SPI2

AT-SPI2

At-Spi2 is a protocol over DBus, toolkit widgets use it to provide their content to screen readers such as Orca.

Formal information is available on http://www.linuxfoundation.org/collaborate/workgroups/accessibility/atkat-spiat-spiond-bus, https://wiki.linuxfoundation.org/accessibility/start

A table of the different types of events is available on https://accessibility.linuxfoundation.org/a11yspecs/atspi/adoc/atspi-events.html

A C binding library for the client side, libatspi, is available, and its documentation provides details on how At-Spi works libatspi API

The core that defines the protocol and starts the dbus accessibility bus is at-spi2-core , the formal definition of RPCs is available as xml files in at-spi2-core/xml/

The protocol essentially consists in dbus RPCs and notifications. For each application (seen as a dbus sender), its tree of widgets is represented as a tree of dbus paths.

The server side, implemented in atk and at-spi2-atk, is basically the server implementation for all the RPC calls that one would make with the client-side library: atk API, and KDE atk overview

A Walkthrough documents the RPC and function calls details.

There are recommandation for applications to be accessible: https://wiki.gnome.org/Accessibility/ATK/BestPractices

Convenient python bindings are available for screen readers: pyatspi2 , the documentation is available through pydoc pyatspi, pydoc pyatspi.text, etc. , a example of playing with it is available, and is probably the recommended way to explore At-Spi from the client side.

Getting it started by hand (normally done by the Desktop Environment session manager):

  • /usr/lib/at-spi2-core/at-spi-bus-launcher &
  • /usr/lib/at-spi2-core/at-spi2-registryd &

  • one can make sure it got registered by using

    $ xprop -root | grep SPI
AT_SPI_BUS(STRING) = "unix:abstract=/tmp/dbus-6fNHBTP2lK,guid=9d17aaa3ca64ff4b66f0c5985442999e"

  • That was the bus address, one can watch what happens by spying on it:

    $ dbus-monitor --address unix:abstract=/tmp/dbus-6fNHBTP2lK,guid=9d17aaa3ca64ff4b66f0c5985442999e

  • Whether applications should enable their at-spi2 support is defined by the IsEnabled property of org.a11y.Status in the accessibility bus (see proposal https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00397.html and implementation https://mail.gnome.org/archives/commits-list/2011-August/msg06285.html). If an application does not enable at-spi2 support by default, it should monitor that property, in order to dynamically enable at-spi2 support if it changes to true (e.g. as done by a screen reader on startup)

  • Whether a screen reader will be started automatically by the session is defined by the ScreenReaderEnabled property of org.a11y.Status in the accessibility bus. Applications should not use this to determine whether to enable at-spi2 support or not, since the screen reader could be started by hand instead of by the session. They should use IsEnabled instead, see above.

  • One can force enabling accessibility (but ideally it should be automatic thanks to the property mentioned above):

    export GTK_MODULES=gail:atk-bridge
export OOO_FORCE_DESKTOP=gnome
export GNOME_ACCESSIBILITY=1
export QT_ACCESSIBILITY=1
export QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1

  • Accessibility enabling can be tested with this script:

    $ git clone https://git.debian.org/git/pkg-a11y/check-a11y
$ cd check-a11y
$ ./troubleshoot

  • Accessibility working in toolkits can be tested with this script:

    $ git clone https://git.debian.org/git/pkg-a11y/check-a11y
$ sudo apt-get install build-essential pkg-config libdbus-1-dev libatspi2.0-dev libgtk2.0-dev libgtk-3-dev libqt4-dev qtbase5-dev 
$ cd check-a11y
$ source env.sh
$ make check

Accerciser to test the availability of the content

Wayland

Works just the same :D