Comment créer des boîtes de dialogue d'alerte modales conformes aux normes WAI-ARIA : série sur l'accessibilité (A11y)

L'article suivant est le deuxième volet de la nouvelle série d'articles de blog de Paul Adam intitulée « Widgets WAI-ARIA, modèles de conception et prise en charge de l'accessibilité ». 

Dans le premier article de la série « A11y Support », nous avons abordé les panneaux d'onglets ARIA. Dans la continuité de cette série, nous allons créer un autre widget accessible, à savoir une boîte de dialogue de message détaillé avec l'attribut `role="alertdialog"`, puis tester quelles combinaisons de lecteurs d'écran et de navigateurs sont prises en charge.

Démonstration en direct

Boîte de dialogue d'alerte ou boîte de dialogue de message

Les instructions permettant de créer un widget accessible avec l'attribut `role="alertdialog"` sont disponibles dans le document « WAI-ARIA Authoring Practices 1.1 ». Ce document précise que les exemples incluent les invites de confirmation d'action, les messages d'avertissement ou l'aide en cas de saisie non valide dans un formulaire. La boîte de dialogue doit être modale. Le focus clavier est placé sur un élément de la boîte de dialogue en fonction de son contenu.

Pour plus d'informations, consultez la spécification ARIA 1.1 relative au rôle « alertdialog » ; notez qu'il existe des différences entre les recommandations de la spécification ARIA et celles des « ARIA Authoring Practices » concernant la manière de placer le focus sur la boîte de dialogue.

S'agit-il d'une boîte de dialogue « Message simple » ou « Message détaillé » ?

Une boîte de dialogue est considérée comme une boîte de dialogue de message détaillé lorsque :

• Si le texte comporte plus d'une phrase
• S'il contient des informations pour lesquelles la ponctuation est indispensable
• S'il contient des informations détaillées susceptibles d'être copiées, comme un numéro ou une adresse
• S'il comporte un élément interactif, tel qu'un lien.

Si la boîte de dialogue ne présente aucune de ces caractéristiques, il s'agit alors d'une simple boîte de dialogue de message.

Gestion de l'attention

Dans les boîtes de dialogue de message simples, le focus est placé sur le bouton de confirmation (par exemple, le bouton « OK »). Dans les boîtes de dialogue de message détaillées, le focus est placé sur l’élément contenant le message. Cela est conforme aux pratiques de rédaction WAI-ARIA, mais je ne suis pas certain d’approuver le fait de placer le focus sur le texte statique à l’intérieur de la boîte de dialogue – simplement parce qu’il me semble plus logique de placer le focus sur le premier élément pouvant recevoir le focus du clavier à l’intérieur de la boîte de dialogue. La démo en ligne présente une boîte de dialogue d’alerte conforme aux pratiques de rédaction ARIA (ainsi qu’une autre qui s’en écarte).

role="document" et tabindex="0" sur le message détaillé

In the alertdialog exact to ARIA Authoring Practices the pattern seems to be designed for NVDA because it says the detail message should be focusable and have a role=”document”. In the alertdialog that deviates from the ARIA Authoring Practices we’re setting focus to the first button inside the dialog. <button> elements can receive .focus() from JavaScript by default without needing a tabindex=0 like the static text.

Lorsque vous déplacez le focus du lecteur d'écran vers un conteneur dont le rôle est défini comme « dialog » ou « alertdialog », les valeurs textuelles du nom d'accessibilité (aria-label/aria-labelledby) et de la description (aria-describedby) seront lues à voix haute automatiquement, en plus du rôle « Dialog » ou « Alert Dialog ».

Comportement du mode « Formulaires » de NVDA et combinaison de touches « Insert + barre d'espace »

Dans un élément « role=“dialog” » ou « “alertdialog” » standard, NVDA passe en mode « Formulaires » lorsque le focus est transféré vers la boîte de dialogue. En mode « Formulaires », les utilisateurs de NVDA ne peuvent naviguer dans la boîte de dialogue qu’à l’aide de la touche Tab. Ils ne peuvent pas utiliser les touches fléchées haut/bas pour parcourir la boîte de dialogue en navigation linéaire.

