WCAG 2.0, logiciels et applications mobiles – « C’est encore pire avec le mobile » (2/3)

C’est encore pire avec le mobile

L’utilisation des WCAG 2.0 pour les applications mobiles a suscité plus d’intérêt, en particulier après le jugement de HR Block. Étant donné que le ministère de la Justice était impliqué dans le procès, le jugement a été largement interprété comme le message qu’appliquer les WCAG 2.0 aux applications mobiles est facile à faire et que le ministère de la Justice compte sur cette application. Je prévois deux problèmes majeurs à attirer l’attention là-dessus.

L’accessibilité des applications mobiles est déjà un thème relativement nouveau et compliqué.

Comme discuté ci-dessous, l’accessibilité des logiciels se base généralement sur l’API (interface de programmation) – un concept qui n’existe pas dans les technologies web. Ces API sont très spécifiques au matériel et à l’interface utilisateur (UI) du périphérique.

Par exemple, certains périphériques mobiles utilisent un écran tactile et pas de clavier (comme l’iPhone), tandis que d’autres utilisent un clavier physique et pas d’écran tactile (comme les anciens BlackBerry). La façon d’obtenir une accessibilité optimale pour ces deux plateformes est évidemment très différente.

Le second problème est que beaucoup d’applications mobiles affichent des contenus web en dehors d’un navigateur, dans ces cas, considérer uniquement les WCAG 2.0 pourrait diminuer l’accessibilité.

En résumé, les WCAG sont l’interaction entre une page web et le navigateur, mais elles ne traitent pas du logiciel qui n’est pas le navigateur de ces appareils mobiles. Ainsi, une application mobile peut apparaître comme étant juste la coquille du navigateur, mais cela ne veut pas dire que cette application offre le même niveau de support d’accessibilité que le navigateur de l’appareil. Cela peut ressembler au navigateur, mais ce n’est pas le navigateur. En réalité, c’est juste un autre logiciel. À un niveau plus technique, les plateformes de logiciels mobiles permettent aux développeurs d’importer des classes et intègrent des composants comme des fenêtres, des boîtes de dialogue ou même des fenêtres de navigateur rudimentaires à inclure dans l’application mobile, mais cela ne veut pas dire qu’une fenêtre de navigateur est en fait le navigateur.

À l’été 2014, j’ai travaillé avec un centre scientifique de la côte du Midwest, qui développait ses propres applications iOS et Android, fournissant des informations de base à propos du centre scientifique par l’intermédiaire de pages web écrites spécifiquement pour n’être lues que par ces applications. Malheureusement, ces composants de navigateur ne sont pas le navigateur complet disponible sur ces plateformes mobiles – il n’est pas clair si elles supportent les techniques d’accessibilité des WCAG 2.0 dans la même proportion que le navigateur mobile complet.

Si l’on ne porte attention qu’aux WCAG 2.0 au lieu des API d’accessibilité du mobile, il est tout à fait possible que les développeurs de l’application mobile réduisent son niveau d’accessibilité. Par exemple, l’application mobile du centre scientifique qui vient d’être évoquée peut contenir un formulaire à remplir et envoyer par l’utilisateur. Ce formulaire peut être inclus dans une fenêtre de navigateur à l’intérieur de l’application mobile. Si l’on disait aux développeurs du centre scientifique de créer l’application en fonction des WCAG 2.0, ils inséreraient naturellement des balises dans les pages affichées par l’application mobile. Cela peut fonctionner parfaitement bien dans le navigateur de l’appareil mobile, mais il n’est pas sûr que le composant de navigateur relativement primitif intégré dans l’application mobile soit en mesure de reproduire les balises . Évidemment, le fait que cela fonctionne ou non dépend du système d’exploitation et de la plateforme logicielle du mobile, et ceci n’est pas du tout contrôlable par le développeur de l’application mobile. Si le composant de navigateur n’était pas assez robuste pour gérer les balises , l’application mobile serait inaccessible.

