WCAG 2.0, logiciels et applications mobiles : « Pourquoi nous avons besoin de normes claires » (1/3)

Traduction

L’application des règles d’accessibilité des contenus web (WCAG) 2.0 de la Web Accessibility Initiative (WAI) aux logiciels, et en particulier, aux applications mobiles, m’inquiète de plus en plus.

Afin d’éviter toute confusion, clarifions les termes «logiciels» et «applications mobiles». Il ne s’agit pas de logiciels avec une interface utilisateur reposant sur un navigateur web (par exemple les applications web de Microsoft Office 365, SharePoint ou Google Docs ), mais il s’agit de logiciels ayant une interface utilisateur (UI) séparée du navigateur. Un logiciel fonctionnant via un navigateur est une application web et relève complètement du domaine des WCAG.

Cet article traite plutôt des logiciels de bureau et mobiles traditionnels, qui ne nécessitent pas de navigateur tel qu’Internet Explorer, Safari, Chrome, etc. Je crains que l’application des WCAG à ce type de logiciels ne soit dangereuse. Même si, de prime abord, ça peut sembler être un moyen commode pour assurer l’accessibilité, je suis convaincu que cela porte atteinte aux associations de personnes en situation de handicap et nuit à l’accessibilité. Les avocats travaillant dans ce domaine doivent comprendre les différences entre les concepts d’«applications web» et d’«applications mobiles» dans leurs jugements, car le domaine peut engendrer de la confusion. Ce billet a pour but d’expliquer cette confusion et les dangers liés.

Les WCAG ont été développées pour les pages web et les applications web. Elles n’ont jamais eu pour objectif de s’appliquer aux logiciels. Même s’il paraît logique que de nombreux concepts d’UI concernent les logiciels, une analyse plus poussée montre que ce n’est pas le cas. Une meilleure alternative est d’emprunter une poignée des exigences A et double AA des WCAG qui s’appliquent aux logiciels, et pour les autres cas, de se concentrer sur l’utilisation des API (interfaces de programmation) d’accessibilité qui conviennent bien mieux pour rendre les logiciels accessibles. C’est cette approche qui a été choisie par la nouvelle norme européenne d’accessibilité EN 301-549 (document PDF en anglais de 1,4 Mo). Se tourner vers cette norme, plutôt que les WCAG, est plus facile pour les développeurs, améliore l’accessibilité et enfin conduit à un avenir plus prometteur pour les personnes en situation de handicap.

Bref historique de l’application des WCAG aux logiciels

L’idée d’appliquer les WCAG aux logiciels a émergé il y a des années lors de la création des WCAG et lorsque les développeurs de logiciels ont constaté que de nombreux concepts d’accessibilité des WCAG pourraient être généralisés et appliqués aux logiciels. En décembre 2011, cette idée a pris de l’essor lorsque le comité Accessibilité des États-Unis (U.S. Access Board), comité de rédaction du paragraphe Section 508 a inclus la disposition suivante dans son projet de norme de la Section 508.

E207 Platforms and Applications : projet de texte en anglais sur les plateformes et les applications dont voici une traduction.

• E207.1 Général. Lorsque les composants des TIC sont des plateformes ou des applications et qu’ils transmettent des informations ou qu’ils ont une interface utilisateur, ces composants doivent être conformes à la disposition E207 et aux dispositions applicables du chapitre 5.

• E207.2 Conformité aux WCAG. Les composants des interfaces utilisateurs et les contenus des plateformes et applications doivent être conformes aux niveaux A et double AA des critères de succès et exigences de conformité relatives aux pages web dans les WCAG 2.0 (inclues en référence dans le chapitre 1).

• Conformité obligatoire de E207.2 aux WCAG. Les WCAG ont été rédigées indépendamment des technologies. Bien qu’axées sur les pages web, définies comme étant transmises à l’aide de HTTP, il est simple d’appliquer les critères de succès et les exigences de conformité des WCAG aux composants d’interface utilisateur et aux contenus des plateformes et des applications.

Un peu plus de trois mois après la publication de ce projet de directive, j’ai témoigné devant le comité Accessibilité, en mars 2012, lors de la conférence de l’université d’État de Californie à Northridge (California State University Northridge (CSUN)) et exprimé mes inquiétudes sur le fait d’appliquer les WCAG aux logiciels. L’essor de cette idée a aussi entraîné la création d’un nouveau groupe de travail WCAG2ICT Task Force au sein du W3C qui a produit un document de conformité des WCAG aux logiciels (en anglais). L’essentiel des conclusions de ce groupe de travail est que seul un sous-ensemble des WCAG peut être directement appliqué aux logiciels et qu’une grande partie des WCAG doit être plutôt réécrite pour répondre aux besoins spécifiques aux différences existantes entre les logiciels et le web.

