18f.gsa.gov: Plusieurs problèmes d'accessibilité avec le menu mobile

Créé le 24 juin 2020  ·  6Commentaires  ·  Source: 18F/18f.gsa.gov

Comportement prévisible

Les personnes utilisant des lecteurs d'écran sur des appareils mobiles, des claviers avec des appareils mobiles ou des claviers et un zoom de navigateur avec la vue mobile activée devraient pouvoir ouvrir, accéder et fermer le menu mobile avec la même facilité relative que toute autre personne utilisant le site.

Comportement réel

  1. Le bouton de menu n'a pas d'état descriptif (par exemple aria-expanded="false" ), donc un utilisateur aveugle ou malvoyant ne sait pas que le bouton de menu est fermé et peut ouvrir le menu de navigation.
  2. Lorsque le bouton de menu est enfoncé/activé, le focus n'est pas déplacé vers le menu de type modal, donc il n'y a aucune indication que quelque chose s'est produit. De plus, les éléments de navigation sont dans un div près du bas/de la fin de la source de la page, donc un utilisateur doit naviguer vers le bas de la page pour accéder au menu.
  3. Le modal du menu a un bouton de fermeture, mais il n'est pas étiqueté. Le svg besoin d'un aria-label ou il devrait y avoir du texte visuellement caché dans le button pour fournir aux utilisateurs de technologies d'assistance un nom accessible. Actuellement, VoiceOver sur iOS avec Safari suppose qu'il s'agit d'un bouton de fermeture, mais d'autres combinaisons de technologie d'assistance/OS/navigateur peuvent ne pas offrir cette fonctionnalité.

Étapes pour reproduire le comportement

  • [ ] Ouvrez le site 18F à l'aide d'un appareil mobile et à l'aide d'un lecteur d'écran/d'une technologie d'assistance, suivez les étapes suivantes
  • [ ] Naviguez jusqu'au bouton du menu principal et activez-le
  • [ ] Naviguez jusqu'aux éléments du menu de navigation
  • [ ] Accédez au bouton de fermeture

Ce problème est résolu lorsque :

  • [ ] Le bouton Menu annonce avec précision son état (réduit/développé)
  • [ ] La mise au point est définie par programme (via JS) sur le menu lorsqu'il est ouvert
  • [ ] Le bouton Fermer a un nom accessible et est annoncé par les technologies d'assistance
  • [ ] Piège le focus dans le tiroir de navigation lorsqu'il est ouvert
  • [ ] La mise au point revient au bouton de menu lorsque le menu mobile est fermé
  • [ ] BONUS : le menu est fermé et le focus revient au bouton lorsque l'utilisateur appuie sur le bouton esc de son clavier.

Veuillez décompresser et regarder ceci
enregistrement d'écran de l'iPhone à l'aide de Safari et VoiceOver pour démontrer le problème .

Ressources supplémentaires pouvant être utiles :

front-end accessibility bug

Commentaire le plus utile

@iamjolly et @aduth êtes-vous disponible pour nous rejoindre lors de notre session de co-working la semaine prochaine ? Nous pouvons discuter de ces options. Je t'ajoute à l'invitation.

Tous les 6 commentaires

Merci Robert ! Nous allons ajouter à notre travail d'accessibilité actuel

Merci @Dahianna - À moins que vous ne pensiez tous fermement que nous devrions attendre, je peux travailler avec @aduth sur un PR pour résoudre ce problème rapidement car il s'agit d'un obstacle important pour les gens.

Pas du tout. N'hésitez pas à travailler avec Abdul pour le réparer

@iamjolly et moi avions passé une partie de la matinée à examiner la meilleure façon d'aborder ce problème. C'est particulièrement pertinent à l'esprit des travaux en cours à #3097 pour mettre à niveau vers USWDS v2, car une partie du problème ici est que le site Web 18F actuel ne tire pas parti de l'accessibilité intégrée des composants de navigation USWDS et implémente à la place son propre comportements de menu mobile.

Ainsi, nous avons envisagé plusieurs façons d'aborder cela :

  1. S'appuyer sur la mise en œuvre actuelle comme solution plus immédiate pour résoudre les problèmes

    • Succursale : 3188-a11y-mobile-nav

    • Aperçu en direct

    • Avantages:



      • Il n'y a que quelques changements nécessaires


      • Cohérence de la conception avec le site Web actuel



    • Les inconvénients:



      • Il s'agit essentiellement d'une réimplémentation de ce qui est déjà fourni via USWDS. Certaines sont plus difficiles à mettre en œuvre que d'autres (focus trap, par exemple).


      • En tant que réimplémentation, il n'y a aucune garantie que le comportement reste synchronisé avec USWDS. Par exemple, la branche actuelle définira le focus sur le _container_ du tiroir de menu mobile, plutôt que sur le premier élément focalisé. En revanche, si cette approche est idéale, elle pourrait être intéressante à considérer comme une proposition d'amélioration en amont de l'USWDS.



  2. Convertir la navigation actuelle pour utiliser USWDS v1 déjà disponible aujourd'hui sur le site

    • Branche : update/nav-uswds

    • Aperçu en direct

    • Avantages:



      • Réutilise les comportements déjà disponibles via USWDS


      • Comportement et apparence cohérents avec USWDS


      • Il pourrait bénéficier au #3097 en se rapprochant des conventions USWDS



    • Les inconvénients:



      • Conflits avec le style d'en-tête personnalisé 18F. Cela pourrait être considéré comme une "bonne chose" dans la façon dont il embrasse les conventions de l'USWDS, mais cela s'écarte légèrement de la conception actuelle du site.


      • Cela pourrait rendre le travail dans #3097 plus difficile, car les modifications sont probablement conflictuelles et nécessiteront des mises à jour des noms de classe mis à jour de USWDS v2



  3. Attendez la fin de la mise à niveau USWDS v2 dans #3097

    • Avantages:



      • Déjà nécessaire et en cours


      • Tire parti des comportements d'accessibilité les plus récents et cohérents des composants de navigation USWDS



    • Les inconvénients:



      • Ce problème continuera d'affecter les gens jusqu'à ce que les changements de # 3097 soient appliqués, et il n'est pas clair s'il devrait être terminé dans un proche avenir



Je serais curieux de savoir si vous avez des idées à ce sujet. Je vois qu'il y a eu pas mal de mises à jour récentes de #3097, ce qui pourrait avoir un impact sur laquelle de ces options pourrait être la meilleure à considérer.

@iamjolly et @aduth êtes-vous disponible pour nous rejoindre lors de notre session de co-working la semaine prochaine ? Nous pouvons discuter de ces options. Je t'ajoute à l'invitation.

Ça sonne bien @Dahianna . Parlez-vous alors!

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

gboone picture gboone  ·  3Commentaires

gboone picture gboone  ·  4Commentaires

elainekamlley picture elainekamlley  ·  16Commentaires

gboone picture gboone  ·  16Commentaires

konklone picture konklone  ·  4Commentaires