3 bonnes pratiques pour la conception d'applications mobiles plus accessibles

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

Aperçu d'une application mobile commerçante affichée dans un smartphone en vue portrait. Lorsque le smartphone est retourné en paysage l'application mobile s'adapte.

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.

Aperçu d'une application mobile affichée dans un smartphone en vue portrait. Lorsque le smartphone est retourné en paysage l'application mobile ne s'adapte pas et reste toujours affichée en mode portrait.

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.

Aperçu d'une application mobile commerçante affichée dans un smartphone en vue portrait. L'application n'affiche rien d'autre que "Please turn your device" (s'il-vous-plait, tournez votre smartphone).

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
Visuel d'un embout de licorne utilisé avec un smartphone.

Photo tirée du site systergo.fr.

Visualisation de boutons sur un smartphone avec les hauteurs et largeurs de zones interactives fixées à 44 px.

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"
Visuel Apple qui montre un bouton dont la zone d'interaction est de 44pt x 44pt (bon exemple) et un autre exemple où la zone est plus petite et se chevauchent avec un autre bouton (mauvais exemple).

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.

Exemple d'une application qui affiche une carte avec la possibilité de zoomer/dézoomer en faisant un mouvement pincement des doigts 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.

Sur la même application que précédemment des boutons + et - permettent de zoomer/dézoomer la carte en complément des gestes à l'écran.

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 :

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.

Identifiez-vous pour afficher ou ajouter un commentaire

Autres pages consultées

Explorer les sujets