L’idée d’appliquer les WCAG 2.0 aux logiciels est un peu restée en sommeil pendant un certain temps. Puis, en mars 2014, la Fédération Nationale américaine pour les aveugles, (National Federation of the Blind, NFB), et mes anciens collègues du ministère de la Justice ont proposé un jugement avec HR Block. J’ai publié un billet de blog sur ce jugement courant 2014. Une partie de ce jugement exigeait que HR Block rende son application mobile conforme aux niveaux A et double AA des WCAG. Naturellement, les jugements impliquant le ministère de la Justice exercent une grande influence et, selon certains collègues issus de l’industrie, ceux-ci sont confrontés à une pression croissante pour rendre leurs applications mobiles conformes aux niveaux A et double AA des WCAG. Plus récemment encore, le 17 novembre 2014, le ministère de la Justice a annoncé un jugement similaire avec Peapod, un service de courses en ligne dans la région de Washington DC, et plusieurs autres importants marchés de la côte du Midwest et de la côte Est.

Je souhaite revenir sur les inquiétudes formulées en mars 2012 à la lumière de ces développements et autres développements récents. Ceci est aujourd’hui particulièrement important pour faire suite à ce qu’a entraîné le jugement de HR Block. Alors que l’application des WCAG 2.0 aux logiciels donne l’impression d’être une solution facile et efficace, je pense au contraire qu’il s’agit d’un recul et que cela engendre de la confusion dans la communauté des technologies de l’information, que cela détourne l’attention d’alternatives plus appropriées, et enfin blesse les personnes en situation de handicap. Après des discussions avec des représentants des droits des personnes handicapées et mes anciens collègues du ministère de la Justice, je propose des pistes pour faire avancer la réflexion.

Pourquoi nous avons besoin de normes claires

Je suis un fervent partisan de normes claires pour l’accessibilité. Je ne veux pas parler ici d’une méthode vraiment novatrice pour atteindre le niveau d’accessibilité le plus élevé possible. Je veux plutôt parler des standards minimums que nous devons exiger de tous les développeurs de logiciels. Si des solutions innovantes représentent le sommet de nos tâches, les normes de base d’accessibilité en sont les fondements. Je pense qu’à ce niveau d’accessibilité, nous avons besoin de standards qui sont aussi clairs et simples que possible.

Une rapide étude du document de conformité du groupe de travail WCAG2ICT montre que dans beaucoup de cas, l’application des niveaux A et double AA des WCAG 2.0 aux logiciels n’est pas complètement évidente. Je pense qu’il est plus facile d’illustrer ce propos par trois exemples.

Critère de succès 1.3.2 (ordre séquentiel logique)

Dans certains cas, les exigences des WCAG 2.0 sont parfaitement transposables aux logiciels. Par exemple, le contenu du critère de succès 1.3.2 (ordre séquentiel logique) se lit comme s’il avait été pris directement de la spécification d’accessibilité d’un logiciel :

lorsque l’ordre de présentation du contenu affecte sa signification, un ordre de lecture correct peut être déterminé par un programme informatique.

Critère de succès 2.1.1 (clavier)

D’autres exigences des WCAG 2.0 ont un sens pour certains types de logiciels, mais pas pour d’autres. Par exemple, l’une des exigences fondamentales de niveau A des WCAG 2.0 est le critère de succès 2.1.1 (clavier) exige que :

toutes les fonctionnalités du contenu soient utilisables à l’aide d’une interface clavier sans exiger un rythme de frappe propre à l’utilisateur, sauf lorsque la fonction sous-jacente nécessite une saisie qui dépend du tracé du mouvement effectué par l’utilisateur et pas seulement des points de départ et d’arrivée de ce tracé.

