Este artículo es una especie de abstract extendido para la charla que quiero dar en el GUADEC.

Hoy en día, muy poca gente trabaja en la infraestructura de accesibilidad de GNOME, que es básicamente lo que se usa en el resto del ecosistema de los escritorios libres sin importar su toolkit gráfico. Después de que Oracle compró a Sun Microsystems en 2010, prácticamente desapareció todo el trabajo remunerado en accesibilidad. Hay muy poco trabajo por parte de voluntarios, y nuestra infraestructura de accesibilidad ha ido acumulando deuda técnica desde entonces.

¿Qué clase de deuda técnica hay en nuestra infraestructura de accesibilidad?

Tiene pocas pruebas.
No tiene un entorno reproducible de compilación y pruebas.
No se ha actualizado conforme ha evolucionado el resto de la plataforma.
Muy poca gente sabe cómo funciona.

Es un círculo vicioso, y quiero ayudar a romper el ciclo.

Recordatorio veloz: ¿qué hace la infraestructura de accesibilidad?

Una persona sin discapacidades físicas y con buena visión utiliza una computadora de escritorio así: mirar la pantalla, interactuar con cosas en ella mediante el teclado y el mouse. Los toolkits gráficos asumen este esquema desde el fondo, y el hardware también lo hace — piensa en todo el trabajo que hay hecho para gráficos bonitos en tiempo real, GPUs, herramientas de diagnóstico de desempeño cuadro-por-cuadro, etc.

La gente que no puede ver bien, o que son 100% ciegos, o que no puede usar un teclado regular de la forma en que las aplicaciones asumen que se puede usar (¿sólo tienes una mano? ¡intenta apretar un tecla de modificador y otra tecla al otro extremo del teclado!), o que no pueden usar un mouse de forma efectiva (¿manos que tiemblan? ¿dolor de artritis? ¿no puedes hacer doble clic? ¿no tienes control motriz fino como para distinguir entre el botón izquierdo y el botón derecho del mouse?), necesitan tecnologías diferentes.

O un adaptador que traduzca las suposiciones de las aplicaciones "regulares" en un modelo de interacción que sí puedan usar.

La infraestructura de accesibilidad de cada plataforma, incluyendo GNOME, es precisamente esa clase de adaptador.

En artículos futuros voy a describir nuestra infraestructura de accesibilidad en mayor detalle.

Los tiempos cambian

He estado re-familiarizándome con nuestro código de accesibilidad. La última vez que lo vi era al principio de los 2000s, cuando Sun contrató a Ximian para arreglar cosillas "fáciles" como añadir roles faltantes en algunos controles, o asociar etiquetas con sus controles correspondientes. En ese entonces todo asumía X11, y se usaban hacks más bien horribles para tragarse todos los eventos de GTK y mandarlos al código de accesibilidad. ¡El código de accesibilidad todavía usaba CORBA para comunicación entre procesos!

Hoy en día, la cosa es diferente. Cuando GNOME abandonó CORBA, el código de accesibilidad tuvo que portarse a DBus en modo de emergencia. Aparecieron GTK3 y luego GTK4, y también Wayland. La infraestructura de accesibilidad no les siguió el paso, y ahora tenemos cosas que faltan de manera muy notoria: GTK ya no tiene forma de enviar todos los eventos al código de accesibilidad, y entonces no todas las funciones de Orca (el lector de pantalla) se pueden usar con las aplicaciones que usan GTK4.

Además, en Wayland las ventanas no saben su posición absoluta en la pantalla. El compositor puede acomodarlas donde sea, o aplicarles transformaciones arbitrarias. Más aún, Wayland quiere alejarse del modelo inseguro de X11 donde cualquier aplicación maliciosa puede declararse a sí misma como una tecnología de accesibilidad (AT por sus siglas en inglés), y espiar todos los eventos de todas las aplicaciones.

Han cambiado tanto nuestra infraestructura de toolkit gráfico como nuestra visión de la seguridad.

Qué he estado haciendo

He estado re-familiarizándome con cómo funciona el código de accesibilidad, y espero detallarlo en artículos futuros.

Por ahora he hecho lo siguiente:

Añadí integración contínua a at-spi2-core. Tres de los módulos básicos de accesibilidad — at-spi2-core, at-spi2-atk, pyatspi2 — no tenían IC configurada. Atk tiene IC, Orca no la tiene, pero todavía no me he metido a ver el código de Orca. Orca code yet.
Quiero combinar los respositorios de at-spi2-core/atk/at-spi2-atk/pyatspi2 en uno sólo, pues dependen uno del otro de forma muy exacta y va a ser más fácil ponerles pruebas si están en el mismo repositorio. Hoy en día las pocas pruebas que hay están dispersas entre at-spi2-atk y pyatspi2.
Re-escribí el README de at-spi2-core para hacerlo más amigable; lo convertí a Markdown y lo actualicé según el estado de cosas de hoy en día.
Hice un poco de refactorización en at-spi2-core después de ponerle análisis estático en su IC.
Hice un poco de refactorización experimental ahí también, pero descubrí que no tengo una forma fácil de probarla. Por eso mi deseo de combinar los repositorios y probar junto todo el código de accesibilidad.
Arreglé un crash en GTK cuando uno usa gnome-text-editor con el lector de pantalla activado. (el merge request está esperando ser revisado)
Estoy debugueando esta anotación faltante en gnome-shell.

Se solicita ayuda

¿Alguien sabe cómo probar cosas en Gitlab que necesitan ejecutarse por dbus-broker? Creo que eso requiere correr systemd en el contendedor de IC (cosa algo engorrosa), o usar una máquina virtual con systemd en vez de un contenedor. De todas formas — si te interesa Fedora o dbus-broker, ayuda por favor.