1.1. Structurer la zone d’entête principale avec <header role="banner">

• Par Sylvain, le 23 mars 2016 à 18h12.

  Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

  

  Bonjour,
  Le fait de doubler l’information en utilisant la balise HTML 5 et la rôle ARIA correspondant n’est pas valide lorsqu’on passe la page au validateur du W3C. C’est d’ailleurs bien spécifié : ARIA in HTML.

  Par ailleurs cela risque d’entrainer une double vocalisation avec certaines synthèses vocales.

  Cela va à l’encontre des RGAA V3 mais est ce que vous avez prévu de faire évoluer cette règle ?

  Répondre

  • Par Sébastien Delorme, le 29 mars 2016 à 15h29.

    Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

    

    Bonjour Sylvain, et merci pour ce commentaire.

    Le fait de doubler l’information en utilisant la balise HTML5 et le rôle ARIA correspondant n’est pas valide lorsqu’on passe la page au validateur du W3C.

    Pour citer la fiche que tu commentes, la balise <header> ne doit pas être confondue avec le rôle ARIA role="banner".

    ARIA précise que role="banner" correspond à A region that contains mostly site-oriented content, rather than page-specific content (voir banner (role)). Il est ensuite précisé que ce rôle ne doit être utilisé qu’une seule fois par page : the author SHOULD mark no more than one element with the banner role.

    La balise <header> quant à elle correspond à une section d’introduction d’un article, d’une autre section ou du document entier. Elle peut être utilisée plusieurs fois sur une même page, à l’inverse de role="banner"

    L’objectif est donc bien différent et non redondant dans ce cas.

    Une page est d’ailleurs bien valide avec <header role="banner">, il ne s’agit que d’un avertissement donné par le validateur : Warning: The banner role is unnecessary for element header. Toutefois, à mon sens, il s’agit donc d’une coquille du validateur.

    Par ailleurs cela risque d’entrainer une double vocalisation avec certaines synthèses vocales.

    Comme l’objectif et la sémantique sont différents, aucune double vocalisation ne sera faite dans ce contexte.

    Cela va à l’encontre des RGAA V3 mais est ce que vous avez prévu de faire évoluer cette règle ?

    Nous sommes bien conformes avec le RGAA 3, puisqu’il demande explicitement cela :

    • Test 9.2.1 : Dans chaque page Web, la structure du document vérifie-t-elle ces conditions ?
      • La zone d’en-tête de la page est structurée via une balise header
      • […]
    • Test 12.10.4 : Dans chaque page Web, la structure du document vérifie-t-elle ces conditions ?
      • La zone d’en-tête de la page possède un rôle ARIA banner
      • […]

    Aussi, le RGAA précise dans le glossaire :

    Zone d’en-tête : zone située en haut du document et contenant généralement le titre du document, un logo, un slogan…

    Note : Attention à ne pas confondre cette zone d’en-tête, unique dans le site, avec tout contenu pouvant être balisé en HTML5 avec l’élément header.

    Là où l’utilisation de la balise HTML5 et du role peut être surperflue est éventuellement sur les fiches 1.3. Structurer la zone de contenu principal avec <main role="main"> et 1.5. Structurer les menus de navigation principaux et secondaires avec <nav role="navigation">. Mais je n’ai jamais rencontré de cas où la restitution était double, et d’ailleurs cette double mention est explicitement demandée dans le RGAA 3 au niveau des tests 9.2.1 (présence de la balise) et 12.10.4 (présence du rôle).

    PS : j’aurais aimé mettre les liens vers le RGAA 3 mais avec le site actuel il est impossible de faire des ancres dignes de ce nom, il faudra donc rechercher les références directement sur le référentiel technique RGAA 3.

    Bien à toi,
    Sébastien.

    Répondre

• Par Cedric, le 29 mars 2016 à 16h34.

  Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

  

  Bonjour,

  Je ne pense pas que ça soit une coquille du validateur HTML5.

  La documentation HTML5 définit la balise <header> comme ayant une sémantique native forte et comme ayant pour rôle ARIA implicite le rôle banner.
  La documentation HTML5 précise qu’il est recommandé de ne pas définir un rôle ARIA identique au rôle ARIA implicite, d’où le warning.
  La balise <header> ayant une sémantique native forte, je suppose que tout autre rôle que banner provoquerait une erreur (non testé).

  Semantics, structure, and APIs of HTML documents: Strong Native Semantics.

  Donc je pense qu’il y a bien une contradiction entre les règles du RGAA3, et donc la notice Accede Web, et la documentation HTML5.

  Répondre

  • Par Sébastien Delorme, le 29 mars 2016 à 17h29.

    Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

    

    Effectivement la balise <header> a une valeur sémantique forte.
    Le lien fournit est intéressant, il mentionne entre autres : header element that is not a descendant of an article or section element.

    Il est donc écrit que l’élément <header> correspond à role="banner" lorsque (et seulement dans cette situation) <header> n’est pas descendant d’un article ou d’un élément section.
    Ainsi, <header> n’a donc pas toujours la même sémantique que role="banner".

    Malheureusement (sauf erreur de ma part), la spécification HTML5 n’interdit pas l’usage de plusieurs <header> non descendants d’un article ou d’une section. Alors que role="banner", lui, doit explicitement être utilisé une seule fois par page. Il y a donc un léger manque sur ce point.

    Je pense que le RGAA 3 a fait le choix de doubler l’information pour garantir avec certitude la bonne restitution par les lecteurs d’écran (la restitution en double est quasi-impossible puisque le navigateur web va devoir choisir l’information qu’il renverra à l’API accessibilité du système d’exploitation).

    Nous avions longuement débattu en interne pour ne pas demander cette double information par exemple sur <main> et (dans une moindre limite) <nav>, et maintenant, effectivement, j’ajoute <header> à la liste.
    Mais comme nous cherchons également à garantir une conformité avec le RGAA 3, ce sujet reste donc à suivre (nous allons en redébattre).

    La documentation HTML5 précise qu’il est recommandé de ne pas définir un rôle ARIA identique au rôle ARIA implicite, d’où le warning.

    Nous sommes d’accords oui.
    C’est toutefois peu critique dans cette situation, et encore une fois, ça permet davantage de garantir une bonne restitution (qui certes ne correspond qu’à très très peu de situations).

    La balise header ayant une sémantique native forte, je suppose que tout autre rôle que banner provoquerait une erreur (non testé).

    En effet, à l’exception de role="presentation".

    Je ne pense pas que ça soit une coquille du validateur HTML5.

    Après vérification, et lecture de dernier commentaire, tu as raison.

    Donc je pense qu’il y a bien une contradiction entre les règles du RGAA3, et donc la notice Accede Web, et la documentation HTML5.

    Il n’y a pas réellement de contradiction, la recommandation de ne pas redéfinir le role ARIA implicite n’est seulement pas respectée.
    Le fait de ne pas surcharger un élément HTML5 avec son rôle n’est qu’une recommandation, il est parfois utile de le faire pour garantir un meilleur support pour les aides techniques.

    Toutefois, nous sommes assez ouverts à l’idée de faire évoluer ce point.
    Merci pour ton intervention argumentée et pertinente !

    Répondre

• Par Sylvain, le 30 mars 2016 à 8h54.

  Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

  

  Effectivement le validateur remonte bien des d’avertissements et non d’erreurs comme je le précisais.

  Merci Sébastien et Cédric pour les réponses précises.

  Répondre

• Par Loriane, le 12 novembre 2019 à 13h24.

  Ce commentaire a été publié sur une ancienne version des notices AcceDe Web. Il se peut que son contenu ne soit plus d'actualité.

  

  Bonjour,
  Dans le guide d’accessibilité pour intégrateur de la DINSIC, il est précisé « Afin de rendre l’utilisation des régions (balise HTML5 et landmarks) optimale, il est toujours préférable de ne pas inclure dans l’en-tête la navigation principale par exemple. De manière générale, il est préférable de ne pas imbriquer les régions principales définies ici. »

  Or ici vous précisez que ce n’est pas du tout un problème d’imbriquer plusieurs rôle ARIA.

  Quelle recommandation suivre ?

  Merci beaucoup pour votre réponse.

  Répondre

• Par Nicolas, le 21 janvier 2022 à 7h12.

  Ce commentaire a été publié il y a plus de 2 ans. Il se peut que son contenu ne soit plus d'actualité.

  

  Bonjour,

  Je reviens sur le commentaire de Sylvain datant de 2016, sur un sujet qui doit remonter aux alentours de 2013. Nous sommes aujourd’hui en 2022, qu’en est-il aujourd’hui de cette règle de doublement des roles de type Landmark (header, banner, main, etc…) ?

  On peut observer que le référentiel RGAA 4.1 a conservé ce test sur le critère 12.6, pourtant, [le W3c recommande encore et toujours de ne pas ajouter de rôles ARIA redondants](https://www.w3.org/TR/html-aria/#don-t-add-redundant-roles), et ce même sur les régions principales d’une page web.

  Aussi, WCAG indique dans sa checklist :
  > « HTML5 regions **or** ARIA landmarks are used to identify page regions. »

  Depuis toutes ces années, on pourrait en effet supposer que les technologies d’assistance ainsi que les navigateurs sont désormais à jour pour reconnaître le role implicite porté par les éléments HTML concernés…

  Existe-t-il encore des situations réelles où la redondance des rôles ARIA reste nécessaire ? Cette règle n’est-elle pas aujourd’hui obsolète ?

  Répondre

Ajouter un commentaire