À qui incombe l’accessibilité d’un système ?

17 septembre 2018, par Équipe Access42

Après avoir vu passer une conférence sur l’accessibilité de Linux (lien direct vers le fichier mkv de la vidéo), donnée par Sébastien Hinderer, nous avons voulu en savoir plus sur sa perception des modèles de prise en charge de l’accessibilité par Microsoft et Apple (dont il parle entre 30 minutes 10 et 33 minutes 50).

Ce sujet étant peu connu, nous avons demandé à Sébastien et à son collègue Samuel Thibault de nous faire part de leur retour d’expérience sur l’implémentation de l’accessibilité dans ces différents systèmes.

À propos des auteurs

Sébastien Hinderer est ingénieur de recherche au centre Inria de Paris.

Aveugle de naissance, il s’intéresse à tous les aspects de l’accessibilité : techniques, sociaux, réglementaires. Il est impliqué dans le développement du lecteur d’écran brltty et d’une bibliothèque numérique pour déficients visuels, Teupaga.

Samuel Thibault est maître de conférences en informatique, il bricole 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 aussi aux projets Debian, GNU/Hurd et FFDN.org.

En préambule

Bon an, mal an, l’idée selon laquelle logiciels, sites Internet, bâtiments et tous les aspects de la cité devraient être accessibles fait son chemin. Se pose la question de savoir à qui incombe cette mise en accessibilité. Est-ce aux fournisseurs de sites, logiciels, bâtiments etc. de rendre ceux-ci d’emblée accessibles, ou l’accessibilité doit-elle être réalisée a posteriori, par des structures particulières et éventuellement via des dispositifs distincts ?

Nous illustrons les deux approches par des exemples issus de l’informatique et montrons quelles conséquences découlent de chacune d’elles.

Première approche : déléguer l’accessibilité ?

L’idée qu’une accessibilité de qualité passe par des solutions externalisées dédiées est tentante : l’accessibilité demande un savoir-faire que ne peuvent avoir que des spécialistes, les besoins auxquels on cherche à répondre sont de toute façon trop spécifiques pour pouvoir être pris en charge par le service « de base ». C’est probablement pour cette raison que cette approche est celle qui a été explorée en premier, historiquement.

C’est ainsi que des entreprises telles que Microsoft ou Symbian ont choisi cette approche pour la prise en charge de l’accessibilité des systèmes d’exploitation qu’elles proposent (Windows, et Symbian OS pour les téléphones mobiles d’avant les SmartPhones).

Dans cette approche, le système fournit une interface de programmation permettant de savoir quels sont les objets présents à l’écran et d’interagir avec eux, mais c’est à une application tierce (lecteur d’écran, agrandisseur...), développée par une entité externe, d’exploiter effectivement l’interface de programmation fournie.

Cette approche a des conséquences tant techniques qu’économiques.

  • Sur le plan technique, il est difficile, avec une telle approche, d’empêcher qu’il se forme au moins un certain décalage entre la mise à jour du système d’exploitation et la mise à jour des outils qui en assurent l’accessibilité. En outre, l’absence d’une solution de revue d’écran intégrée au système conduit assez naturellement au développement de plusieurs solutions. Ceci peut certes être vu comme un avantage, dans le sens où cela peut donner lieu à des approches différentes suscitées par une concurrence. On peut cependant se demander si une division des ressources de développement est pertinente dans un domaine où les spécialistes sont si peu nombreux. Enfin, du point de vue de l’utilisateur, lorsqu’une solution de mise en accessibilité est externe au système d’exploitation, cela signifie le plus souvent qu’elle devra être installée sur un système déjà opérationnel. Il en résulte qu’une personne ayant besoin d’une telle solution ne sera pas en mesure d’installer le système d’exploitation sous-jacent de façon autonome.
  • Sur le plan économique, une solution tierce a, le plus souvent, un coût (sauf si elle est issue du logiciel libre). Même si la collectivité se substitue souvent aux individus pour prendre en charge ce coût supplémentaire, cela ne change rien au fait qu’un tel modèle établit une scission entre les personnes auxquelles le système d’exploitation tel quel suffit et celles, en situation de handicap, qui ont besoin d’un composant supplémentaire.

