Placer des boutons de navigation dans la barre d'outils est-il une bonne pratique du point de vue de l'accessibilité?
J'ai conçu une application mobile iPhone et maintenant je dois effectuer un examen d'accessibilité. L'exigence était de suivre les directives de l'interface utilisateur iOS8 et de donner l'impression que c'était une application native.
Pour la première fois, j'ai utilisé la fonction VoiceOver pour le tester et ce que j'ai remarqué, c'est que lorsque vous avez des boutons de navigation tels que "Annuler" et "Terminé" placés dans la barre d'outils en haut, ils lisent d'abord avant tout le contenu. De cette façon, l'utilisateur doit remonter jusqu'au sommet après la lecture, ou dans ce cas, remplir le formulaire, pour pouvoir terminer ou passer à l'étape suivante.
De nombreuses interfaces utilisateur mobiles utilisent de nos jours un schéma similaire pour placer les boutons sur le dessus au lieu de les placer logiquement après les formulaires. Quels sont les avantages/inconvénients de ce point de vue de la personne aveugle qui utilise VoiceOver?
Un autre commentaire: les utilisateurs atteints de déficiences motrices auront du mal à toucher de petites cibles dans votre application.
Il a été démontré que si vous placez des boutons à côté de la zone du cadre (bordure), leur accès est plus facile.
Essayez également de proposer une alternative au pincement (comme les boutons de zoom avant et arrière), car c'est la chose la plus difficile à faire pour quelqu'un qui manque de dextérité des mains.
Pour résumer, quelques conseils de conception pour l'accessibilité de l'écran tactile
- Rendre chaque cible (entrées, boutons) accessible. [1,3]
- Placer les éléments clés à côté des zones du cadre [2]
- Évitez les pincements ou autorisez des alternatives [2,5]
- Prévoyez suffisamment de temps pour remplir les formulaires, lire ou appuyer sur les boutons
- Essayez de ne pas remplir l'écran avec des choses exploitables pour réduire les erreurs (c'est une règle générale qui fonctionne pour tout le monde ..)
Références :
Si vous souhaitez en savoir plus, voici quelques articles que j'aime sur l'écran tactile a11y pour les utilisations avec facultés affaiblies par le moteur
- Accessibilité physique des smartphones à écran tactile. Trewin S, Swart C, Pettick D. http://dl.acm.org/citation.cfm?doid=2513383.2513446
- Pointage de la barrière: utilisation des arêtes physiques pour faciliter l'acquisition de cibles sur les écrans tactiles des appareils mobiles, Froehlich J Wobbrock J Kane S. http://dl.acm.org/citation.cfm?id=1296843.1296849
- Analyser les vidéos YouTube générées par les utilisateurs pour comprendre l'utilisation de l'écran tactile par les personnes ayant une déficience motrice. Anthony L Kim Y Findlater L. http://dl.acm.org/citation.cfm?id=2466158
- Développement d'un modèle d'interaction accessible pour les appareils mobiles à écran tactile: résultats préliminaires. Piccolo L De Menezes E De Campos Buccolo B. http://dl.acm.org/citation.cfm?id=2254436.2254474
- Stratégies d'assistance pour les personnes ayant une déficience motrice fine basées sur une analyse des sous-mouvements. Hourcade JO Guardionex. http://dl.acm.org/citation.cfm?id=2520961
Mes 2 cents!
Votre question est très difficile. Comme vous l'avez dit, il n'est pas logique de lire les boutons d'action finale avant les champs. J'avais un tel formulaire sur PC et c'était une mauvaise chose d'avoir à faire défiler tout le temps pour valider ou annuler le formulaire. Dans votre cas, si vous avez beaucoup d'utilisateurs aveugles, vous devez les aider, pourquoi ne pas avoir une option au début du processus pour permettre aux utilisateurs de spécifier leur handicap et dans ce cas, avoir des boutons sur le dessus et dans d'autres cas les laisser à leur place naturelle?
il me semble que ni les voyants ni les aveugles ne bénéficieraient de ce schéma. Même si cette section est désactivable, l'utilisateur doit savoir ce que la page propose avant de continuer. Si cela nécessite une entrée, vous configurez l'utilisateur pour la frustration (messages d'erreur) si vous donnez le choix de continuer avant que les données ne soient entrées. Ne suivez donc pas ce modèle si cela vous semble logique. il en va de même pour le bouton d'annulation. Faites-leur savoir ce qu'ils abandonnent.
- En outre, l'appel à l'action doit être clair sur ce que l'utilisateur fera ou trouvera ensuite au lieu de simplement avancer aveuglément. Quelle est la prochaine étape dans votre flux?