HTML5 outline n'est pas supporté

Sophie Schuermans le 03/06/2016

Traduction de l'article en néerlandais HTML5 outline algorithm. Mis à jour le 2 juin 2016

En résumé

  • Continuez à utiliser une hiérarchie correcte de titres ( <h1>, <h2>, <h3>,...) pour structurer vos pages web, même lorsque vous utilisez des éléments sectionnants.
  • Ne vous appuyez pas sur le nouvel outline HTML5 qui calcule automatiquement le niveau de titre sur base de l'imbrication des éléments sectionnants (<section>, <nav>,<aside> et <article>).

Les personnes qui n'ont pas de vue d'ensemble de leur écran, comme les personnes aveugles ou malvoyantes, peuvent utiliser un logiciel qui lit tout ce qui est affiché à l'écran. Ce logiciel, appelé lecteur d'écran, fait plus que simplement lire le contenu affiché. Il annonce entre autres les titres, les listes et les tableaux. Lorsqu'un lecteur d'écran vocalise un titre, le lecteur d'écran annonce également le niveau du titre. Par exemple sur notre page Eviter le spam sans captcha un lecteur d'écran lira 'Eviter le spam sans captcha titre de niveau 1'. Un peu plus bas le sous-titre 'pas de captcha' est lu 'Pas de captcha titre de niveau 2'. Et ainsi de suite.

indication des niveaux de titre dans l'article sur les captcha

Cette information est cruciale pour ceux qui ne peuvent pas (ou à peine) voir l'écran. Les niveaux de titre permettent de mieux comprendre la structure de la page. Le lecteur d'écran permet également de sauter d'un titre à l'autre en utilisant un raccourci clavier ('t' pour 'titre') ou d'obtenir un liste de tous les titres (outline) de la page. La capture d'écran ci-dessous montre une liste de titres obtenue avec le lecteur d'écran VoiceOver sur Mac.

liste de titres obtenue avec VoiceOver

C'est pour cela que les directives d'accessibilité demandent d'utiliser une structure de titres logique. C'est essentiel pour les visiteurs ayant une déficience visuelle. Cela favorise également le référencement naturel.

HTML5 a introduit de nouveaux éléments qui permettent de mieux structurer les pages web. Ce sont les éléments sectionnants, comme par exemple <section>, <nav>,<aside> et <article>.

En HTML4 il était toujours nécessaire d'indiquer explicitement les niveaux de titre. Le titre principal de la page est un h1, un sous-titre un h2 etc. Si vous utilisez les nouveaux éléments sectionnants proposés par HTML5, vous pouvez (mais n'êtes pas obligé) utiliser toujours h1 en début de section. C'est l'imbrication des éléments sectionnants qui détermine la structure du document, et donc les niveaux de titre (voir l'algorithme d'outline d'HTML5). Pour chaque niveau d'imbrication le niveau de titre est incrémenté de 1. Un h1 qui se trouve à l'intérieur d'un élément section imbriqué dans un autre élément section devient automatiquement un h2. Si vous utilisez un h1 dans un élément sectionnant qui est imbriqué au 3ème niveau, il devient un h3 dans l'outline, etc.

En théorie

Ci-dessous, un exemple (source: W3C) avec une hiérarchie de titres traditionnelle.

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Color</h2>
  <p>Apples come in various colors.</p>
 </section>
</body>

L'outline des titres devient::

<h1>Apples</h1>
<h2>Taste</h2>
<h3>Sweet</h3>
<h2>Color</h2>

La spécification HTML5 permet de n'utiliser que des h1:

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h1>Taste</h1>
  <p>They taste lovely.</p>
  <section>
   <h1>Sweet</h1>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>
</body>

Grâce à l'utilisation de sections ce sera interprété exactement de la même manière:

<h1>Apples</h1>
<h2>Taste</h2>
<h3>Sweet</h3>
<h2>Color</h2>

En théorie cet algorithme devrait faciliter la vie d'un développeur, à conditions qu'il utilise un hiérarchie correcte de sections (et autres éléments sectionnants comme <nav>, <aside> et <article>). Mais est-ce que cela donne de bons résultats lors d'une lecture avec un lecteur d'écran? Est-ce que les personnes aveugles et malvoyantes vont entendre des niveaux de titre corrects?

En pratique

L'exemple ci-dessus ("apples") utilisant des éléments <section> et uniquement des h1 donne les résultats suivants pour les lecteurs d'écrans les plus courants:

logo NVDA NVDA
  • version 2016.1 avec IE11 et FireFox 46: pas de support, ne lit que des h1
logo Supernova Supernova
  • version 13.59 avec Internet Explorer 11: pas de support, ne lit que des h1
logo VoiceOver VoiceOver
  • OS X 10.11.5 (El Capitan) avec Safari 9.1.1: pas de support, ne lit que des h1
logo Jaws Jaws
  • versions 15, 16 et 17 avec IE11 et Firefox 46: pas de support, ne lit que des h1

Conclusions du test:

Il n'y a pas de support pour l'outline HTML5 de la part des principaux lecteurs d'écran. Si vous utilisez des éléments sectionnants en combinaison avec des h1 uniquement, la structure des pages ne sera pas visible pour la majorité des visiteurs utilisant un lecteur d'écran. La spécification HTML5.1 déconseille de compter sur l'algorithme d'outline pour construire la hiérarchie de titres

There are currently no known implementations of the outline algorithm in graphical browsers or assistive technology user agents, although the algorithm is implemented in other software such as conformance checkers. Therefore the outline algorithm cannot be relied upon to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure.
Réagissez

Nouvelles conditions pour les prestataires reconnus

Sophie Schuermans le 26/05/2016

Les agences web sont nos partenaires les plus importants pour rendre le web plus accessible. C'est pourquoi nous donnons le statut de prestataire reconnu aux agences web qui ont démontré leur savoir-faire en accessibilité. La liste de prestataires reconnus compte à ce jour 12 agences web. On peut leur faire confiance pour développer un site web accessible.

Nous souhaitons d'une part voir cette liste s'allonger et d'autre part établir une meilleure relation avec les agences web belges. Nous avons des idées pour modifier les conditions d'agrément des prestataires reconnus et souhaitons connaître vos avis sur cette proposition.

Conditions actuelles

Il y a actuellement 4 conditions pour devenir prestataire reconnu:

  • Suivre une formation technique chez AnySurfer
  • Obtenir le label AnySurfer pour le site web de l'agence web
  • Obtenir le label AnySurfer pour le site d'un client
  • Proposer un CMS qui permet de produire du contenu accessible

Pour conserver le statut de prestataire reconnu:

  • Produire chaque année un site qui obtient le label AnySurfer
  • Suivre une formation tous les deux ans

Certains candidats trouvent que la barre est un peu trop haut. D'autres nous font remarquer qu'ils est difficile de produire un site labellisé chaque année, puisqu'une partie de la responsabilité se trouve chez leur client. C'est d'ailleurs la raison pour laquelle nous n'avons pas été très stricts concernant cette dernière condition.

Proposition de nouvelles conditions

L'idée de base reste la même: un développeur web obtient la reconnaissance quand il a démontré les connaissances et l'expérience nécessaires en accessibilité numérique.

Nous baissons le seuil pour devenir prestataire reconnu:

  • Suivre une formation technique est la base et reste obligatoire.
  • L'agence web doit obtenir le label AnySurfer pour son site ou le site d'un client. Cela fait une condition de moins à satisfaire.
  • L'agence web fournit à son client une documentation adaptée au CMS utilisé qui lui décrit comment créer du contenu accessible.

Pour conserver l'accréditation, nous demandons aux agences Web d'entretenir leur expertise en accessibilité. Cela peut être fait de plusieurs façons:

  • Obtenir le label AnySurfer pour le site d'un client
  • Construire un site web qui est conforme aux directives d'accessibilité, sauf pour des points rédactionnels, qui sont sous la responsabilité du client. Par exemple, créer des documents accessibles, sous-titrage des vidéos ou d'autres éléments de contenu.
  • Faire suivre une formation aux nouveaux collaborateurs
  • Partager connaissances et savoir-faire:
    • Conférences, séminaires, rencontres, billets de blog où l'accessibilité est abordée
    • Partager du code, par exemple un système d'onglets accessible pour Drupal
    • ...

Avantages pour les prestataires reconnus

La liste des prestataires reconnus actuelle sur notre site Web est une liste alphabétique de liens. Nous voulons mettre les prestataires reconnus davantage à l'honneur. Comme pour les sites labellisés, nous voulons également également offrir une page de statut aux prestataires reconnus. De cette façon, vos clients potentiels auront davantage d'information:

  • Quels genre de projets réalisez-vous? Plutôt de grands sites commerciaux ou de petits sites pour des associations ou PME?
  • Quelle est votre spécialisation?
  • Avec quel(s) CMS travaillez-vous?
  • Quelle est votre contribution pour un internet plus accessible? Avez-vous labellisé des sites, produit des modules accessibles, corrigé des bugs d'accessibilité dans des applications open source, fait des présentations, écrit des articles ...

Qu'en pensez-vous?

Que pensez-vous des nouvelles conditions? Qu'est-ce qui vous empêche de devenir prestataire reconnu? Qu'est-ce qui vous motiverait? Laissez-nous votre avis dans un commentaire ou via un mail à info@anysurfer.be.

Réagissez

Trop d'exceptions dans la directive européenne

Pierre Jourdain le 19/02/2016

Cet article fait suite à Directive Européenne : il faut exiger plus. Dit artikel in het Nederlands: Teveel uitzonderingen in europees wetvoorstel

L'année dernière, le ministre de l'agenda numérique, Alexander De Croo promettait son soutien à "un règlement qui oblige les pouvoirs publics à rendre leurs sites accessibles aux visiteurs présentant un handicap fonctionnel, conformément aux normes internationales ouvertes en matière d'accessibilité au web". Les institutions européennes sont en train de discuter le contenu de ce texte.

Blindenzorg Licht en Liefde (NL), tout comme Slechtzienden- en Blindenplatform Vlaanderen (NL) et la Ligue Braille, n'est pas satisfait du contenu de la version la plus récente de la législation en cours de développement (PDF).

La proposition actuelle prévoit des exceptions pour:

  • Les intranets: comment une personne avec un handicap pourra-t-elle alors travailler dans une administration?
  • Les clips audio et vidéo: pourquoi dépenser de l'argent public pour leur réalisation, si 15% de la population ne peut les utiliser?
  • Les documents téléchargeables: la brochure informative et le formulaire de demande ne devraient pas être accessibles? Seule la page où télécharger ces documents devrait l'être?
  • Les sites des chaînes de télévision: les personnes handicapées ne doivent-elles pas savoir quels programmes sont diffusés ce soir à la télé?
  • Les sites des écoles et des crèches: l'obligation scolaire existe pourtant également pour les enfants handicapés et les enfants de parents handicapés.

Autres insuffisances dans le texte actuel du règlement:

  • Il s’appliquerait seulement aux sites web, et pas aux applications pour tablettes, smartphones, montres intelligentes, réfrigérateurs intelligents et tout ce que l'avenir nous réserve.
  • Le texte ne prévoit aucune sanction pour les sites qui ne sont pas accessibles.
  • Il manque également une référence à une autorité qui peut déterminer si oui ou non les sites répondent aux critères d'accessibilité.

Le texte devra changer radicalement pour que la loi atteigne l'objectif pour lequel elle a été établie: donner à tous les citoyens l'accès aux services en ligne, de plus en plus nombreux, fournis par les administrations.

C'est le cabinet du ministre De Croo qui représente la Belgique dans ces négociations. AnySurfer soutient l'appel des groupes d'intérêts belges à travailler sur un texte de loi effectif plutôt qu'une loi qui, en raison de nombreuses exceptions, sera dépassée au moment de sa publication.

Les ministres en charge des télécoms peuvent s'inspirer des amendements faits par le Parlement Européen qui ont été approuvés par 92% des votes en février 2014.

Le Conseil Supérieur National des Personnes Handicapées a conseillé au ministre De Croo de réglementer l'accessibilité des sites gouvernementaux nationaux par une loi. C'est pourquoi un projet de loi a été déposé à la chambre. On pourrait comprendre que le gouvernement attende que la réglementation européenne soit prête. Mais alors il faut que le gouvernement prenne ses responsabilités et demande au conseil européen des télécommunications que les propositions actuelles soient revues en profondeur.

Update du 22 février 2016

Monsieur le ministre De Croo a réagi sur Twitter : la position de la Belgique est que cette loi doit être un pas en avant pour l'accessibilité et il s'engage a essayer de convaincre les autres.

Merci, c'est une bonne nouvelle. Nous sommes prêts à aider si nécessaire!

Réagissez

L'accessibilité, un prérequis pour l'e-inclusion

Sophie Schuermans le 15/12/2015

Dit artikel in het Nederlands : Toegankelijkheid, een vereiste voor digitale inclusie

La fracture numérique est souvent expliquée par un manque de compétences ou de motivation du côté des utilisateurs. Le virage numérique peut être vu comme une menace par ceux-ci.

Pour d’autres personnes, en particulier les personnes handicapées, la numérisation de l’information est une chance. Des difficultés insurmontables dans le monde physique peuvent complètement disparaître dans le monde numérique. Ces personnes sont donc très motivées pour profiter au maximum des supports numériques.

Et pourtant, même lorsque les compétences et la motivation sont là, de nombreuses personnes handicapées se retrouvent dans l’impossibilité d’utiliser des services numériques. Le problème ne vient pas des utilisateurs mais des supports numériques qui ne sont pas accessibles à tous. Ce manque d’accessibilité est souvent causé par un manque de compétences ou de motivation chez les créateurs de contenus numériques.

C’est d’autant plus grave que le support numérique est souvent pour ces mêmes personnes la seule option disponible et que lorsque la technologie est bien utilisée elle peut supprimer beaucoup de barrières.

La technologie peut supprimer des barrières

Les progrès technologiques permettent aujourd'hui à presque tout le monde d’utiliser un ordinateur, tablette ou smartphone. Il est possible d’utiliser ces appareils avec sa voix ou avec le regard et bientôt même avec la pensée. Pour une personne qui ne peut pas tenir un bic en main ou parler au téléphone, ce type de technologie permet de communiquer et d’effectuer des actes de la vie quotidienne de manière autonome.

Le zoom sur smartphone est un outil précieux pour toutes les personnes dont la vue baisse avec l’âge. Un lecteur d’écran permet à une personne aveugle de naviguer dans une page web. Des applications comme Facetime facilitent la communication entre sourds. Et ce ne sont que quelques exemples parmi d’autres.

Quand les moyens de communication utilisés sont adéquats, il n’y a pas de handicap, comme Sylvie et Sophie en ont fait l’expérience en communiquant par messages directs sur twitter.

La situation crée le handicap

Une personne qui se promène avec un enfant en bas âge dans une poussette ne se considère pas en situation de handicap, jusqu'au moment où elle se retrouve face à une volée d’escaliers. Dans le monde numérique, c’est la même chose.

  • Une personne aveugle qui dispose d’un logiciel de lecture d’écran peut sans problème remplir un formulaire bien construit, mais ne pourra pas le soumettre s’il se termine par un CAPTCHA.

    exemple de re-captcha

    En utilisant une autre solution technique pour éviter le spam, le développeur peut faire en sorte de ne bloquer aucun utilisateur, mais uniquement des robots.

  • Une campagne de communication basée uniquement sur des vidéos sans sous-titres ou interprétation en langue des signes empêche toutes les personnes sourdes d’avoir accès au message. En prévoyant le sous-titrage et l’interprétation en langue des signes dans le budget on s’assure que le message pourra être compris par tous.
  • L’utilisation du rouge, orange et vert uniquement pour indiquer par exemple les heures d'affluence d’un magasin, rend cette information inutilisable pour un daltonien. Les bons designers le savent bien, et s’assurent de ne pas utiliser que la couleur pour transmettre l’information.

    heures d'affluence indiquées au moyen de la couleur et d'un pictogramme symbolisant 1, 2 ou 3 personnes
  • Le fait de désactiver le zoom sur un site web peut le rendre illisible sur un smartphone pour de nombreuses personnes.
  • Un contenu en Flash handicape l’internaute qui n’a qu’une tablette sous la main pour le consulter.

La responsabilité des créateurs de contenu numérique

Les visiteurs d’un site web utilisent des outils différents, ont différentes manières de percevoir l’information et d’interagir avec votre site. Certains ont un handicap.

Il faut en tenir compte lors de la création d’un contenu numérique.

Comme le dit Sarah Bourne, l’accessibilité ce n’est pas la cerise sur le gâteau. C’est plutôt comme les œufs. Il faut les ajouter au début, sinon c’est beaucoup plus de travail.

Les choix que font les responsables communication, les designers, les développeurs et les éditeurs de contenu peuvent vraiment créer des obstacles et effectivement mettre de nombreux internautes en situation de handicap, ou au contraire, faire en sorte que chacun ait la possibilité d’accéder au contenu.

Le dernier moniteur de l’accessibilité indique qu’à peine 15% des sites web belges sont utilisables pour les personnes handicapées. C’est beaucoup trop peu, et ce pourcentage n’évolue presque pas. AnySurfer propose des formations et de l’information pour aider toutes les personnes concernées par la conception de contenu numérique à faire de bons choix et à intégrer l’accessibilité dans le processus.

Conclusion

La Belgique est un des rares Etats de l’Union Européenne sans législation pour imposer que le monde numérique soit accessible à tous. Nous demandons aux responsables politiques de ne pas oublier cet aspect lors de l’élaboration de plans d’actions numériques.

Sans accessibilité, les compétences et les motivations des utilisateurs sont inutiles. Sans accessibilité, le virage numérique est une occasion ratée de donner à tous un accès égal à l’information et aux services. L’accessibilité est un prérequis pour l’e-inclusion.

Réagissez

Des onglets dans les règles de l'art

Sophie Schuermans le 15/09/2015

Le problème

Tout comme un diaporama, un système d'onglets est visuellement très intuitif mais peut vraiment porter à confusion pour quelqu'un qui ne voit pas l'écran ou qui n'en a pas la vue d'ensemble.

  • Pour un utilisateur de lecteur d'écran, les onglets ne sont pas une entité bien délimitée. Il n'est pas clair où le contenu d'un panneau d'onglet se termine. Après avoir atteint la fin de l'onglet l'utilisateur doit penser à remonter vers le haut pour sélectionner un autre onglet.
  • Quand on sélectionne un onglet, le panneau correspondant à cet onglet s'affiche, en remplaçant le contenu de l'onglet qui était sélectionné avant (rafraîchissement dynamique).
  • Les panneaux n'ont généralement pas de titre. L'onglet actif se distingue visuellement et fait office de titre pour le panneau correspondant, mais un utilisateur de lecteur d'écran ne dispose pas de cette information et ne sait pas quel est l'onglet actif.

screenshot tabs van Hans Hillen

Code de base d'un système d'onglets

<div id="Tabs">
<ul>
  <li><a id="tabsdemo-1-tab" href="#tabsdemo-1">Dogs</a></li>
  <li><a id="tabsdemo-2-tab" href="#tabsdemo-2">Cats</a></li>
  <li><a id="tabsdemo-3-tab" href="#tabsdemo-3">Sheep</a></li>
</ul>
			
<div style="display: block;" id="tabsdemo-1">
<p>The dog Canis lupus familiaris, is?</p>
</div>

<div style="display: none;" id="tabsdemo-2">
<p>The cat (Felis catus), also known as? </p>
</div>
				
<div style="display: none;" id="tabsdemo-3">
<p>Domestic sheep are quadrupedal?</p>
</div>

ARIA à la rescousse

Les onglets sont un des rares widgets pour lesquels nous recommandons fortement d'utiliser ARIA. Pour le faire correctement, partez d'une liste de liens (onglets) suivie d'une série de divs (panneaux pour le contenu), et ajoutez les éléments de sémantique qui n'existent pas en HTML:

  • changez la valeur sémantique des liens en "onglet" avec role="tab",
  • regroupez les onglets en liste d'onglets avec role="tablist" sur le ul,
  • écrasez la valeur sémantique des éléments li avec role="presentation",
  • indiquez avec aria-selected quel onglet est sélectionné. Ajoutez cet attribut à chaque onglet et n'oubliez pas de mettre à jour sa valeur à chaque changement.
  • indiquez le lien entre l'onglet et le panneau correspondant avec aria-controls. La valeur de cet attribut doit être celle de l'attribut id du panneau correspondant.
  • utilisez role="tabpanel" pour indiquer où commence et où termine un panneau d'onglet,
  • donner un nom à chaque panneau avec aria-labelledby. Cet attribut reçoit comme valeur l'id de l'onglet qui correspond à ce panneau.

Ce film montre étape par étape comment ajouter les attributs ARIA. Il contient également une discussion intéressante sur la manière de sélectionner les onglets. Entre temps la majorité semble d'accord pour dire que la deuxième solution est la meilleure : on utilise les flèches du clavier pour sélectionner un onglet et TAB pour aller au contenu de l'onglet. Cependant tous les utilisateurs ne savent pas encore qu'ils peuvent utiliser les flèches pour passer d'un onglet à l'autre.

Comportement au clavier

ARIA ajoute de l'information sémantique mais n'a pas d'effet sur l'aspect visuel ou la manière de fonctionner de l'interface. Pour que les onglets se comportent de la manière attendue pour les utilisateurs qui naviguent au clavier (dont les utilisateurs de lecteurs d'écrans), il faut également faire les choses suivantes:

  • Ajoutez tabindex="0" à l'onglet actif et tabindex="-1" à tous les autres onglets. De cette manière seul l'onglet actif se trouve dans l'ordre de tabulation.
  • Faites en sorte que l'on puisse utiliser les flèches pour passer d'un onglet à l'autre : en utilisant la flèche droite (ou vers le bas) le prochain onglet est sélectionné et le panneau correspondant s'affiche. Les flèches gauche et vers le haut sélectionnent l'onglet précédent.
  • Après avoir sélectionné un onglet avec les flèches, une tabulation doit déplacer le focus sur le panneau correspondant. Il est essentiel pour un utilisateur de lecteur d'écran que le focus se trouve tout en haut du panneau : soit sur le panneau lui même, soit sur le premier élément du panneau (titre). Si vous ne forcez pas ce comportement, le focus se déplacera vers le premier élément interactif qui se trouve dans le panneau, ou en dehors des onglets.
  • Après avoir lu le contenu d'un panneau il faut idéalement que l'utilisateur puisse facilement retourner à la liste d'onglet pour en sélectionner un autre. Cela peut être difficile quand un onglet contient beaucoup de liens ou un formulaire. La solution préconisée par les WAI-ARIA Authoring Practices 1.1 est d'utiliser les raccourcis clavier ctrl+flèche en ctrl+pageUp en ctrl+pageDownpour basculer d'un onglet à l'autre. Mais ces raccourcis ne fonctionnent pas dans certains navigateurs et entrent en conflit avec les raccourcis clavier de certains lecteurs d'écran.

