Il n’y a rien de plus frustrant pour les personnes aveugles que d’essayer d’utiliser une application et de se rendre compte qu’elle est inaccessible. Il se peut que votre lecteur d’écran ne puisse pas lire une partie importante de l’application, ou qu’il ne puisse rien lire du tout. Lorsque les applications sont développées à l’aide de boutons standard, de zones d’édition, de zones de liste, de tableaux ou d’autres éléments d’interface utilisateur, il n’est pas difficile de les rendre accessibles. Mais certaines applications sont développées à l’aide d’une boîte à outils d’interface utilisateur non standard, et ces boîtes à outils sont totalement inaccessibles. La mise en œuvre de l’accessibilité à partir de zéro dans une boîte à outils d’interface utilisateur est difficile et prend beaucoup de temps, de sorte qu’elle n’est généralement pas réalisée, sauf dans les quelques boîtes à outils d’interface utilisateur les plus performantes bénéficiant d’un soutien important de la part des entreprises. Parfois, il est vraiment nécessaire pour un développeur d’applications d’utiliser une boîte à outils d’interface utilisateur personnalisée, parfois non, mais quoi qu’il en soit, nous nous retrouvons avec des applications inaccessibles.
Ce problème est particulièrement urgent pour les applications qui sont essentielles à certains emplois. Il n’est pas rare qu’une personne aveugle ne puisse pas obtenir un emploi particulier parce que celui-ci nécessite l’utilisation d’une application inaccessible. Il s’agit souvent d’applications de niche pour lesquelles l’incitation économique habituelle à la mise en œuvre de l’accessibilité, à savoir la vente aux secteurs gouvernementaux et éducatifs, ne s’applique pas. Nous avons donc besoin de toute urgence d’une solution qui élimine le plus grand nombre possible d’obstacles à l’accessibilité de la longue traîne d’applications.
À l’instar des travaux de Pneuma Solutions sur la remédiation des documents et du contenu des réunions, l’apprentissage automatique peut contribuer à résoudre ce problème. Apple ouvre la voie dans ce domaine avec la fonction de reconnaissance d’écran intégrée à iOS, et les résultats obtenus jusqu’à présent sont prometteurs. Cependant, cette technologie n’est pas encore disponible sur tous les ordinateurs et appareils, et les résultats ne sont souvent pas satisfaisants. Nous ne pouvons pas attendre que cette solution mûrisse et soit plus largement adoptée ; nous avons besoin d’une autre approche qui sera pratique à court terme. Par ailleurs, de nombreux développeurs d’applications et d’outils d’interface utilisateur sont prêts à rendre leurs logiciels accessibles, si seulement cela n’était pas si difficile et si cela ne prenait pas tant de temps. Ces développeurs sont déjà prêts à nous rencontrer à mi-chemin ; nous devons maintenant faire de même.
C’est là qu’intervient mon nouveau projet open-source, AccessKit. L’objectif d’AccessKit est de fournir une infrastructure partagée pour rendre les applications accessibles, sur autant de plateformes et de langages de programmation que possible. Avec AccessKit, un développeur travaillant sur plusieurs plateformes n’aura pas à mettre en œuvre l’accessibilité pour chaque plateforme à partir de zéro. Un autre objectif d’AccessKit est d’être mieux documenté et plus facile à utiliser correctement que les API d’accessibilité existantes spécifiques à une plateforme, telles que UI Automation pour Windows ou Cocoa accessibility pour les plateformes Apple. Après tout, une implémentation défectueuse de l’accessibilité peut être presque aussi frustrante que l’absence d’accessibilité.
AccessKit n’en est encore qu’au début de sa conception et de son développement, mais il suscite déjà l’intérêt d’autres développeurs, y compris des contributions au code de la part d’un autre développeur. J’ai maintenant l’immense privilège de recevoir un financement de Google pour travailler à temps partiel sur ce projet, en commençant par l’implémentation de Windows. J’espère obtenir des résultats utilisables d’ici la fin de l’année.
Je suis sûr que les développeurs qui liront ces lignes voudront en savoir plus sur le fonctionnement d’AccessKit. En bref, AccessKit fournira une abstraction d’accessibilité multiplateforme fortement inspirée par le moteur de navigation Chromium. Cette abstraction est basée sur des structures de données sérialisables, minimisant ainsi la surcharge d’interface entre les langages de programmation. AccessKit sera principalement mis en œuvre dans le langage de programmation Rust, qui offre une combinaison unique de fiabilité et d’efficacité. Cependant, AccessKit sera utilisable à partir d’une variété de langages de programmation. Plus de détails sont disponibles sur le dépôt AccessKit GitHub.
En tant que projet open-source, AccessKit a besoin de la participation de la communauté des développeurs pour réussir et durer. En particulier, j’apprécierais les contributions des développeurs qui maîtrisent le langage de programmation Rust. La conception globale d’AccessKit est encore fluide, il est donc trop tôt pour que je délègue une grande partie du travail de mise en œuvre. Ce dont j’ai besoin à ce stade, c’est d’une évaluation par les pairs, en particulier de la part de développeurs plus expérimentés que moi avec le langage Rust. Si vous êtes intéressé, rejoignez-nous sur GitHub.
Pour conclure, l’une des principales raisons pour lesquelles j’ai quitté Microsoft pour cofonder Pneuma Solutions est que je veux avoir la liberté de travailler sur des projets liés à l’accessibilité qui, selon moi, auront un impact positif important pour notre communauté, au-delà d’une seule plateforme. Je suis toujours enthousiaste à propos du travail que nous faisons chez Pneuma Solutions, et ce travail se poursuivra. Avec AccessKit, j’ai maintenant l’opportunité de résoudre un problème qui me préoccupe depuis de nombreuses années. J’ai hâte de travailler avec la communauté des développeurs de logiciels pour rendre beaucoup plus d’applications accessibles.
Laisser un commentaire