Tout en séparant les individus en deux groupes, nous pensons que cette approche est également source de confusion. En effet, elle laisse à penser que les personnes en situation de handicap sont les seules à avoir besoin des fonctionnalités d’accessibilité (il est donc normal qu’on les développe spécifiquement pour elles et qu’elles soient les seules à en assumer le coût). Or, l’expérience montre que les choses ne sont pas si simples et que, le plus souvent, des solutions initialement développées expressément pour des personnes en situation de handicap se révèlent utiles à tous.

D’autre part, nous pensons que le fait de déléguer la mise en accessibilité peut conduire à un désinvestissement et à une déresponsabilisation des développeurs des systèmes « grands publics ». Dans le cas des sites Internet, il nous semble que ce travers peut être encore plus grave. Il existe ainsi des solutions payantes proposant aux personnes en situation de handicap de servir d’intermédiaires entre elles et des sites réputés peu ou pas accessibles. Ces structures récupèrent les contenus de ces sites et les mettent à disposition des personnes sous une forme simplifiée ou plus lisible. En plus de toutes les conséquences mentionnées précédemment, nous pensons que cette approche peut, à long terme, donner raison à ceux qui seraient tentés de penser que les sites « grand public » n’ont plus réellement besoin d’être accessibles, puisqu’il existe des moyens alternatifs dédiés d’accéder à leur contenu.

Par ailleurs, les personnes recourant à ces solutions dédiées risquent de s’y limiter et de ne jamais aller vers l’utilisation de sites « grand public », quand bien même ceux-ci seraient accessibles. Ceci créerait donc une situation d’enfermement dans laquelle les personnes concernées seraient pour ainsi dire captives. Du point de vue des sites accessibles que ces personnes n’utiliseraient pas, ceci a pour conséquence de priver leurs concepteurs de retours d’utilisateurs ayant besoin d’accessibilité, ce qui pourrait conduire ces concepteurs, qui avaient pourtant fait l’effort de mettre l’accessibilité en place, à penser que cela ne sert à rien, faute de retour attestant d’une utilisation effective des fonctionnalités d’accessibilité proposées.

Deuxième approche : intégrer l’accessibilité dans les systèmes ?

À l’inverse, l’exemple le plus connu illustrant le choix d’intégrer pleinement l’accessibilité aux logiciels proposés est donné par Apple avec ses systèmes pour ordinateurs et téléphones mobiles. Dans cette approche, aucun composant logiciel supplémentaire n’est à installer pour que le système soit accessible. Il l’est dès l’origine, les solutions d’accessibilité n’ayant qu’à être activées en fonction des besoins.

Les conséquences de cette approche sont l’exact opposé de celles décrites précédemment. Les coûts inhérents aux développements liés à l’accessibilité sont répartis entre tous et le produit qui en découle ne crée pas de dichotomie entre personnes en situation de handicap et personnes valides. En outre, les fonctionnalités d’accessibilité étant disponibles pour tous, elles peuvent être utilisées même par des personnes pour lesquelles elles n’avaient pas été conçues mais qui y trouvent un intérêt, fût-il ponctuel ou circonstanciel.

Il nous semble cependant, que pour que cette approche d’intégration de l’accessibilité soit complète, elle devrait aussi inclure des interfaces de programmation claires et documentées permettant à des structures tierces de compléter ou d’améliorer les solutions existantes lorsque cela est jugé nécessaire.

Ces interfaces ne sont pas disponibles avec les solutions proposées par Apple, mais le sont ou tendent à l’être dans le cas du logiciel libre, pour lequel tout est fait pour que l’accessibilité soit à la fois aussi intégrée et aussi extensible que possible, offrant ainsi le meilleur des deux solutions précédentes.

En conclusion

Il nous semble fondamental que l’accessibilité des produits et services soit prise en compte dès leur conception et non a posteriori. Une telle démarche nous paraît fondamentale, non seulement pour des raisons techniques, mais aussi économiques et sociales. Si l’accessibilité n’est pas pensée au moment même de la conception des produits et services, soit on ne s’en occupera pas du tout et ce sera source d’exclusion, soit on s’en occupera a posteriori avec un coût élevé, tant de conception que de maintenance.

Nous sommes convaincus qu’il y a tout à gagner à intégrer l’accessibilité aussi tôt que possible dans les processus de conception et que c’est toute la société, et pas seulement les personnes en situation de handicap, qui gagnerait à ce changement de paradigme.