👐🏽 👗 🚙 Comment nous avons effectué les tests d'accessibilité dans Alfa Digital 💪🏽 ⌚️ 🍰

Les produits numériques doivent être non seulement beaux, pratiques et rentables, mais également accessibles aux personnes handicapées. C'est plus important qu'il n'y paraît à première vue. Parfois, cela doit être communiqué à l'entreprise, aux propriétaires de produits et aux collègues directs. Mais il s'avère que cela porte votre produit à un nouveau niveau. Nous sommes avec un développeur iOS seniorfamilkoraconter notre expérience.

Alfa-Bank fait partie d'un groupe de travail spécial créé par la Banque centrale dans le but d'améliorer la qualité des produits financiers pour les groupes malvoyants. Une méthodologie spéciale de travail et d'évaluation a déjà été développée, à laquelle toutes les banques adhèrent.

Et c'est ainsi que nous avons testé.

Utilisateurs et scénarios

Tout d'abord, nous avons invité des personnes ayant une déficience visuelle (de différents groupes) à tester.

Le premier groupe de déficiences visuelles est constitué par les personnes complètement aveugles qui sont obligées d'utiliser des appareils et des logiciels spéciaux (lecteurs d'écran, VoiceOver).

Les deuxième et troisième groupes sont malvoyants, qui, selon la maladie, utilisent de tels dispositifs ou réussissent à s'en passer.

Oui, il est important de noter que lorsque vous effectuez des tests, dont le résultat sera l'achèvement ou même le traitement de l'ensemble de l'application ou de ses fonctions individuelles, cela ne fera pas de mal de transmettre son besoin à l'entreprise. Parce que cela coûte aussi du temps, des efforts. Ici, il s'avère une telle histoire que, d'une part, de telles actions pour les personnes ayant une déficience visuelle sont de la responsabilité sociale de l'entreprise, d'autre part, comme le montrent les statistiques, jusqu'à 30% de la population du pays peut rencontrer des difficultés temporaires de vision dans différentes situations, et cela déjà chiffre impressionnant.

Par conséquent, nous nous sommes réunis et nous sommes assis pour tester avec eux les quatre scénarios les plus populaires d'utilisation d'Alpha Mobile. Les voici:

autorisation de demande
vérification de l'équilibre
afficher vos comptes (historique, statut)
recharge de compte mobile

Bien sûr, selon une personne en particulier, les scénarios peuvent être différents - quelqu'un paie souvent le logement et les services communaux à l'aide d'un code QR, quelqu'un transfère de l'argent à des proches, mais les quatre plus courants sont les quatre suivants.

Méthodes et outils de test

Il existe un GOST R 52872-2012 spécial , "Exigences d'accessibilité pour les malvoyants", qui décrit toutes les normes de manière suffisamment détaillée. C'est ce que nous utilisons, en attribuant à chaque erreur trouvée une étiquette correspondante. Au total, tous les problèmes trouvés ont été divisés en trois catégories.

Problème de conception. Par exemple, à l'entrée de la banque mobile, c'est la fenêtre habituelle pour que tout le monde entre le code PIN, vous ne vous concentrez pas sur le champ de saisie et la personne ne dit pas à haute voix combien de tentatives elle a pour entrer dans le code PIN.

Il en était ainsi avec nous. Cela ressemble à un problème moyen, mais c'est une chose critique. Si une personne ne peut pas entendre si elle a correctement saisi ou non le code PIN, combien de tentatives il lui reste, alors elle pourrait bien dépasser ce nombre de tentatives. Cela signifie que l'entrée d'Alfa Mobile sera temporairement bloquée avec tous les inconvénients qui en résulteront.

Problème de qualité du code. C'est quand tous les éléments ne se prononcent pas correctement. Par exemple, à certains endroits, les flèches de navigation peuvent être exprimées comme «Fin de table» et éléments système similaires.

Le problème du contraste. Par exemple, ici, même avec une vision normale, il est difficile de lire le texte. Vous devez vous en débarrasser et en tenir compte immédiatement.

"
Notre travail a comporté quatre étapes principales:

Rassemblé un groupe de testeurs (7 personnes) et régressé l'application
Séparé des branches de développement, analysé les problèmes et les éléments
Ils les ont écrits sur une plaque, priorisés
Critical a commencé à éditer

Les tests aident vraiment l'approche d'Apple pour créer des produits. Premièrement, il est vraiment pratique de tout tester directement sur l'appareil, les Cupertiniens ont tout adapté cool.

Deuxièmement, il y a Xcode avec son inspecteur d'accessibilité, cet utilitaire affiche une vue spécifique des boutons et des éléments lorsque vous survolez l'écran, vous pouvez rapidement tout lire et comprendre s'il sera correctement exprimé. En fait, dans notre cas, c'était le principal problème - les boutons de signature pour VoiceOver.