Pour quitter le mode « formulaires », les utilisateurs de NVDA peuvent appuyer sur les touches Insert + barre d'espace, puis passer en mode « navigation », où ils peuvent utiliser les touches fléchées et les touches de navigation rapide pour parcourir la boîte de dialogue, plutôt que de se limiter à la touche Tab.

La plupart des spécialistes de l’accessibilité sont déconcertés par ce comportement et se demandent si les utilisateurs de lecteurs d’écran comprennent comment lire cette boîte de dialogue, ou si le code de celle-ci est défectueux, car il ne fonctionne pas correctement avec NVDA. Ce problème est similaire à ceux liés à l’utilisation de l’attribut « role="application" ». Les problèmes liés au mode « Forms » et au mode « Browse » n’affectent pas les autres lecteurs d’écran tels que VoiceOver et TalkBack. J'ai entendu dire que JAWS n'était pas affecté par le problème lié au mode « Formulaires » avec « role="alertdialog" », contrairement à NVDA.

Non-respect des pratiques de rédaction WAI-ARIA en plaçant le focus sur le premier bouton

Ma préférence – et ce qui semble fonctionner bien mieux avec VoiceOver – est de placer le focus sur le premier élément pouvant logiquement recevoir le focus à l’intérieur de la boîte de dialogue ; le rôle de la boîte de dialogue ainsi que son nom et sa description accessibles seront alors lus automatiquement. On pourrait s’attendre à ce que les utilisateurs de NVDA entendent lorsqu’ils entrent dans un conteneur de boîte de dialogue, puis passent manuellement en mode « Parcourir » à l’aide des touches Insert + barre d’espace pour lire l’intégralité du texte de la boîte de dialogue s’ils ont manqué une partie du contenu lors de leur entrée dans celle-ci. NVDA fonctionne toujours très bien lorsqu’on place le focus sur le bouton à l’intérieur de la boîte de dialogue. En effet, tout le contenu de la boîte de dialogue est toujours lu à voix haute automatiquement par NVDA en fonction des attributs « rôle » et « nom/description accessible ».

Si vous utilisez la structure recommandée pour les boîtes de dialogue d'alerte dans les « WAI-ARIA Authoring Practices », vous constaterez que VoiceOver ne fonctionne pas du tout correctement. En fait, cela semble même bien pire.

Sortie VoiceOver : « Attention ! Adresse postale incorrecte ! 3 éléments. Boîte de dialogue d'alerte »

Mais si vous placez le curseur sur un bouton à l'intérieur de la boîte de dialogue, VoiceOver prononcera correctement le nom et la description accessibles de la boîte de dialogue.

Sortie VoiceOver : « Attention ! Adresse incohérente ! 4 éléments. Boîte de dialogue d'alerte. Bouton « Oui, le format est correct ». L'adresse que vous avez saisie ne correspond pas aux données du code postal. Le format est-il correct : 12345 Main St. Blvd. ?»

Il est parfois judicieux de s'écarter des règles des pratiques de rédaction ARIA.

La spécification ARIA 1.1 relative à la boîte de dialogue d'alerte (rôle) stipule en effet : « Lorsque la boîte de dialogue d'alerte s'affiche, les auteurs doivent placer le focus sur un élément actif au sein de cette boîte de dialogue, tel qu'un champ de saisie de formulaire ou un bouton OK. » Cela semble contredire les recommandations des pratiques de rédaction ARIA ou, du moins, la spécification ARIA ne fait pas la distinction entre une boîte de dialogue de message simple et une boîte de dialogue de message détaillé.

Le « modal » dans les boîtes de dialogue modales

Le mode « modal » signifie que l'utilisateur ne peut interagir avec aucun contenu situé en dehors de la boîte de dialogue. Ainsi, les interactions via le clavier, la souris et le lecteur d'écran DOIVENT être confinées à l'intérieur de la boîte de dialogue. Une façon de confiner le focus à l'intérieur d'une boîte de dialogue consiste à désactiver la possibilité de sélectionner le contenu principal désactivé situé sous la boîte de dialogue.

Une fois que l'utilisateur a ouvert la boîte de dialogue, nous utilisons JavaScript (jQuery) pour modifier les attributs et les valeurs des éléments HTML, puis nous construisons la boîte de dialogue de manière dynamique après avoir masqué l'ensemble du contenu principal et des conteneurs de navigation.

