3 bonnes pratiques pour la conception d'applications mobiles plus accessibles
Rappelons-le : l’accessibilité numérique est un ensemble de bonnes pratiques et normes qui couvrent : les aspects fonctionnels, le design, le développement technique et le rédactionnel. Ces règles permettent de s’assurer que les supports numériques (sites internet, applications mobiles, documents…) sont parfaitement accessibles à tous les utilisateurs en situation de handicap.
Une application mobile accessible permet par exemple de :
- Personnaliser l'affichage de l'application selon ses besoins (grossissement des caractères, modification des couleurs, changement de la typographie, arrêt des animations, etc.).
- Naviguer à l’aide d’outils d’assistance comme des synthèses vocales ou des plages braille.
- Naviguer sans utiliser le toucher, avec des contacteurs ou via un clavier connecté au smartphone.
- Consulter les vidéos ou podcasts à l’aide de sous-titres ou de transcription.
- Etc.
Je vous propose de découvrir aujourd'hui 3 bonnes pratiques de conception fonctionnelle accessible tirées des WCAG 2.1 (Web Content Accessibility Guidelines).
Si vous souhaitez en découvrir davantage ou discuter autour de ces points, n'hésitez pas à commenter cet article. Nous sommes également disponibles chez Ideance pour accompagner vos projets et vos équipes dans la prise en compte de l'accessibilité numérique.
1. Prévoir une application utilisable quelle que soit l’orientation
Si ce point est très souvent pris en compte sur les sites web, il est beaucoup plus rarement prévu dans les applications mobiles.
Il est essentiel de permettre à l'utilisateur de choisir l'orientation qu'il souhaite pour afficher une application.
Certaines personnes peuvent avoir des difficultés de préhension, rencontrer des douleurs à la main, etc. D'autres ne tiennent pas directement leur smartphone en main, et ne peuvent pas facilement (voire pas du tout) modifier leur orientation, c'est par exemple le cas des personnes en situation de handicap moteur qui fixent leurs smartphones ou tablettes à l'aide d'un bras articulé et le contrôlent à l'aide de contacteurs.
Dans la courte vidéo qui suit, vous pourrez par exemple découvrir Todd Stabelfeldt faire une démonstration de Switch Control sur iOS (l'équivalent sur Android est Switch Access). À l'aide de contacteurs il est en mesure de piloter l'intégralité de son smartphone et des applications (sous réserve qu'elles soient accessibles).
Si votre application n'est en mesure de s'adapter à l'orientation de son téléphone, son expérience utilisateur sera très fortement dégradée. Il ne peut pas modifier seul l'orientation de son smartphone.
Pire encore, si vous imposez une orientation et empêchez l'utilisation de l'application dans l'autre sens, il se retrouvera dans l'incapacité totale de l'utiliser.
Plus d'informations sur le critère de succès WCAG : 1.3.4 Orientation
2. Prévoir des zones de clics/toucher suffisamment grandes
Utiliser un écran tactile et pointer avec précision une zone peut être complexe pour certains utilisateurs, les exemples sont nombreux :
- Tremblements, douleurs articulaires...
- Difficulté pour déplier des doigts (ou impossibilité)
- Amputation, malformation...
- Utilisation de licornes et tiges buccales
Photo tirée du site systergo.fr.
Les WCAG demandent que chaque zone de clic ait une taille d’au minimum 44 x 44px CSS (2.5.5 Target Size). Il s'agit bien de la taille de la zone interactive et non de l'icône ou du texte. En effet, si une icône est plus petite ce n'est pas un problème à partir du moment où la zone interactive ne se limite pas à celle de l'image.
À noter que des travaux pour faire évoluer WCAG sont actuellement en cours et il est prévu un nouveau critère de succès à ce succès : 2.5.8: Pointer Target Spacing (il précise notamment des cas particuliers dans le cas d'éléments interactifs côte-à-côte ou les uns sous les autres).
Google et Apple fournissent également des préconisations (utiles notamment car l'unité px CSS n'est pas adaptée dans le cas d'applications natives) :
- Apple Developers, Adaptivity and Layout : "try to maintain a minimum tappable area of 44pt x 44pt for all controls"
- Material Design (Google), Layout and typography : "consider making touch targets at least 48 x 48 dp"
Il est possible, sur Android de tester facilement les tailles de zones interactives d'une application grâce à Accessibility Scanner :
3. Proposer une alternative aux actions gestuelles
Nous l'avons vu dans les 2 bonnes pratiques précédentes, tous les utilisateurs ne se servent pas de leurs smartphones de la même façon. Je vous invite d'ailleurs à découvrir cet excellent article de présentation des contacteurs (appelés Switch en anglais) :
Qu'ils se servent d'aides techniques ou non, de nombreux utilisateurs peuvent être limités ou dans l'incapacité de réaliser de certains mouvements sur l'écran. Il est donc essentiel de prévoir des alternatives aux fonctionnalités qui nécessitent des gestes complexes sur l'écran.
S'il est possible de zoomer/dézoomer sur une carte en pinçant l'écran, prévoyez également qu'il soit possible, par exemple, de le faire en utilisant également des boutons prévus à cet effet.
Plus d'informations sur le critère de succès WCAG : 2.5.1 Pointer Gestures
Et bien plus encore
Il y a bien entendu plusieurs autres règles et bonnes pratiques pour assurer une conception et un développement accessible des applications mobiles. Je serai ravi de vous en partager d'autres ici dans les prochaines semaines, vous apprendrez également plein de choses sur ces excellentes ressources :
- Apple Developers > Human Interface Guidelines > Accessibility
- Material Design > Accessibility
- Les critères incontournables sous Android pour la conception (recommandations proposées par le centre de compétences groupe d'Orange sur l'accessibilité numérique.)
- Les critères de conception iOS (recommandations proposées par le centre de compétences groupe d'Orange sur l'accessibilité numérique.)
Si vous souhaitez être accompagnés ou formés à la prise en compte de l'accessibilité dans vos projets mobiles, n'hésitez pas à me contacter.