Cet article ne sera pas une ligne de code, pas un seul terme complexe. J'essaierai de dire de telle manière que même une personne loin du développement comprend.
Il s'agira de la mise en œuvre de l'accessibilité (accessibilité) dans une application mobile.
Bref historique
Récemment, au nom du projet Accessible Life, j'ai commencé à aider Yandex à mettre en œuvre l'accessibilité de leurs applications de navigation.
J'étais confronté au fait que beaucoup de choses qui ne me viennent pas à l'esprit sont évidentes de mon point de vue: des éléments invisibles à l'écran, la sortie directe de messages vocaux à l'aide de l'API du programme d'accès à l'écran, etc.
J'ai donc décidé de déclarer tout cela dans un article séparé.
En général, allons-y.
Objets invisibles
Le problème
Lors du travail sur les cartes, nous avons rencontré un problème:
Lorsque vous cliquez sur une zone de l'écran avec une carte, l'application doit changer de mode (je ne me souviens pas des détails avec certitude).
Pour un utilisateur aveugle avec un programme d'accès à l'écran, cette action apparemment simple devient impossible.
Le fait est que les programmes d'accès à l'écran «ne voient» que des objets spécifiques à l'écran: boutons, blocs de texte, champs de saisie, commandes et listes. Et dans l'application Yandex.Maps, cliquer sur la carte n'était pas traité comme une sélection d'un objet, mais comme une touche sur une zone spécifique de l'écran.
Solution
La solution est assez simple: faire un bouton sur l'écran sans cadre, avec un fond transparent et sans texte visible (police zéro, ce qui n'est pas si esthétique du point de vue du programmeur, ou attributs spéciaux qui affichent du texte uniquement pour les programmes d'accès à l'écran sans l'afficher à l'écran).
Cette approche a choqué et surpris les programmeurs, mais dans la pratique, tout a fonctionné, l'idée a fonctionné et est activement introduite partout où vous avez besoin de traiter les clics directs sur la zone d'écran.
Sortie directe des messages vocaux à l'aide du programme d'accès à l'écran lui-même
Le problème
Un autre problème était que, parfois, il est nécessaire d'afficher des informations supplémentaires uniquement pour l'utilisateur aveugle. Dans ce cas, les messages contextuels gâcheront la conception et interféreront avec les autres, et la mise en œuvre d'un mode d'application distinct dans lequel ces messages seront affichés est lourde et illogique.
Solution
La solution n'est pas aussi évidente que dans le cas des boutons invisibles, mais elle réside également en surface.
Vous devez utiliser l'API du programme d'accès à l'écran lui-même pour afficher les messages. Il semble moins volumineux dans le code du programme, il n'oblige pas le développeur à faire des efforts supplémentaires pour créer des modes séparés, des paramètres supplémentaires, etc.
Soit dit en passant, si vous utilisez l'API de lecteur d'écran, vous n'avez même pas besoin de vérifier si elle est activée. Si le programme est en cours d'exécution, il affichera un message en utilisant le synthétiseur vocal sélectionné par l'utilisateur. Et si le programme est désactivé, rien ne se passera et l'utilisateur moyen ne remarquera rien.
Partagez!
Le problème
Il s'agit d'une recommandation plutôt que d'un hack de vie, mais je suis obligé de le mentionner.
N'oubliez pas qu'il n'y a que des objets sur l'écran pour le programme d'accès à l'écran?
Ainsi, le type d'objet est également important. Le texte ne peut pas être cliqué, à son avis, mais le bouton ne peut pas être copié. C'est-à-dire que si la table des paramètres est implémentée comme un gros bloc de texte qui "attrape" les clics sur différentes parties de lui-même, alors une telle table n'est pas disponible pour le programme d'accès à l'écran. Il sera lu, mais il ne permettra pas d'interaction.
Solution
La solution est assez simple: utilisez les éléments comme prévu.
S'il doit s'agir d'une liste, vous devez utiliser l'élément décrivant la liste dans le code;
s'il s'agit d'un bouton, ce doit être le bouton; si c'est un curseur, un régulateur de quelque chose, alors ce devrait être un élément du curseur, et non du texte avec animation lors du glissement.
Conclusion
En conclusion, je tiens à dire que le développement pour Windows, bien que non essentiel, est différent du développement pour les plates-formes mobiles, de sorte que les fonctionnalités d'accessibilité pour Windows diffèrent des fonctionnalités pour Android / Ios.