Ce résultat serait particulièrement malheureux si le système d’exploitation de l’application mobile avait une API permettant de rendre les formulaires avec des étiquettes accessibles en dehors du composant de navigateur. Dans ce cas, le développeur éviterait d’utiliser le composant de navigateur de l’application mobile et emploierait un simple composant de formulaire qu’il aurait été plus facile de rendre accessible via l’API d’accessibilité du système d’exploitation du mobile.

Au revoir les API

En implémentant une API d’accessibilité, les développeurs d’applications mobiles peuvent tirer profit des caractéristiques d’accessibilité spécifiques intégrées dans ces périphériques et systèmes d’exploitation.

Par exemple, au lieu d’intégrer dans le logiciel un programme de synthèse vocale compliqué, un développeur peut simplement saisir quelques lignes de code sur des plateformes mobiles et exploiter le logiciel de synthèse vocale intégré au système d’exploitation du mobile. Voilà, l’application mobile peut soudain parler ! Cependant, les API sont en constante évolution et très spécifiques au périphérique utilisé. Le fait d’obliger les développeurs d’applications mobiles à utiliser les WCAG 2.0 pour l’accessibilité fait effectivement croire aux développeurs que les API d’accessibilité ne sont pas importantes et peuvent être ignorées.

Bien sûr, les API d’accessibilité ne se limitent pas qu’aux appareils mobiles. Microsoft Windows, par exemple, propose Microsoft Active Accessibility (MSAA) depuis 1997, User Interface Automation (UIA) depuis 2005. En terme d’accessibilité, UIA est une solution d’accessibilité particulièrement puissante. Elle donne un accès très robuste et le contrôle sur presque tout ce que l’utilisateur peut percevoir ou ce avec quoi il peut interagir. De plus, comme son nom l’indique, elle permet un niveau bien plus élevé de test automatisé de l’accessibilité par rapport aux tests actuellement disponibles dans toute autre technologie – et infiniment plus élevée par rapport aux WCAG 2.0 (qui sont beaucoup moins spécifiques en ce qui concerne l’articulation exacte des techniques d’accessibilité). Cela rend le développement et le test minutieux de l’accessibilité des applications bien plus faciles.

Cependant, le plus important est que les API fournissent un point de rencontre parfait entre les logiciels et les technologies d’assistance (TA). Après tout, c’est la raison pour laquelle on les appelle interfaces de programmation. Elles fonctionnement comme un «contrat» pour les développeurs. Lorsqu’ils implémentent une interface, ils acceptent d’implémenter certaines fonctionnalités de façon spécifique (en général par l’intermédiaire de méthodes ou fonctions qui doivent avoir une entrée et une sortie spécifiques). Ce qu’ils obtiennent en retour est l’accord que ces entrées et sorties seront utilisées de manières spécifiques et concertées. En effet, la plupart des logiciels de lecture d’écran puissants (tels que Jaws, Window-Eyes et NVDA) reposent sur ces API. Tant que le développeur a respecté sa partie du «contrat» en implémentant l’API correctement, le vendeur de la technologie d’assistance peut utiliser cette API et garantir sa restitution accessible à l’utilisateur final. Évidemment, nous ne devons pas tourner le dos à ces opportunités d’accessibilité passionnantes, mais c’est exactement ce que les développeurs seraient tentés de faire en se concentrant uniquement sur les WCAG pour l’accessibilité.

Le meilleur des deux mondes

Une meilleure approche de l’accessibilité des logiciels comprend :

1. Emprunter aux WCAG. Plusieurs exigences des WCAG 2.0 sont parfaitement applicables aux logiciels. D’autres doivent être retravaillées ou être extrêmement clarifiées. D’autres doivent tout simplement être abandonnées concernant l’accessibilité des logiciels. L’emprunt sélectif aux WCAG 2.0 permettra d’harmoniser les normes pour les logiciels avec l’ébauche du paragraphe 508 du comité Accessibilité, et donnera aux développeurs un ensemble commun d’attentes sur les UI fonctionnelles, que ces éléments d’UI apparaissent sur des pages web ou dans des logiciels.
2. Se servir d’APIs existantes. Nous ne voulons certainement pas jeter le bébé avec l’eau du bain et ignorer les APIs d’accessibilité existantes.

