Les Directives pour l’accessibilité des contenus Web (WCAG) constituent depuis deux décennies la norme en matière d’accessibilité numérique à l’échelle mondiale. Bien qu’elles n’aient pas été conçues spécifiquement pour régir les applications mobiles natives, bon nombre de ces directives peuvent s’y appliquer, soit directement, soit moyennant une interprétation judicieuse. Le W3C s’apprête à publier la version 2.2 des WCAG, qui ajoute plusieurs nouveaux critères de succès élargissant les exigences pour les utilisateurs malvoyants, présentant des troubles cognitifs ou ayant une motricité fine limitée. Nous verrons ci-dessous si et comment chacune d’entre elles peut s’appliquer aux applications mobiles natives.
Nouveaux critères de réussite
La proposition WCAG 2.2 comporte actuellement neuf nouveaux critères de conformité. Ceux-ci sont encore en cours d'examen ; il n'est donc pas certain qu'ils soient tous intégrés à la recommandation finale. La liste des nouveaux critères de conformité, telle qu'elle figure dans la recommandation candidate du 6 septembre 2022, est la suivante :
2.4.11 Apparence de l'élément actif (minimum) (niveau AA)
2.4.12 Élément actif non masqué (minimum) (niveau AA)
2.4.12 Élément actif non masqué (amélioré) (niveau AAA)
2.5.7 Mouvements de glissement (niveau AA)
2.5.8 Taille de la cible (minimum) (niveau AA)
3.2.6 Aide cohérente (niveau A)
3.3.7 Authentification accessible (niveau AA)
3.3.8 Authentification accessible (sans exception) (niveau AAA)
3.3.9 Saisie redondante (niveau A)
Focus : Apparence
Ce critère de succès garantit que les utilisateurs voyants qui naviguent sur une page Web à l’aide d’un clavier disposent d’un « indicateur de focus » clairement visible qui leur indique où ils se trouvent sur la page. Dans le cas des applications mobiles natives, cela concerne les utilisateurs qui naviguent à l’aide de technologies d’assistance telles que « Switch Control » ou « Full Keyboard Access » pour iOS, ou « Switch Access » pour Android. Sur ces deux plateformes, la couleur, la taille et la forme de l’indicateur de sélection sont dictées par le système d’exploitation. Cela signifie qu’un développeur ne peut pas modifier l’apparence de l’indicateur de sélection dans son application et bénéficie donc d’une exception pour ce critère. Il s’agit du seul nouveau critère de conformité qui ne peut pas s’appliquer aux applications mobiles natives.
Une vision claire
À l’instar du critère « Apparence du focus », ces deux critères de conformité portent sur la capacité d’un utilisateur voyant utilisant le clavier à voir où se trouve son point de focus actuel. Là encore, dans le cas des applications mobiles natives, le focus clavier peut être interprété comme l’indicateur de focus pour diverses technologies d’assistance telles que « Commande par commutateur/Accès », « Accès complet au clavier » ou « Commande vocale/Accès ». Le critère minimal stipule que lorsqu’un composant reçoit le focus, il ne doit pas être entièrement masqué par d’autres composants. Le critère renforcé exige que, lorsqu’un composant reçoit le focus, aucune partie de l’indicateur ne soit masquée par d’autres composants. Ces deux critères, avec une interprétation plus large du focus clavier, peuvent s’appliquer aux applications mobiles natives. Un exemple de ce problème sur les sites web se produit lorsqu’un composant qui reçoit le focus est recouvert par un en-tête ou un pied de page fixe. Cela peut s’appliquer aux applications mobiles natives lorsqu’un composant qui reçoit le focus est masqué par une barre supérieure ou inférieure.
Mouvements de glissement
Les actions de glisser-déposer sont sans doute plus courantes dans les applications mobiles natives que sur les pages web. Par exemple, imaginez que vous créiez une playlist sur Spotify ou Apple Music : vous pouvez modifier l’ordre des morceaux en les faisant glisser et en les déposant à l’endroit souhaité. Ces interactions nécessitent des mouvements assez précis et la capacité de maintenir un doigt sur l’écran sans le relâcher accidentellement, ce qui peut s’avérer difficile pour les personnes souffrant de troubles moteurs. Ce critère de conformité exige que toutes les actions utilisant des mouvements de glissement puissent également être effectuées à l’aide d’un seul pointeur. Dans le cas des applications mobiles natives, ce pointeur unique peut être interprété comme un simple tapotement du doigt.
Taille cible
Plus un élément de commande est petit, plus il est difficile à activer, en particulier pour les personnes dont la motricité fine est réduite. Ce critère de succès exige une taille minimale de la cible de 24 × 24 pixels CSS ou un espacement minimal de 24 × 24 pixels CSS pour certains éléments de commande. Cela s'applique aux applications mobiles natives ; toutefois, ce critère de succès ne peut pas être appliqué directement puisqu'il est défini en pixels CSS. Le CSS n'existant pas dans les applications mobiles natives, cette directive doit être adaptée aux échelles de pixels iOS et Android. Pour iOS, 24 pixels CSS peuvent être remplacés par 24 pt, et pour Android par 24 DP.
Une aide cohérente
Ce critère de succès exige que, si certaines pages web d'un ensemble proposent une forme d'aide (telle que des coordonnées ou une FAQ), au moins une de ces formes d'aide soit placée au même emplacement relatif sur chaque page où cette aide apparaît. Cette exigence permettra aux utilisateurs de trouver plus facilement de l'aide lorsqu'ils en ont besoin. Bien que l'exigence mentionne explicitement les pages web, elle peut être interprétée comme s'appliquant également aux écrans d'une application mobile native.
Authentification accessible
La connexion à un site web ou à une application peut s’avérer difficile lorsque les utilisateurs doivent mémoriser leur nom d’utilisateur et leur mot de passe et/ou saisir un code d’authentification à deux facteurs (2FA) reçu par SMS. Ces critères de conformité exigent que l’authentification soit possible sans ces tests cognitifs ou qu’un mécanisme soit mis en place pour aider les utilisateurs à les effectuer. Cette directive s’applique directement aux applications mobiles natives. iOS et Android disposent tous deux de fonctionnalités permettant d’aider les utilisateurs à effectuer ces tests cognitifs d’authentification. Par exemple, les applications iOS peuvent prendre en charge Keychain, le gestionnaire de mots de passe d’Apple, afin d’éviter aux utilisateurs d’avoir à mémoriser leurs noms d’utilisateur et mots de passe. Sur Android, l’application Messages de Google propose un bouton permettant de copier le code de sécurité issu d’un SMS d’authentification à deux facteurs (2FA) directement depuis la notification.
Entrée redondante
Certains formulaires nécessitent la saisie répétée de certaines informations, par exemple les adresses de livraison et de facturation. Ce critère de conformité exige la mise à disposition de mécanismes tels que le remplissage automatique afin de réduire la fatigue liée à la saisie répétée. Ce critère peut s'appliquer directement aux applications mobiles natives, car la directive n'utilise aucune terminologie spécifique au Web.
Publication
La norme WCAG 2.2 devrait être publiée en tant que recommandation officielle du W3C d'ici la fin de l'année 2022. À mesure que les autorités réglementaires adopteront cette mise à jour, nous pourrions progressivement voir cette norme devenir une obligation légale dans divers pays à partir de 2023.
Deque prévoit de proposer les WCAG 2.2 en option pour les audits d'applications mobiles natives peu après leur publication.
