Accesibilidad en GNOME (formato WORD).

Accesibilidad
en
GNOME
1
1.
Cómo trabaja la Accesibilidad en GNOME: Arquitectura
de Accesibilidad de GNOME.
La Arquitectura de Accesibilidad de GNOME fue diseñada para proporcionar una interfaz
estándar entre:
 las tecnologías de asistencia (Assistive Technologies, AT's), por un lado, y
 las aplicaciones y el escritorio de usuario.
Las aplicaciones que ejecuta el usuario deben
poder ser accesibles para las personas con
discapacidad…
Antes de comenzar, vamos a señalar algunos de los acrónimos que utilizaremos y su
significado esencial.

AT, Tecnología de Asistencia: es una aplicación encargada de pedir y recopilar información
sobre la interfaz de usuario de la aplicación con la que esté trabajando para adecuarla a un
formato accesible. Además, puede transmitir acciones a dicha aplicación si ésta lo permite, es
decir, si es compatible.

ATK, Accessibility Toolkit: se trata de un conjunto de interfaces de accesibilidad. Dichas
interfaces serán implementadas por las aplicaciones en ejecución. De este modo, las AT’s
pueden obtener y mandar información a estas aplicaciones de usuario. Estas interfaces son
independientes del soporte de las aplicaciones (GTK, Motif o Qt).

AT-SPI, Assitive Technology Service Provider Interface: es una biblioteca que también
proporciona interfaces usadas por las AT's. Se combinará con la ATK para proporcionar una
accesibilidad óptima. Al contrario que ATK, AT-SPI está basada en CORBA, pero sus funciones
2
son prácticamente las mismas.

GTK: es una librería para crear GUI’s (Graphical User Interfaces). Funciona sobre muchas
plataformas basadas en UNIX e incluso en Windows.

GAIL, GNOME Accessibility Implementation Library: se trata de un conjunto de bibliotecas
que permiten la interacción entre las AT's y las aplicaciones que usen widgets GTK. Por tanto,
se trata de un puente entre ATK / AT-SPI y dichas aplicaciones.
1.1.
Vista general de la Arquitectura.
En este primer acercamiento, vamos a fijarnos en la parte de aplicación e interfaz de usuario,
dejando para más adelante la interacción con las AT's. De esta forma, iremos ampliando un poco los
conceptos citados en el apartado anterior.
Supongamos solo una cierta aplicación ejecutada por el usuario y una sola AT. Así,
simplificaremos la explicación, aunque ésta sea perfectamente extendible a una relación múltiple
entre aplicaciones usuario y AT’s.
Una condición necesaria para garantizar la accesibilidad en GNOME es que la información
de la aplicación usuario pueda ser recogida y transformada para que la AT haga uso de ella. Esa
transmisión de información necesita de un camino y un formato específico para poder comunicar
ambos extremos. Ese camino está compuesto de dos partes: el ATK y el AT-SPI.
- La misión del ATK es la de la comunicación directa con la aplicación usuario. No obstante,
es posible que no sea necesario cargar el ATK. Por ejemplo, Mozilla incluye la
implementación de ATK en sus aplicaciones; Java, por su parte, puede usar una librería de
accesibilidad propia.
- La misión del AT-SPI es la de transmitir la información recogida por ATK, transformarla y
propagarla directamente a la AT.
A grandes rasgos, este es el esquema de la Arquitectura de Accesibilidad en GNOME. Sin
embargo, el proceso de comunicación es más complejo, pues requiere la carga de librerías
específicas que permitan la interacción entre:
3
-
ATK y AT-SPI,
ATK y las aplicaciones basadas en GTK y
AT-SPI y la AT
De lo dicho hasta ahora, es necesario puntualizar que la comunicación descrita entre la
aplicación de usuario y la AT es recíproca, es decir, hay transmisión de información en ambos
sentidos.
Sobre el proceso de comunicación y su estructura interna hablaremos con más detalle en
apartados siguientes.
1.2.
GTK y la accesibilidad GNOME.
Muchas aplicaciones hacen uso de GTK para implementar las componentes gráficas de sus
interfaces. Para la correcta comunicación entre ATK y las aplicaciones GTK se carga la librería
GAIL.
2.
El diseño de AT-SPI.
AT-SPI (Assistive Technology Service Provider Interface) fue desarrollado para permitir a
las AT’s como los lectores de pantalla pudieran relacionarse con las aplicaciones usuario. AT-SPI
consta de:
- atk-bridge (puente-atk)
- Registry Daemon (demonio conocido como Accesibility Broker)
- cspi, una librería compartida
AT-SPI está basado en CORBA y bonobo. En el último apartado profundizaremos en lo
referente a CORBA y el debate abierto en la comunidad GNOME. La librería cspi facilita el trabajo
de los programadores de C, ya que ésta hace referecencia a la librería libspi, la cual requiere el uso
directo de llamadas tipo CORBA y bonobo.
2.1.
Relación del atk-bridge con Registry Daemon.
Atk-bridge enlaza ATK con AT-SPI. Ello permite la comunicación entre las AT’s y aquellas
aplicaciones que soportan AT-SPI. Al comienzo, atk-bridge inicializa el servidor bonobo, el cual a
su vez inicializa el Registry Daemon. Una vez activados, el atk-bridge comienza a registrar en el
Registry Daemon “escuchadores” para los eventos básicos que puedan aparecer.
El Registry Daemon, por su parte, cuando se inicializa realiza las siguientes tareas:
1) Activa la conexión al servidor bonobo si ésta no existía.
2) Crea un registro.
3) Dicho registro crea un escritorio.
4
4)
5)
6)
7)
2.2.
Al inicializar el escritorio, se crea un escritorio especial: el escritorio-ATK.
Este escritorio-ATK crea un objeto que servirá de ruta para el árbol del escritorio.
De esta ruta colgarán todas las aplicaciones registradas por Registry Daemon.
Los escritorios enviarán señales y los registros serán los encargados de gestionarlas
mediante “manejadores” de señales.
Cómo sucede el registro de aplicaciones.
Cuando una aplicación inicia su ejecución, la función gtk-module-init del atk-bridge es
llamada. Ello, a su vez, activa las llamadas pertinentes para que atk-bridge registre la aplicación con
Registry Daemon. Una aplicación es un árbol de objetos accesibles.
3.
El problema de base que presenta AT-SPI.
AT-SPI usa actualmente ORBit para su IPC (Inter-Process Communication), el cual es un
componente obsoleto de GNOME y en desuso sobre el escritorio KDE. La comunidad de
desarrolladores debate en la actualidad sobre la idoneidad de migrar AT-SPI a otro estándar IPC, el
D-Bus.
No existe un análisis completo de la interfaz AT-SPI trabajando bajo D-Bus, pero son
algunas las mejoras que plantea D-Bus sobre ORBit, como la rapidez en el envío de referencias de
objetos.
Actualmente, AT-SPI está definido por su IDL (Interface Definition Language). El IDL es
utilizado para describir los componentes software de una interfaz (procedimientos, métodos…)
mediante un lenguaje neutral, lo cual permite la comunicación entre componentes de software que
no comparten el mismo lenguaje de programación.
Es por ello, por la naturaleza neutral del AT-SPI, la posible futura migración del IDL al
protocolo D-Bus. No obstante, dicha migración plantea dos problemas:
1) Por el momento no existe un traductor fiable de IDL a lenguaje D-Bus.
2) Sería necesario reescribir las librerías básicas ligadas a ORBit, las cuales son fundamentales
(ATK / GAIL, cspi…).
Por suerte, las AT’s usan llamadas indirectas (wrappers) sobre ORBit, en lugar de llamadas
directas, lo cual podría permitir la creación de una API muy similar a la actual para esas librerías si
se llegara a usar el protocolo D-Bus.
3.1.
D-Bus.
Es un mecanismo IPC (Inter-Process Communication) y RPC (Remote Procedure Calling)
originalmente desarrollado para Linux, con la finalidad de reemplazar los IPC’s existentes bajo un
único protocolo unificado.
Usa un protocolo de transferencia de mensajes muy rápido, con latencia y uso de recursos
5
reducidos. A bajo nivel, las aplicaciones se comunican por D-Bus enviándose mensajes
mutuamente. Estos mensajes pueden contener tanto las llamadas a procesos remotos como sus
respuestas y los posibles errores asociados a ellos. Además, estos mensajes tienen un emisor y un
destinatario concretos, evitando la congestión que pueda provocar, por ejemplo, el envío en masa
(broadcasting). Para distinguirse entre ellas, las aplicaciones escogen un “nombre de servicio” con
el que serán identificadas unívocamente dentro del bus. Los servicios que se prestan unas
aplicaciones a otras son posibles gracias a la exportación de objetos, los cuales están
jerárquicamente organizados.
6