Vous masquez du contenu aux lecteurs d'écran à l'aide de l'attribut `aria-hidden="true"`, mais cela ne supprime pas la possibilité d'y accéder au clavier ; vous devez donc également définir `tabindex="-1"` sur les liens et l'attribut `disabled` sur les boutons. Sinon, l'utilisateur d'un lecteur d'écran pourrait toujours accéder à ces éléments de contrôle du contenu principal à l'aide de la touche Tab. Cela signifie que l'utilisateur n'entendra aucune information d'accessibilité lue à voix haute en raison de l'attribut `aria-hidden="true"`.

Code jQuery pour masquer le contenu principal

$('main, [role=navigation]').attr('aria-hidden','true');
$('body').attr('style','background-color:gray;');
$('a').attr('tabindex','-1');
$('a').attr('style', 'cursor:default;');
$('button').attr('disabled', 'true');

Rôles, états et propriétés WAI-ARIA

Le conteneur principal de la boîte de dialogue doit avoir la valeur de l’attribut `role="alertdialog"` définie afin d’indiquer à l’utilisateur d’un lecteur d’écran le type de widget et les interactions au clavier. La démo « Exact to ARIA Authoring Practices » respecte l’exigence selon laquelle les zones de message doivent avoir `role="document"` et `tabindex="0"`, mais l’autre démo ne suit pas cette recommandation. Le conteneur `role="alertdialog"` doit également doit disposer d’un nom accessible, soit via l’attribut `aria-labelledby` faisant référence au titre de la boîte de dialogue, soit via un attribut `aria-label` s’il n’y a pas de titre visible. Généralement, le titre de la boîte de dialogue est une balise H1, mais la spécification ne fournit aucune recommandation concernant les en-têtes. Le conteneur de la boîte de dialogue doit également disposer d’une description accessible via l’attribut `aria-describedby`, faisant référence à l’élément de message ayant le rôle « document », ou simplement au conteneur de texte du message si le rôle « document » n’est pas utilisé. Vous ne souhaiterez probablement pas définir de description pour la boîte de dialogue si son contenu est très long ou s’il contient des informations complexes, telles que des formulaires ou des tableaux de données.

Code HTML/ARIA pour une boîte de dialogue d'alerte conforme aux bonnes pratiques de rédaction ARIA

<div role="alertdialog" aria-labelledby="alertHeading" aria-describedby="alertText">
<h1 id="alertHeading">Warning! Street Address Mismatch!</h1>
<div id="alertText" tabindex="0" role="document">
<p>The street address you entered does not match the Postal Code Data.</p>
<p>Is this the correct format: 12345 Main St. Blvd.?</p>
</div>
<button id="yes">Yes, Format Is Correct</button><button>No, Edit Street Address</button>
</div>

Code HTML/ARIA pour une boîte de dialogue d'alerte qui s'écarte des bonnes pratiques de rédaction ARIA

<div role="alertdialog" aria-labelledby="alertHeading" aria-describedby="alertText">
<h1 id="alertHeading">Warning! Street Address Mismatch!</h1>
<div id="alertText">
<p>The street address you entered does not match the Postal Code Data.</p>
<p>Is this the correct format: 12345 Main St. Blvd.?</p>
</div>
<button id="yes">Yes, Format Is Correct</button><button>No, Edit Street Address</button>
</div>

Démonstration en direct

Résultats des tests de compatibilité avec les lecteurs d'écran

Problèmes sur mobile avec les boîtes de dialogue d'alerte conformes aux pratiques de rédaction ARIA

Sous iOS, le focus VoiceOver ne se place pas dans la boîte de dialogue de message détaillé lorsqu’il est activé via la méthode JavaScript .focus() sur un conteneur dont les attributs role="document" et tabindex="0" sont définis. Au lieu de cela, le focus VoiceOver reste sur le bouton déclencheur et il est impossible de passer d’un élément à l’autre en balayant l’écran ; il faut alors utiliser la fonction « Explorer au toucher » pour placer manuellement le focus dans la boîte de dialogue.

