Nous sommes en train de mettre en œuvre (c'est-à-dire d'ajouter) le support WAI-ARIA au menu de navigation principal d'un portail Web. Le menu est celui montré ici:
Le menu est implémenté au moyen de <ul>
/<li>
/<a>
Arbre DOM, stylisé en CSS pour ressembler à des onglets horizontaux.
Quelle est la mise en œuvre recommandée de WAI-ARIA pour un tel widget?
Je vais poster une implémentation possible ici comme réponse, donc pour faire avancer les choses.
Ignorez les paragraphes restants si vous connaissez/ne vous souciez pas des menus de navigation CSS dans le contexte WAI-ARIA.
TA
Préambule (pour ainsi dire)
J'ai lu de nombreuses parties des spécifications WAI-ARIA les plus récentes de w3org pour une compréhension générale, la taxonomie, etc. Ensuite, j'ai lu plusieurs exemples d'implémentations de widget UI. Je n'ai trouvé aucun exemple spécifiquement ciblé dans un tel menu de navigation CSS. Les widgets les plus proches que j'ai toujours trouvés sont le menu, la barre de menu et le panneau de tabulation. Bien sûr, j'ai également regardé Free ARIA Community group (où cette question a été initialement publiée).
Je dirais que aucun de ces widgets correspondent exactement à un menu de navigation (CSS). Par exemple, TabPanel peut contrôler du contenu dans la page (-> aria-controls), peut-être aussi MenuBar; mais je ne suis pas du tout sûr qu'un menu de navigation contrôle le contenu de la page (il contrôle la page suivante à afficher). Sans aller plus loin, il existe également d'autres différences. Les références sont à la fin de l'article. Si quelqu'un a des exemples de menu de navigation meilleurs (ou plus adaptés), nous serions heureux de les connaître.
Références
Une mise en œuvre possible serait:
Structure HTML:
<div> <!-- Outer wrapper -->
<ul> <!-- Main navigation bar container -->
<li> <!-- First-level item without submenu -->
<a> <!-- Destination URL -->
</a>
</li>
<li> <!-- First-level item with submenu -->
<a> <!-- Destination URL -->
</a>
<ul> <!-- Second-level menu container -->
<li> <!-- Second-level item -->
<a>
</a> <!-- Destination URL -->
</li>
</ul>
</li>
</ul>
</div>
Rôles:
<div>
<ul>
<ul>
de deuxième niveau<li>
(ils ne sont pas nécessaires dans la structure de barre de menus accessible exposée)<a>
Propriétés:
<a>
ayant un sous-menu<a>
précédent" pour les conteneurs <ul>
de deuxième niveauÉtats:
<a>
de premier ou de deuxième niveau actuellement visité; aria-selected = "false" sur les autres éléments <a>
. C'est pour faire respecter le concept "sélectionné <==> page actuelle"<ul>
de deuxième niveau<ul>
de deuxième niveau<ul>
. Ceci est une alternative au travail avec tabindex<a>
actuellement visité; tabindex = -1 sur les autres éléments <a>
. C'est afin de se concentrer d'abord sur la page actuelle lors de la tabulation dans la barre de navigation. C'est une alternative au travail avec aria-activedescendantClavier:
Août/2014: menuesem Vs sélectionné par aria
En réponse au commentaire de @Joshua Muheim: maintenant je peux voir d'ici , ainsi que de sa référence , cet attribut aria-selected
N'est pas autorisé pour le rôle menuitem
.
Comme je l'ai lu dans cette récente SO réponse il y a des solutions étant donné l'état actuel des choses, et il y a aussi un nouvel attribut proposé.
En tant que FYI, vous pouvez obtenir un menu pour annoncer les informations "X de Y" en ajoutant des attributs aria-posinset et aria-setsize aux éléments avec role = menuitem. Cordialement, Bryan Garaventa
Échapper pour fermer est un moyen standard de revenir en arrière, c'est le comportement attendu de nombreux utilisateurs.
Les modèles de conception ARIA fournissent le comportement attendu de l'interface utilisateur pour une gamme de contrôles personnalisés http://www.w3.org/TR/wai-aria-practices/#aria_ex utilisation de esc La clé pour fermer et revenir à l'élément déclencheur à la fermeture est l'interface utilisateur standard sur le bureau et le Web. Essayez-le sur n'importe quelle application Google Documents (par exemple).