Résultat

<div id="Tabs">
<ul role="tablist">
  <li role="presentation">
    <a role="tab" tabindex="0" aria-selected="true" aria-controls="tabsdemo-1" 
    id="tabsdemo-1-tab" href="#tabsdemo-1">Dogs</a></li>
  <li role="presentation">
    <a role="tab" tabindex="-1" aria-selected="false" aria-controls="tabsdemo-2" 
    id="tabsdemo-2-tab" href="#tabsdemo-2">Cats</a></li>
  <li role="presentation">
    <a role="tab" tabindex="-1" aria-selected="false" aria-controls="tabsdemo-3" 
    id="tabsdemo-3-tab" href="#tabsdemo-3">Sheep</a></li>
</ul>
			
<div role="tabpanel" style="display: block;" aria-labelledby="tabsdemo-1-tab" 
id="tabsdemo-1">
  <p>The dog Canis lupus familiaris, is?</p>
</div>

<div role="tabpanel" style="display: none;" aria-labelledby="tabsdemo-2-tab" 
id="tabsdemo-2">
  <p>The cat (Felis catus), also known as? </p>
</div>
				
<div role="tabpanel" style="display: none;" aria-labelledby="tabsdemo-3-tab" 
id="tabsdemo-3">
  <p>Domestic sheep are quadrupedal?</p>