J'ai également remarqué ce même problème dans d'autres exemples de boîtes de dialogue accessibles en temps réel, où la méthode .focus() est appliquée à l'élément conteneur ayant le rôle « alertdialog » plutôt qu'à un contrôle pouvant recevoir le focus à l'intérieur de la boîte de dialogue. Sur iOS, le focus de VoiceOver ne se place pas dans le conteneur et il est impossible d'y accéder par glissement. La seule façon d'accéder à la boîte de dialogue est d'utiliser la fonction « Explorer au toucher ».

Sélection du texte du dialogue

VoiceOver/Safari sur iOS

Sortie VoiceOver : « Message d'avertissement : Attention ! Adresse postale incorrecte !, Oui, le format est correct, Non, Modifier l'adresse postale, L'adresse postale que vous avez saisie ne correspond pas aux données du code postal., Ce format est-il correct : 12345 Main St. Blvd. ? »

Android TalkBack/Chrome

Sortie de TalkBack sur Chrome : « Attention ! Adresse incohérente ! L'adresse que vous avez saisie ne correspond pas aux données du code postal. Le format est-il correct : 12345 Main St. Blvd. ?
Avertissement ! Adresse postale non conforme !
L'adresse que vous avez saisie ne correspond pas aux données du code postal.
Le format est-il correct : 12345 Main St. Blvd. ?
Oui, le format est correct
Non, modifier l’adresse
document »

Android TalkBack/Firefox

Sortie de TalkBack dans Firefox : « » (rien n'est lu à voix haute)

Sélection du bouton « Dialogue »

VoiceOver/Safari sur iOS

Sortie VoiceOver : « Oui, attention ! Adresse incohérente ! L'adresse que vous avez saisie ne correspond pas aux données du code postal. Est-ce le bon format : 12345 Main St. Blvd. ? Oui, le format est correct. Non, modifier l'adresse. »

Android TalkBack/Chrome

Sortie de TalkBack sur Chrome : « Attention ! Adresse incohérente ! L'adresse que vous avez saisie ne correspond pas aux données du code postal. Le format est-il correct : 12345 Main St. Blvd. ?
Avertissement ! Adresse postale non conforme !
L'adresse que vous avez saisie ne correspond pas aux données du code postal.
Le format est-il correct : 12345 Main St. Blvd. ?
Oui, le format est correct
Non, modifier l’adresse
Bouton « Oui, le format est correct »

Android TalkBack/Firefox

Message de TalkBack dans Firefox : « Oui, le format est correct. Avertissement ! Incohérence dans l'adresse ! L'adresse que vous avez saisie ne correspond pas aux données du code postal. Le format est-il correct : 12345 Main St. Blvd. ? »

Démonstration en direct

Conclusion

Le mode « Formulaires » de NVDA pour les rôles de boîte de dialogue et le comportement moins efficace de VoiceOver lorsqu’on suit à la lettre les pratiques de rédaction WAI-ARIA rendent la création d’un widget universellement accessible bien plus complexe qu’on pourrait le penser au premier abord. Je ne m’attendais pas à rédiger des articles de blog aussi longs sur chaque widget ARIA pris individuellement, mais dès lors qu’on entre dans les détails d’ARIA et de la prise en charge par les lecteurs d’écran, il n’est pas toujours possible de se contenter d’un article court.

Afin de rendre le prochain article de la série « ARIA Support » aussi simple que possible, nous allons aborder un rôle qui semble très basique, à savoir « role="button" », mais nous verrons qu’il s’avère toujours plus complexe qu’on ne le pense une fois que le comportement du clavier et les événements « keyCode » de JavaScript sont correctement programmés. Restez à l’écoute pour découvrir d’autres articles consacrés à l’accessibilité, portant sur la création de widgets accessibles, ainsi que d’autres tutoriels «Deque How To » proposant des astuces pratiques en matière d’accessibilité !

Paul J. Adam est évangéliste de l'accessibilité chezDeque Systems. Il se consacre principalement à l'accessibilité mobile et à l'accessibilité du Web moderne, et possède une expertise dans les domaines suivants : Web mobile, applications natives iOS et Android, applications hybrides, conception Web adaptative, HTML5, JavaScript, WAI-ARIA, WCAG 2.0 et techniques modernes de développement Web. Paul est développeur Apple certifié depuis 2011 et consacre son temps libre à la création d'applications iOS et à l'apprentissage du développement JavaScript moderne. Vous pouvez le contacter sur Twitter à l'adresse @pauljadam.