why not extending non-regression tests to accessibility matter?

Speaker(s) : Jean-Philippe MENGUAL Samuel Thibault

  • Language : Anglais
  • Level : Confirmed
  • Nature : Conference
  • Date : Tuesday 4 July 2017
  • Schedule : 11h40
  • Duration : 40 minutes
  • Place : Room J 109 Programmation
Public cible : Accessibilité

In a code, we set unit tests which may be run at building time or compiling time. These ensure each feature works as expected by the developper. Other tests, more or less automated according to the complexity of the potential bug, aim to avoid security bugs, or regressions.
Accessibility may be part of a non-regression test testsuite included in a Makefile or similar. Testing labellization of widgets, warning about a feature without alternative to be run (just keyboard or just mouse), may help avoiding most regressions in graphical free software a11y, including LibreOffice, Mozilla or desktop environments.
Other tests are possible, based on the simulation of usecases.

What can be done exactly, without specific skills, and at project level, to avoid a program to loose accessibility after un upgrade? What common thought is possible?

Jean-Philippe MENGUAL , Samuel Thibault
JPM: Linux user since 2004, he is now an administrator of Freedom 0 and accelibreinfo. He has been getting involved since 2008 in many free software accessibilit-related projects (the April group, translations, LibreOffice QA and design). Since 2015, he has created the Hypra project to promote for everybody, and in particular for sighted impaired people, free software to get benefits and make it pass a new step.

Samuel Thibault is a computer science assistant professor at the university of Bordeaux, he tinkers with Linux since 1998, started getting interested in accessibility since 2001, and never stopped since. He also participates to the Debian and GNU/Hurd projects, as well as the FFDN.org project.

titre documents joints

Slides PDF (PDF - 321.2 kb)
Slides ODP (OpenDocument Presentation - 463.6 kb)