J'utilise React Modal dans mon application et lorsqu'elle est ouverte, exécutez le ax donne l'erreur suivante:
les éléments aria-hidden ne contiennent pas d'éléments focalisables
C'est parce que le modal React ajoute un aria-hidden = "true" à l'élément racine de l'application (le div sous lequel tous les composants de mes applications sont rendus, mais pas le modal), mais il ne met pas à jour l'index des onglets ou ne désactive pas chaque élément focalisable .
Cependant, le modal React intercepte le focus du clavier, donc l'utilisateur ne peut pas sortir du modal et cliquer sur l'arrière-plan ferme le modal.
Ma question est donc: p>
Est-ce vraiment un problème que je dois résoudre? Ou est-ce un faux positif car l'outil n'a pas connaissance du focus de piégeage modal?
Si cela doit être corrigé, ma seule option est-elle de mettre à jour manuellement l'index des onglets ou de désactiver chaque élément focalisable ?
Merci!
Le code HTML lorsque le modal est ouvert ressemble un peu à ceci:
<div data-react-modal-body-trap="" tabindex="0" style="position: absolute; opacity: 0;"></div>
<div id="root" aria-hidden="true">application content</div>
<div class="ReactModalPortal">
<div class="ReactModal__Overlay ReactModal__Overlay--after-open modal-overlay-6fODnA">
<div tabindex="-1" role="dialog">modal content</div>
</div>
</div>
3 Réponses :
vous obtenez l'avertissement, car lorsque aria-hidden = "true" est défini sur l'élément racine, votre page peut avoir des éléments focalisables, ce qui va à l'encontre de cette règle.
donc pour éviter cela, vous pouvez toujours définir ariaHideApp = {false} dans votre Modal qui ne définira pas le aria-hidden = "true" et vous aurez toujours votre concentration piégée dans le Modal ouvert.
De la même page "Il est important pour les utilisateurs de lecteurs d'écran que les autres contenus de page soient masqués (via l'attribut aria-hidden) pendant que le modal est ouvert." et "Si vous appliquez déjà l'attribut aria-hidden au contenu de votre application par d'autres moyens, vous pouvez transmettre ariaHideApp = {false}". Il semble donc que votre suggestion supprimerait l'avertissement et le remplacerait par un véritable problème d'accessibilité ...
Est-ce vraiment un problème que je dois résoudre? Ou est-ce un faux positif car l'outil ne connaît pas le focus de piégeage modal?
Un plugin listant tous les liens de la page listera toujours les liens s'ils ne sont pas désactivés (en supprimant le tabindex par exemple).
En ce qui concerne l'accessibilité, vous devez toujours considérer que les plugins personnalisés ne reposant pas sur ARIA peuvent exister ou existeront.
ARIA est principalement utilisé par les lecteurs d'écran: ce n'est pas une condition requise pour les technologies d'assistance mais une superposition pour améliorer l'accessibilité.
Par exemple, un dispositif de suivi oculaire peut également déclencher le premier élément cliquable à une position donnée, et comme la superposition de votre plugin n'est pas dans l'ordre de tabulation, il peut activer un élément derrière.
L'ajout de aria-modal à votre modal supprimera cet avertissement.
Il m'a fallu un certain temps pour comprendre pourquoi nos modaux n'ont pas cet avertissement, mais le vôtre, car nous utilisons un balisage similaire. Nous utilisons la propriété aria-modal sur nos modaux.
Ax a été mis à jour pour attendre la propriété aria-modal sur un modal. aria-modal a un support moyen pour le moment, mais il est une bonne pratique car elle évite les erreurs des développeurs (car les combinaisons lecteur d'écran / navigateur qui le respectent vont automatiquement piéger le focus pour vous!).
Le seul La façon de vraiment tout cacher est d'ajouter tabindex = "- 1" à chaque élément interactif.
Cependant, en réalité, cela est beaucoup plus susceptible de causer un problème d'accessibilité catastrophique si votre La fonction JS que vous utilisez pour ajouter tabindex = "- 1" à chaque élément interactif rencontre un problème et ne parvient pas à rétablir le tabindex ou à le supprimer. Cela signifierait que vous laisseriez des parties de la page complètement inaccessibles!
Évidemment, vous échoueriez alors WCAG sur la partie "Robuste" de POUR. Merci de ne pas faire cela.
Le meilleur compromis est d'utiliser aria-hidden sur
Enfin, vous devez gérer le focus pour les personnes en utilisant la touche tab . Ceci est notre sauvegarde en cas d'échec des méthodes ci-dessus et pour les personnes n'utilisant pas de lecteur d'écran (c'est-à-dire les personnes ayant des problèmes de dextérité ou de précision qui ne peuvent pas utiliser de souris.)
Si vous avez besoin d'informations sur la façon de piéger le focus de l'onglet dans un modal Je vais fournir un exemple de code mais c'est assez simple.
La gestion du focus de la touche de tabulation n'empêchera pas les utilisateurs de lecteurs d'écran ou les plugins qui se comportent mal de sortir de votre modal ( si le d'autres méthodes échouent ) mais croyez-moi, s'ils ont un problème avec votre site après avoir implémenté ce qui précède, ils auront de plus gros problèmes sur d'autres sites.
Enfin, comme autre sauvegarde, nous ajoutons inerte aux éléments en dehors de notre modal. Le support n'est pas génial , mais chaque petit geste est utile!
Vous peut le polyfill si vous le souhaitez, mais je ne pense pas qu'il soit encore sorti du brouillon de spécification, nous l'utilisons donc tel quel.
Il est purement là comme un autre ajout et (espérons-le) à La pérennité de nos applications héritées en tant que inertes est un attribut indispensable et facile à comprendre. Il bloque l'accès des lecteurs d'écran aux éléments sans changer la conception visuelle (essentiellement aria-hidden mais en tant qu'attribut standard, avec l'avantage de supprimer efficacement tous les enfants de l'arborescence d'accessibilité.)
Essayez de supprimer aria-modal = "true" de l'exemple suivant et exécutez Axe, l'avertissement sera renvoyé.
<main aria-hidden="true" inert><a href="https://google.com">test</a></main>
<div class="modal" aria-hidden="false" aria-modal="true">
<label for="iTest">input test</label>
<input id="iTest"/>
</div>
Merci pour cette réponse géniale et détaillée, malheureusement, j'obtiens toujours la même erreur sur mon application et votre exemple: -S J'utilise le plugin Chrome ax v4.5.3 (ax-core 3.5.5)
J'utilise le même? J'ai également parcouru la page via l'interface de ligne de commande Axe et je n'ai eu aucune erreur? Ce qui précède est à 100% la bonne façon de le faire, donc je pense que c'est peut-être un bogue (peut-être que vous avez quelque chose de configuré différemment, mais je ne peux pas penser à quoi!) Désolé, je suis à court d'idées pour se débarrasser de l'erreur, mais faites-le comme ci-dessus et vous serez en or! Vérifiez simplement que vous n'avez pas accidentellement exécuté le plugin sur la mauvaise page (je sais, mais facile à faire) car ce qui précède fonctionne sur la même configuration!
pour plus de clarté (car il peut s'agir d'une faute de frappe "modèle" au lieu de "modal") le modal est rendu séparément et en dehors de tout le reste de la page, et tout le reste est dans
aria-hidden = "true" conteneur lorsque le modal est ouvert, le conteneur lui-même n'a pas detabindex?opps, c'était en effet une faute de frappe. J'ai mis à jour la question pour être plus claire, espérons-le
c'est la bonne façon de le faire, mais nous ajoutons normalement
tabindex = "- 1"au conteneur principal (id = "root") lorsque nous le faisons. Essayez d'ajouter cela manuellement et exécutez Axe alors, j'imagine que le problème disparaîtra. Si cela fonctionne, j'ajouterai une réponseLa définition de
tabindex = "- 1"sur l'élémentrootn'a fait aucune différence, l'avertissement est toujours généré.Je pense que c'est un bogue alors, mais nous n'avons pas ce problème à nos côtés (mais nos trucs sont tous personnalisés, pourraient être des centaines de choses qui réagissent, ce qui pourrait causer des problèmes). Je vais essayer de mettre en place un test et de le vérifier d'abord, mais en principe, vous faites les choses correctement, comme je l'ai dit plus tôt.