Pistes pour développer des apps accessibles

Les smartphones et tablettes qui tournent sur Android et iOS peuvent être bien utilisables par les personnes handicapées. Pour plus d'infos à ce sujet, voyez notre article Naviguer sur internet avec un dispositif mobile.

Vous êtes de plus en en plus nombreux à nous demander des conseils pour développer une app accessible, ou pour vérifier l'accessibilité d'une app existante. Nous voulons dans cet article vous donner quelques pistes. Vous trouverez ci-dessous quelques conseils généraux ainsi que des liens vers des ressources pour les développeurs. Nous nous limiterons pour cette fois-ci aux plateformes iOS et Android.

Pour évaluer l'accessibilité d'un site web nous nous basons sur les Web Content Accessibility Guidelines. Ces critères sont formulés indépendamment des technologies et devraient donc être utilisables pour évaluer des apps.

Quand on évalue l'accessibilité d'une app, il y a effectivement une partie des tests qui se rapprochent de ceux que l'on peut faire sur un site web. Par exemple : les boutons sont-ils bien étiquetés, les liens significatifs, les tableaux linéarisables, les validations de formulaire sont-elles claires pour ceux qui ne voient pas l'écran, etc ?

Par contre il est pour nous plus difficile de dire ce qui cause les problèmes identifiés et comment ils peuvent être résolus. Nous ne pouvons pas consulter facilement le code source comme dans un site web.

Utilisable au clavier

La première des directives AnySurfer demande que toutes les fonctionnalités soient utilisables avec le clavier. Comment cela se traduit-il dans le cas d'un écran tactile ?

Un utilisateur aveugle utilise un écran tactile d'une manière fort différente de quelqu'un qui peut voir. Les lecteurs d'écran comme VoiceOver pour iOS et Talkback pour Android font bien plus que lire ce qui est affiché à l'écran. Ils offrent tout un système d'interaction, y compris des gestes adaptés. Voyez comment cela fonctionne dans cette vidéo : balayer l'écran de gauche à droite avec un doigt déplace le focus à l'élément suivant (comme le TAB du clavier).

En tant que développeur il faut veiller à ce que ce focus puisse se déplacer à travers tous les éléments interactifs de l'app, et que ce déplacement ait lieu dans un ordre logique.

Sémantique

Utilisez le plus possible des éléments standards pour construire des éléments interactifs. Leur comportement sera alors prévisible et compréhensible quel que soit le mode d'interaction.

Les lecteurs d'écran annoncent le rôle de l'élément (case à cocher), son nom (le label du champ), et son état (cochée). Si vous programmez des éléments vous-même (par exemple une fausse case à cocher) vous devrez programmer vous-même toutes les fonctionnalités et les tester de manière approfondie (avec des lecteurs d'écran).

Les images ont une alternative textuelle

Les images d'un site web doivent avoir un attribut alt. Dans les apps les boutons doivent avoir une alternative textuelle. Le principe est le même mais la technique pour donner une alternative textuelle diffère d'un environnement de développement à l'autre.

Si vous oubliez d'étiqueter un bouton, en général c'est le nom du fichier qui est lu, au lieu de la fonction du bouton. En tant qu'utilisateur on préfère entendre "retour" que "NavBarIconBackButtonSmall".

Documentation pour les développeurs

Il existe, pour iOS ainsi que pour Android, de la documentation qui explique comment développer des applications accessibles sur ces plateformes.

• Accessibility Programming Guide for iOS : Making Your iOS App Accessible
• Android Accessibility

A côté de ces guides, il y a également les Mobile Accessibility Guidelines de la BBC, qui ont l'avantage de donner pour chaque critère les techniques pour iOS, Android et HTML.