Pourquoi ne pas étendre les tests de non régression à la question de l’accessibilité ?

Dans un code, il est d’usage de définir des tests unitaires qu’on exécute au moment de la compilation ou de la construction. Cela garantit que les fonctions s’exécutent comme l’a prévu le développeur. D’autres tests, plus ou moins automatisés selon la complexité du bogue potentiel, visent à prévenir les bogues de sécurité ou des régressions.

On pourrait inclure à la suite de tests du Makefile des tests de non régression en matière d’accessibilité. Tester que les widgets sont labellisés, avertir si une fonction n’est exécutable qu’au clavier ou qu’à la souris (sans alternative), permettrait d’éviter la plupat des régressions des logiciels graphiques libres, notamment LibreOffice, Mozilla et les bureaux.

D’autres tests sont possibles à partir de simulations de cas d’usages.

Qu’est-il possible de faire précisément sans compétences spécifiques et à l’intérieur même d’un projet pour éviter les régressions d’accessibilité lors des mises à jour ?

Jean-Philippe MENGUAL , Samuel Thibault
JPM : Linuxien depuis 2004, il est administrateur de Liberté 0 aujourd’hui et d’accelibreinfo. Il participe depuis 2008 à de nombreux projets liés à l’accessibilité des logiciels libres (groupe de l’April, traductions, QA de Libreoffice). Depuis 2015, il a fondé le projet Hypra qui vise à promouvoir auprès du g !and public et notamment dans le secteur de la déficience visuelle le logiciel libre, pour en tirer tous les bénéfices et l’aider à changer d’échelle.

Samuel Thibault est maître de conférence en informatique, il bricole avec Linux depuis 1998, a commencé à s’intéresser à l’accessibilité depuis qu’il a rencontré Sébastien Hinderer en 2001, et n’a pas arrêté depuis. Il participe également aux projets Debian et GNU/Hurd, ainsi qu’au projet FFDN.org.

Lien vers le programme des RMLL