No hay nada más frustrante para las personas ciegas que intentar utilizar una aplicación y descubrir que es inaccesible. Quizá tu lector de pantalla no pueda leer una parte clave de la aplicación, o quizá no pueda leer nada en absoluto. Cuando las aplicaciones se desarrollan utilizando botones estándar, cuadros de edición, cuadros de lista, tablas u otros elementos de la interfaz de usuario, no es difícil hacerlas accesibles. Pero algunas aplicaciones se desarrollan utilizando un conjunto de herramientas de interfaz de usuario no estándar, y estos conjuntos de herramientas son completamente inaccesibles. Implementar la accesibilidad desde cero en un kit de herramientas de interfaz de usuario es difícil y lleva mucho tiempo, por lo que no suele hacerse, excepto en los pocos kits de herramientas de interfaz de usuario con un gran respaldo corporativo. A veces es realmente necesario que un desarrollador de aplicaciones utilice un kit de herramientas de interfaz de usuario personalizado, y a veces no, pero sea como sea, acabamos teniendo aplicaciones inaccesibles.
Este problema es especialmente acuciante en el caso de aplicaciones críticas para determinados trabajos. No es infrecuente que una persona ciega no pueda acceder a un trabajo concreto porque éste requiere el uso de una aplicación inaccesible. A menudo se trata de aplicaciones de nicho para las que no existe el incentivo económico habitual para implantar la accesibilidad, es decir, la venta a los sectores público y educativo. Por eso necesitamos urgentemente una solución que derribe el mayor número posible de barreras para hacer accesible la larga cola de aplicaciones.
Al igual que con el trabajo que Pneuma Solutions está realizando en la corrección de documentos y contenido de reuniones, el aprendizaje automático puede ayudar con este problema. Apple está abriendo camino en este ámbito con la función de reconocimiento de pantalla integrada en iOS, y los resultados hasta ahora son prometedores. Sin embargo, esta tecnología aún no está disponible en todos los ordenadores y dispositivos, y los resultados no suelen ser satisfactorios. No podemos esperar a que esta solución madure y se adopte más ampliamente; necesitamos otro enfoque que sea práctico a más corto plazo. Además, muchos desarrolladores tanto de aplicaciones como de conjuntos de herramientas de interfaz de usuario están dispuestos a hacer accesible su software, si no fuera tan difícil y llevara tanto tiempo. Estos desarrolladores ya están dispuestos a encontrarnos a mitad de camino; ahora nosotros tenemos que hacer lo mismo.
Ahí es donde entra mi nuevo proyecto de código abierto, AccessKit. El objetivo de AccessKit es proporcionar una infraestructura compartida para hacer accesibles las aplicaciones en tantas plataformas y lenguajes de programación como sea posible. Con AccessKit, un desarrollador que trabaje con varias plataformas no tendrá que implementar la accesibilidad para cada plataforma desde cero. Otro objetivo de AccessKit es estar mejor documentado y ser más fácil de utilizar correctamente que las actuales API de accesibilidad específicas de cada plataforma, como UI Automation para Windows o la accesibilidad Cocoa para las plataformas de Apple. Después de todo, una implementación de accesibilidad defectuosa puede ser casi tan frustrante como la falta de accesibilidad.
AccessKit aún se encuentra en una fase temprana de diseño y desarrollo, pero ya está atrayendo el interés de otros desarrolladores, incluidas las contribuciones de código de otro desarrollador. Y ahora tengo el gran privilegio de recibir financiación de Google para trabajar a tiempo parcial en este proyecto, empezando por la implementación en Windows. Espero que los resultados sean utilizables a finales de este año.
Estoy seguro de que los desarrolladores que lean esto querrán saber más sobre cómo funcionará AccessKit. La versión resumida es que AccessKit proporcionará una abstracción de accesibilidad multiplataforma fuertemente inspirada en el motor del navegador Chromium. Esta abstracción se basa en estructuras de datos serializables, minimizando así la sobrecarga de la interfaz entre lenguajes de programación. AccessKit se implementará principalmente en el lenguaje de programación Rust, que ofrece una combinación única de fiabilidad y eficiencia. No obstante, AccessKit podrá utilizarse desde diversos lenguajes de programación. Más detalles en el repositorio GitHub de AccessKit.
Como proyecto de código abierto, AccessKit necesita la participación de la comunidad de desarrolladores para tener éxito y ser sostenible. En particular, agradecería las contribuciones de desarrolladores que dominen el lenguaje de programación Rust. El diseño general de AccessKit sigue siendo fluido, por lo que es demasiado pronto para delegar mucho trabajo de implementación. Lo que sí necesito en este momento es la revisión por pares, especialmente de desarrolladores que tengan más experiencia con el lenguaje Rust que yo. Si estás interesado, únete a nosotros en GitHub.
Para terminar, una gran razón por la que dejé Microsoft para cofundar Pneuma Solutions es que quiero tener la libertad de trabajar en proyectos relacionados con la accesibilidad que creo que tendrán un gran impacto positivo para nuestra comunidad, más allá de una única plataforma. Sigo entusiasmado con el trabajo que estamos haciendo en Pneuma Solutions, y ese trabajo continuará. Con AccessKit, ahora tengo la oportunidad de resolver un problema que ha pesado mucho en mi mente durante muchos años. Estoy deseando trabajar con la comunidad de desarrolladores de software para hacer accesibles muchas más aplicaciones.
Deja una respuesta