Nous avons trouvé des défauts en évaluant la fonctionnalité et la commodité d'une application mobile utilisée par les personnes ayant des problèmes de vision. L'évaluation est effectuée en testant le passage de tous les scénarios utilisateur de base.

Plus les scénarios utilisateur de base disponibles pour le client et moins d'obstacles et de difficultés identifiés lors du passage du script, plus la note est élevée.

Le niveau de disponibilité des scripts est déterminé par le problème le plus critique.

critique reçoit un scénario dans lequel un problème de disponibilité critique est détecté qui ne permet pas du tout de terminer la tâche.
minor reçoit un scénario dans lequel des problèmes d'accessibilité de criticité moyenne sont détectés lorsque les utilisateurs rencontrent des difficultés importantes pour terminer la tâche.
low reçoit un scénario dans lequel des problèmes de disponibilité à faible criticité sont détectés lorsque les utilisateurs éprouvent des difficultés à terminer une tâche.

Comment éviter les défauts d'accessibilité?

Tout d'abord, utilisez le protocole UI Accessibility Element.

Ensuite, vous devez améliorer Voice Over (une fonction spéciale Makoshi qui aide un utilisateur malvoyant à travailler avec des commandes vocales et un clavier):

Boutons de signe.
Ajoutez des valeurs.
Laissez un indice.
Contrôles de groupe.
Corrigez les mauvaises inscriptions.
Indiquez le type de contrôle: bouton, inscription, lien, etc.
Prolongez les boutons ou les éléments s'ils sont trop étroits (minimum 44:44)

Voici ce que nous recommandons d'autre:

1. Boutons - .accessibilityLabel

Chaque bouton doit avoir un nom court et résonnant. VoiceOver se couvrira, si vous oubliez, il essaiera de lire le texte ou le nom de l'icône sur le bouton.

Ce que vous devez signer:

Boutons avec une icône, mais sans texte;
Images. Si possible, il est préférable de signer ce qui est montré sur l'image.
Un bouton et une image sans étiquette expriment le nom de l'icône, comme dans Actifs

2. Valeurs - .accessibilityValue En

plus du nom, vous pouvez écrire une valeur. Par exemple, lorsque vous entrez le montant d'argent avec textField, vous devez signer le nom du compte ou la fin numérique, et également indiquer le nombre de roubles.

3. Conseils - .accessibilityHint

Si nous voulons clarifier davantage l'action, nous pouvons écrire un indice dans .accessibilityHint. Mais vous ne devriez pas trop vous fier aux invites: des explications constantes vous dérangent, donc certains utilisateurs les désactivent via les paramètres du téléphone.

Le bouton est exprimé comme «Vers une autre banque», pour explication, vous pouvez laisser un indice, quel type de transfert, à quelle vitesse et ainsi de suite.

4. Contrôles de groupe -. Accessibilité

Par défaut, chaque élément est prononcé séparément. Cela n'est pas pratique: les zones de pression sont réduites, vous ne remarquerez peut-être pas quelque chose, vous devez donc généraliser.

Maintenant, la cellule a plusieurs champs: carte, argent et nom, 3 contrôles par cellule. Il faut généraliser qu'il y avait 1 cellule et un nom, donc ça se rapproche du sens.

Comment le réparer?

Rendre la commande accessible à toute la cellule. Par défaut, toutes les vues ne sont que des conteneurs pour d'autres éléments; VoiceOver les ignore. Pour marquer la vue comme élément final, vous devez définir la cellule isAccessibilityElement = true.
Donnez un nom à la cellule. Vous ne pouvez plus vous concentrer sur l'étiquette, vous devez donc spécifier manuellement le texte. accessibilityLabel = specialOffer.title

Vous pouvez simplifier:

Rendre la commande accessible à toute la cellule. Définissez la cellule isAccessibilityElement = true
Dans accessibilityLabel, écrivez la chose la plus importante: le nom de la carte et du compte. Séparé par une virgule, VoiceOver prend en compte la ponctuation.
Dans AccessibilityValue, spécifiez des informations supplémentaires, dans notre cas, c'est quel compte, combien d'argent.
Indiquez que la cellule peut être pressée, c'est-à-dire c'est essentiellement un bouton. accessibilityTraits = .button

Total

Les classeurs USABILITYLAB nous ont donné la première place en termes de disponibilité des applications. Cela ne signifie pas que nous sommes si cool et que nous avons résolu tous les problèmes en général, devenant une application idéale, non. Mais nous y travaillons en tenant compte de toutes les subtilités et caractéristiques de travailler avec des personnes ayant des problèmes de vision.

C'est également très cool que cette histoire nous ait aidés à attirer de telles personnes - elles nous envoient souvent des commentaires, et un certain nombre de répondants aident désormais à tester Alfa Mobile de manière continue.

Nous travaillons plus loin.

Comment nous avons effectué les tests d'accessibilité dans Alfa Digital

Utilisateurs et scénarios

Méthodes et outils de test

Comment éviter les défauts d'accessibilité?

Total

More articles: