L'un des aspects les plus complexes de l'accessibilité mobile réside dans le fait que la plupart des développeurs, responsables, concepteurs d'interfaces utilisateur, ingénieurs logiciels, etc. ne souffrent pas d'un handicap qui rendrait difficile l'utilisation des sites web et des applications mobiles. En d'autres termes, ils ne sont pas en mesure d'envisager le processus du point de vue de l'utilisateur. Si cette situation est compréhensible, elle rend néanmoins leur travail plus difficile en matière d'accessibilité.
Pour une personne qui n’a pas de déficience visuelle, il est facile de regarder une application, de repérer le « X » rouge et de fermer une fenêtre modale. Mais qu’en est-il de ceux qui ne voient pas ? De la même manière, vous prenez sans doute votre téléphone et faites glisser votre doigt sur l’écran pour supprimer un SMS sans même y réfléchir à deux fois. Mais qu’en est-il de ceux qui ne peuvent pas effectuer cette action ? Certains utilisateurs empathiques ont peut-être conscience de l’existence de ces handicaps. Mais il est encore trop fréquent que même les utilisateurs les plus empathiques passent à côté d’une information essentielle qui pourrait ne pas être accessible aux personnes souffrant d’un handicap visuel – comme le daltonisme.
Dans cet article, je vais expliquer en quoi l’afflux massif de nouvelles applications sur le marché va souvent à l’encontre de l’objectif visant à rendre les applications mobiles natives accessibles. Je montrerai ensuite comment l’approche de Dequeen matière de formation à l’accessibilité peut aider à former les développeurs à concevoir des applications en tenant compte de l’accessibilité.
Le problème : concilier l'« évolution rapide des applications » et l'accessibilité
Le développement d'applications mobiles natives est encore relativement récent par rapport à d'autres formes de développement d'applications. À mesure que les applications natives et les API évoluent, la question de l'accessibilité devient encore plus complexe. Les systèmes d'exploitation mobiles natifs ont par nature tendance à évoluer rapidement, mais les besoins des utilisateurs en situation de handicap sont en contradiction avec cette évolution rapide des applications.
Chaque année, de nouvelles API sont lancées, offrant aux développeurs les dernières nouveautés en matière d’interface utilisateur, mais ces nouvelles API ne font pas l’objet d’une évaluation complète en matière d’accessibilité de la part des concepteurs du système d’exploitation. Trop souvent, les développeurs ne maîtrisent même pas pleinement les meilleures façons d’utiliser ces nouveaux mécanismes dans le cadre d’une utilisation standard, sans parler des pratiques de conception qui permettraient de les rendre accessibles. Les API d’accessibilité natives ont tendance à évoluer beaucoup plus lentement que le reste du système d’exploitation, omettant ainsi des mécanismes qui pourraient rendre ces nouvelles fonctionnalités accessibles, ce qui rend l’accessibilité native sur mobile particulièrement difficile.
Le fait est qu’il n’y a pas assez d’experts en accessibilité mobile native dans le monde pour répondre à la demande croissante d’applications toujours plus récentes et plus attrayantes. Il est inévitable que la plupart des applications soient lancées sans jamais avoir été examinées par une personne pleinement consciente de l’importance de rendre une application accessible aux utilisateurs en situation de handicap.
Chez Deque , nous sommes confrontés à ce problème au quotidien. C’est en grande partie pour cette raison que nous avons créé la Deque : pour aider les développeurs à comprendre les difficultés rencontrées par les personnes en situation de handicap, et leur fournir les outils et la formation dont ils ont besoin pour faire de l’accessibilité une réalité.
Avant tout, l'objectif de cet article s'inscrit dans le cadre de notre mission d'inclusion : vous aider à mieux comprendre comment rendre votre application « accessible » afin que tout le monde puisse l'utiliser.
Pour commencer
Je vais vous présenter ici, étape par étape, les consignes relatives à l’initiative « Deque » qui vous permettront de mieux comprendre les difficultés auxquelles sont confrontés les utilisateurs en situation de handicap.
- Configurer l'application
La toute première étape consiste à configurer l'application.
- Téléchargez l'application « Deque University » pour iOS depuis l'App Store ou découvrez l' Deque application open source « University » pour iOS sur GitHub. (Si vous utilisez Android, téléchargez Deque University pour Android sur Google Play ou le Deque projet open source « University for Android »). Remarque : cet article portera principalement sur iOS, mais l’application Android est très similaire et les captures d’écran ainsi que les descriptions seront probablement très proches, voire identiques, sur Android.
- Activez la technologie d'assistance de votre choix (VoiceOver (iOS) ou TalkBack (Android)). Avant d'ouvrir l'application « Deque University » sur votre appareil mobile.
Dans le cadre de cet article, je vais utiliser l’Inspecteur d’accessibilité. VoiceOver vous fournit les mêmes informations par voie audio.
2) Activer la superposition de démonstration à l'aveugle
Maintenant que VoiceOver est activé, lancez l'application et ouvrez le menu de navigation principal. Il devrait s'agir d'un menu de navigation de type « tiroir » classique, comportant des rubriques telles que « Introduction », « Étiquettes », « Astuces », etc. Commençons par l'exemple des étiquettes.
- Lorsque vous cliquez sur l'exemple des étiquettes, une fenêtre devrait s'afficher pour expliquer l'utilité des étiquettes d'accessibilité.
Avant de passer aux vues suivantes, jetez un œil au coin supérieur droit.
- Il y a une petite icône en forme d'œil, avec une coche. Cliquez sur ce bouton. Vous devriez maintenant voir une image grise intitulée « Simulation VoiceOver » recouvrir l'intégralité de votre écran. L'affichage sous-jacent n'a pas changé ; il s'agit simplement d'un affichage destiné à vous faire découvrir l'application telle qu'une personne aveugle la percevrait.
3) Testez l'exemple des étiquettes d'accessibilité
- Faites défiler l'application jusqu'à ce que vous trouviez le bouton intitulé « Broken », puis activez-le.
- Maintenant que vous êtes dans l'onglet « Broken », essayez de naviguer dans l'application et de comprendre son fonctionnement.
- Arrivez-vous à comprendre ? Ne trichez pas en écoutant le paragraphe en bas de page ! C'est très difficile de comprendre à quoi sert cette vue, n'est-ce pas ? Ensuite, cliquez sur le bouton intitulé « Fixed » et activez-le. Le but de cette vue vous paraît-il plus clair maintenant ?
- Quand vous pensez avoir tout compris, désactivez la superposition de simulation à l'aveugle et jetez un coup d'œil pour vérifier…
4) Découvrez des exemples plus avancés
L'étiquetage des éléments d'accessibilité est l'un des mécanismes d'accessibilité les plus élémentaires. Sans étiquetage de base, les images, les boutons « Go », les contrôles personnalisés et les liens peuvent prêter à confusion. Il ne s'agit là que d'un exemple très simple. À mesure que les exemples gagnent en complexité, les versions Android et iOS de l'application divergent quelque peu. Cela est nécessaire, car les contrôles natifs et les API d'accessibilité présentent des atouts et des faiblesses différents.
Si vous avez des idées d'exemples ou si vous souhaitez en savoir plus sur un contrôle en particulier, n'hésitez pas à laisser un commentaire ! Vous pouvez également contribuer à notre application open source ou lancer une discussion sur GitHub.
Les applications de l'université « Deque » comportent de nombreux exemples d'utilisation non accessible des contrôles natifs, afin de vous aider à comprendre en quoi une mauvaise utilisation des API d'accessibilité peut dérouter les utilisateurs en situation de handicap.
N’hésitez pas à explorer davantage l’application et veillez à utiliser la fonction « Blind Simulation Overlay ». Entraînez-vous à utiliser vos applications de la même manière et voyez si vous vous surprenez à masquer des informations destinées uniquement à ceux qui peuvent voir.
Chris McMeeking est ingénieur logiciel et architecte chez Deque Systems, où il dirige les efforts de développement des produits natifs d’analyse de l’accessibilité mobile d’ Deque. Son parcours dans le domaine de l’accessibilité a débuté avec un projet mené à l’université du Michigan, le clavier à balayage ASK. Cette application a remporté de nombreux prix, notamment l’Intel Innovator’s Award d’une valeur de 100 000 dollars, la deuxième place au Mobile World Congress et le prix « Student of Da Vinci » décerné par la Fondation pour la sclérose en plaques.