Il se trouve justement que ce type de norme hybride existe déjà. Au cours de l’année 2014, l’Institut Européen des normes de télécommunications (ETSI) qui est l’organe officiel des normes pour l’Union Européenne, a annoncé la publication de la norme EN 301-549 (en anglais) comme la norme officielle pour l’accessibilité des technologies de l’information du secteur public des membres de l’UE. Une copie de cette norme est disponible en anglais sur le site web de l’ETSI au format PDF (1,4 Mo).

Depuis la sortie du paragraphe 508 original en 2000, il y a eu une forte pression afin d’harmoniser les normes pour l’accessibilité des technologies de l’information dans le monde. Ainsi, après que le comité Accessibilité américain a publié le projet de mise à jour du paragraphe 508 en 2011, l’Union européenne était sous une forte pression pour harmoniser ses standards. En conséquence, la norme sur les logiciels fait grandement référence aux WCAG 2.0, mais la norme EN 301-549 a fait des efforts très délibérés pour adopter de façon sélective les WCAG 2.0 de niveau A et double AA.

Par exemple, cet exemple troublant du critère de succès 2.4.5 (accès multiples) a été supprimé de la norme EN 301-549 sur les logiciels (d’autre part, il est conservé dans la norme EN 301-549 pour le web puisqu’il en fait logiquement partie). En ce qui concerne l’autre exemple du critère de succès 2.1.1 (accès au clavier), la norme va au-delà du groupe de travail WCAG2ICT en limitant l’application du critère de succès aux logiciels uniquement lorsque le logiciel supporte spécifiquement l’accès au clavier ou à une interface clavier – ce qui évite la confusion pour les applications mobiles qui dépendent entièrement d’écrans tactiles. En d’autres termes, la norme EN 301-549 se sert judicieusement des WCAG 2.0.

De plus, la norme EN 301-549 exige que les systèmes d’exploitation et les plateformes logicielles aient une API d’accessibilité (exigences 11.3.2.1 et 11.3.2.2). Elle encourage aussi les développeurs à supporter cette API (exigence 11.3.2.1 et 11.3.2.3) – autrement le développeur doit satisfaire à une longue liste d’autres caractéristiques spécifiques d’accessibilité – et elle exige que les technologies d’assistance supportent l’API d’accessibilité de la plateforme (11.3.2.4). Autrement dit, la norme EN 301-549 encourage fortement l’utilisation d’API d’accessibilité existantes.

La forte demande d’harmonisation mentionnée plus haut fonctionne dans l’autre sens – les États-Unis vont être mis sous pression pour faire en sorte que la version définitive du standard du paragraphe 508 s’harmonise avec la norme EN 301-549. On peut donc supposer que le prochain paragraphe 508 ressemblera beaucoup à la norme EN 301-549.

Néanmoins, y a-t-il une garantie que les logiciels qui affichent du contenu web feront en sorte que tout balisage d’accessibilité dans ce contenu web sera transmis fidèlement aux TA ? C’est ce qui pourrait arriver potentiellement à l’application du centre scientifique que je mentionnais plus haut. La norme EN 301-549 exige la compatibilité et l’interopérabilité avec les TA. Ainsi, les balises et autres fonctionnalités insérées dans le contenu web seront fidèlement transmises aux TA présentes sur le même périphérique.

À première vue, on peut être tenté de dire que les logiciels doivent être conformes aux User Agent Accessibility Guidelines (UAAG), une série de recommandations qui ont aussi été développées par le W3C pour le développement de logiciels qui restituent le contenu web (comme les navigateurs). Le seul problème est que UAAG est toujours un document de travail et, selon les rumeurs, il y a de bonnes raisons de croire qu’il n’y aura jamais de document final. De plus, à l’exception de Microsoft, aucun autre grand développeur de navigateur n’est membre du groupe de travail UAAG (liste en anglais). On m’a dit aussi qu’aucun fabricant de navigateur ne supporte UAAG – ou n’en a l’intention.

C’est pourquoi UAAG n’est pas la solution.