Ce critère de succès est parfaitement approprié pour les pages web, parce qu’on accède à celles-ci par une multitude de périphériques différents incluant des ordinateurs avec des claviers. Mais l’application de ce critère de succès à un logiciel tactile sur une tablette ou un appareil mobile n’est pas pertinente, car les systèmes d’exploitation des mobiles peuvent fournir une accessibilité complète sans clavier. Par exemple, les applications sous iOS (comme l’iPhone, l’iPad, etc.) peuvent utiliser VoiceOver, qui est intégré dans le système d’exploitation d’iOS, pour rendre les contenus à l’écran très accessibles aux utilisateurs en situation de handicap, même si l’application elle-même ne peut pas utiliser le clavier.

Le rapport du groupe de travail WCAG2ICT peut ou peut ne pas prendre cela en considération, puisque les périphériques tactiles comme l’iPhone peuvent être considérés comme un périphérique avec une fonctionnalité fermée auquel cas l’accessibilité au clavier ne serait pas nécessaire selon l’annexe A du rapport. Mais il s’agit d’un terrain mouvant. Les avocats ne devraient pas obliger les développeurs à considérer ces zones. Au contraire, il faudrait choisir un jeu de règles plus approprié aux logiciels. Le document de conformité du WCAG2ICT clarifie ce critère de succès en notant que cela ne signifie pas que les logiciels doivent gérer directement un clavier ou une interface clavier. Sans ce conseil supplémentaire, les développeurs d’applications iOS seraient obligés d’ajouter le support du clavier à une application mobile tactile déjà complètement accessible. Cette redondance inutile entraîne un «recul» dans la communauté des technologies de l’information, affaiblit la norme WCAG 2.0 et ne sert pas aux besoins des personnes en situation de handicap.

Critère de succès 2.4.5 (accès multiples)

Toutefois, d’autres exigences des WCAG 2.0 ont peu d’intérêt dans le contexte des logiciels, obligeant les développeurs à des interprétations créatives (et controversées) de la façon dont ces exigences s’appliquent.

Par exemple, le critère de succès 2.4.5 (accès multiples) demande que : Il existe plus d’un moyen de situer une page web dans un ensemble de pages web sauf si cette page est le résultat ou une étape d’un processus. Le groupe de travail WCAG2ICT a retravaillé cette exigence comme suit : Il existe plus d’un moyen de situer un programme dans un ensemble de programmes sauf si ce programme est le résultat ou une étape d’un processus. Cette reformulation a du sens sur le plan linguistique, mais n’est pas logique.

Tout d’abord, la possibilité de basculer entre deux ou plusieurs programmes ne relève pas du contrôle du développeur de logiciel mais du développeur du système d’exploitation. Par exemple, sur mon PC, je peux basculer entre mon lecteur vidéo Quicktime Player (lecteur vidéo développé par Apple) et Chrome (mon navigateur développé par Google), ce qui ne peut être contrôlé ni par Apple ni par Google, mais par Microsoft, qui a développé le système d’exploitation Windows qui se trouve sur mon PC.

Afin de contourner cette limitation liée au système d’exploitation, le document du groupe de travail WCAG2ICT parle d’un «ensemble de programmes» dans le paragraphe 2.5. Pour tenter d’apporter des clarifications, le document du groupe de travail ajoute : l’exemple d’une suite de programmes serait un groupe de logiciels qui peuvent être lancés et utilisés séparément mais qui sont distribués ensemble et ont tous un menu permettant à l’utilisateur de lancer ou basculer vers chacun des autres programmes du groupe.

Le seul problème est que je ne connais aucun exemple d’un tel programme dans le monde réel. Un problème plus grave est que cette reformulation ne veut absolument rien dire dans le contexte des logiciels. Les sites web sont souvent informatifs et ont une structure complexe. C’est pourquoi, les bons développeurs incluent souvent des fonctionnalités comme le fil d’Ariane ou le plan du site pour éviter à l’utilisateur de se perdre sur un site web. L’analogie la plus proche de cet exemple dans le monde du logiciel serait un logiciel complexe avec toute une série de menus et boîtes de dialogue imbriqués les uns dans les autres. Malheureusement, cette interprétation du critère de succès 2.4.5 (qui pourrait arriver à un développeur comme cela m’est arrivé), n’est pas inscrite dans le document du groupe de travail WCAG2ICT. Cela montre qu’il y a de multiples façons d’interpréter comment appliquer le critère de succès 2.4.5 à un logiciel, ce qui crée de la confusion dans la communauté des technologies de l’information.

Ce n’est pas une critique du groupe de travail, mais une critique de la tentative de transposer les WCAG 2.0 dans leur ensemble aux logiciels sans tout d’abord réfléchir sérieusement à ce qui se fait dans le même temps.