</div>

Solution prête à l'emploi

Nicolas Hoffmann a encore une fois fait le travail pour vous : jQuery Accessible tab panel system, using ARIA - By Nicolas Hoffmann, et nous recommandons vivement d'utiliser son plugin.

Les onglets de Nicolas Hoffmann

Remarques

  • Le support pour ARIA varie d'un navigateur à l'autre, et d'un lecteur d'écran à l'autre et n'est pas toujours optimal. Les versions les plus récentes offrent le meilleur support, mais ce ne sont pas toujours celles qui sont utilisées par les internautes.
  • Il y a encore pas mal d'utilisateurs de lecteur d'écran qui ne comprennent pas ce que signifie "onglet" et comment ils sont censés interagir avec un tel module. Quand on active un onglet le lecteur d'écran bascule en mode formulaire (ou application). C'est ce qui permet d'utiliser les flèches pour basculer d'un onglet à l'autre. Mais quand on ne le sait pas c'est perturbant.
  • Nous pensons cependant que c'est quand même la meilleure solution dans le long terme. Le web devient plus compliqué et les internautes vont devoir s'adapter pour pouvoir continuer à l'utiliser. AU fur et à mesure que le support des navigateurs et lecteurs d'écran s'améliorera, les utilisateurs vont s'y habituer. Mais pour cela il est crucial que les onglets soient toujours implémentés selon les mêmes principes. Si vous n'utilisez pas le module de Nicolas, veillez à tester vos onglets de manière très approfondie.
  • N'utilisez pas de role="application" car cela empèche un lecteur d'écran d'avoir accès au contenu de l'onglet avec les touches du clavier habituelles. Plus d'infos à ce sujet dans l'article N'utilisez pas role="application".
Réagissez