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

Fenêtres de dialogue modales

Sophie Schuermans le 17/06/2015

Pas le temps de tout lire? Utilisez le plugin jQuery Simple and Accessible Modal Window de Nicolas Hoffmann (Github).

Il existe deux types de fenêtres de dialogue: modales et non modales. Lorsqu'une fenêtre modale est ouverte on ne peut plus interagir avec le reste de la page. Il faut la fermer avant de pouvoir continuer à lire ou travailler. Nous trouvons ce type de fenêtre dans le système d'exploitation de notre ordinateur. Ce sont ces fenêtres qui nous demandent de confirmer une action. Par exemple si nous fermons un message e-mail qui n'a pas été envoyé.

dialoogvenster mail app save message as draft

Les fenêtres de dialogue non modales sont similaires, mais n'interrompent pas l'application. Vous pouvez continuer à travailler pendant que la fenêtre est ouverte. C'est le cas, par exemple, de la fenêtre de recherche dans Microsoft Word.

Sur le web, on trouve beaucoup de fenêtres de dialogue modales, par exemple pour se connecter à un service, s' inscrire à une liste de diffusion ou afficher des galeries d'images. On les appelle aussi 'lightbox' ou 'overlay'. Les fenêtres non modales existent aussi mais sont moins courantes. Nous nous concentrons ici sur le comportement attendu d'une boîte de dialogue modale accessible.

Gestion du focus

  1. un bouton ou un lien ouvre la fenêtre
  2. le focus est déplacé vers la fenêtre modale
  3. après la fermeture de la modale, le focus revient au bouton d'ouverture

L'ouverture d'une fenêtre de dialogue est une action. Il est en général préférable d'utiliser un <button> pour déclencher son ouverture et non un <a href="">, car l'action ne provoque pas la navigation vers une nouvelle page.

Lors de l'ouverture, le focus se déplace vers la fenêtre modale. Sans ce déplacement de focus, un utilisateur de lecteur d'écran n'est pas informé que quelque chose s'est produit. Il pense que le bouton ne fonctionne pas. Un utilisateur qui navigue au clavier devra tabuler et passer par tous les éléments de la page avant d'atteindre la fenêtre modale car celle-ci se trouve généralement à la fin du code source.

Faites donc se déplacer le focus vers l'élément ( <div> ) englobant la fenêtre modale, ou éventuellement vers le premier élément de formulaire de la modale. La première option est préférable pour les personnes aveugles car on ne saute aucune information. La deuxième option est plus commode pour les utilisateurs qui naviguent au clavier car le focus se trouve directement sur le premier élément qui nécessite une action.

Le déplacement du focus peut se faire via la méthode JQuery .focus(). Le <div> de la modale où devrait se déplacer le focus ne peut normalement pas recevoir le focus. Cela peut être résolu en ajoutant l'attribut tabindex="-1". Tabindex -1 ne place pas le <div> dans l'ordre de tabulation, mais permet qu'il puisse recevoir le focus via javascript.

Lors de la fermeture de la boîte de dialogue, le focus retourne sur l'élément (bouton) qui a ouvert la fenêtre modale. Dans le cas contraire un utilisateur de lecteur d'écran sera désorienté.

Attention, le lecteur d'écran Supernova de Dolphin qui est très populaire auprès des personnes ayant un handicap visuel en Belgique ne gère pas le déplacement du focus. Nous avons informé les développeurs, mais à notre grand étonnement ils ne voient pas cela comme un problème. Vous trouverez plus d'informations sur notre billet de blog consacré à Supernova et à la gestion du focus.

Piège au clavier

Il est non seulement important que le focus se déplace jusqu'à la boîte de dialogue, mais il ne doit pas en sortir. Une boîte de dialogue modale doit être refermée avant de pouvoir à nouveau interagir avec le reste de la page. Dans la majorité des implémentations, le piège au clavier n'est pas présent. Il est possible de sortir de la fenêtre de dialogue en utilisant le TAB ainsi que le curseur du lecteur d'écran. Comment faire pour éviter cela?

Pour qu'un utilisateur de lecteur d'écran soit confiné à la boite de dialogue lorsque celle-ci est ouverte, on cache tout le reste du contenu de la page avec aria-hidden. Placez un attribut aria-hidden sur tous les blocs (header, main, footer) qui sont au même niveau que la boîte de dialogue. Ne les placez pas sur un élément parent, tel que <body>. Basculez cet attribut via JavaScript de aria-hidden="false" à aria-hidden="true" à l'ouverture de la fenêtre de dialogue. Pour le <div> de la fenêtre de dialogue faites l'inverse. Les lecteurs d'écran ignorent les éléments avec aria-hidden = "true".

L'utilisation de l'attribut aria-hidden n'a d'influence que sur ce qui est vu par un lecteur d'écran et n'influence pas l'ordre de tabulation. Il faut utiliser du Javascript pour créer une boucle de tabulation à l'intérieur de la fenêtre de dialogue. Exemple: keep-focus sur Github.

Assurez-vous en outre de donner la possibilité à l'utilisateur de fermer la fenêtre avec la touche ESC.

Indication visuelle de focus.

En plus de bloquer le focus à l'intérieur de la modale, n'oubliez pas de rendre ce focus bien visible. Si ce n'est pas le cas, un utilisateur qui navigue au clavier ne pourra savoir sur quel élément il se trouve. Les navigateurs affichent un focus par défaut. Firefox (Gecko) et Internet Explorer (Trident) affichent un bord pointillé tandis que Chrome et Safari (Webkit) affichent un ligne continue. Il est préférable de renforcer le focus pour le rendre clairement visible. En tous cas, ne le supprimez pas. Attention, certaines feuilles de styles de "Reset" CSS peuvent annuler le focus.

De boutons qui ont du sens

Les boîtes de dialogue ont souvent un bouton de fermeture en forme "x" comme les boutons de fermeture des fenêtres du système d'exploitation. Faites en sorte que ce bouton se trouve dans l'ordre de tabulation et soit compréhensible pour un utilisateur de lecteur d'écran. «x» n'est pas significatif. Donnez la valeur "Fermer" (<button>Fermer</button>) au bouton et utilisez une image d'arrière-plan (background-image) d'un "x". Ou bien choisissez une police d'icône avec texte caché.

ARIA

Pas encore entendu parle d'ARIA? Voici une introduction.

L'élément <dialog> introduit par HTML5 n'est pas encore supporté pas les navigateurs et lecteurs d'écran. ARIA permet de compléter l'information qui sera transmise au lecteur d'écran. En utilisant <div role="dialog">, le div est annoncé comme une fenêtre de dialogue modale.

La fenêtre modale est maintenant bien reconnue, mais n'a pas encore de nom. Avec l'attribut aria-labelledby le titre <h1> de la modale est relié à l'élément <div> parent.

Certains lecteurs d'écran ne lisent que les éléments de formulaire à l'intérieur de la modale car role="dialog" les fait basculer en mode formulaire. Théoriquement c'est correct car une modale ne sert en principe pas à présenter des informations détaillées. Mais c'est un problème si la fenêtre modale contient également du texte. La solution est d'ajouter un <div role="document"> à l'intérieur du div principal. role="document" fait passer le lecteur d'écran du mode formulaire au mode navigation. Cela permet aux lecteurs d'écran de lire la totalité du contenu.

Résumé

  • Le focus se déplace vers la fenêtre modale (div extérieur) quand elle s'ouvre
  • Le focus est visible
  • Le focus est prisonnier de la fenêtre modale
  • Quand on ferme la modale, le focus retourne à l'élément qui a déclenché son ouverture
  • Les boutons sont bien nommés
  • Il est possible de fermer la fenêtre modale avec ESC
  • Utilisez role="dialog" pour le div qui contient la modale
  • Utilisez role="document" pour le contenu
  • Utilisez aria-hidden="true" pour cacher le reste de la page aux lecteurs d'écran.

Exemple

Le plugin créé par Nicolas Hoffmann respecte tous les points ci-dessus : jQuery Simple and Accessible Modal Window by Nicolas Hoffmann (Github)

fenêtre modale

Réagissez

Directive européeenne : il faut exiger plus

Sophie Schuermans le 09/06/2015

Aux 28 ministres européens des télécommunications, à monsieur le ministre De Croo:

Les institutions Européennes ont promis une législation qui impose aux sites web d'être accessibles. Pour atteindre cet objectif il faudra améliorer les propositions actuelles de manière drastique. Sans cela, les efforts n'auront servi à rien.

Dans sa réponse à une question écrite, le ministre De Croo apporte son soutien à la directive européenne qui imposera aux sites web des pouvoirs publics d'être accessibles:

Je soutiens en outre l'initiative européenne visant à parvenir à 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. Cela s'applique à tous les sites internet publics et aux sites internet des organisations qui exercent des missions publiques.

Il nous l'a également confirmé sur twitter (en néerlandais), par l'intermédiaire du compte @digitalagendaBE, suite à notre interpellation le 21 mai:

Nous nous en réjouissons. Mais nous voulons également appeler notre ministre à demander que cela devienne une loi utile qui fasse réellement une différence pour les 80 millions de citoyens handicapés en Europe.

La proposition de directive de la commission Européenne du 3 décembre 2012 manquait de substance:

  • nombre limité de sites web publics concernés,
  • uniquement les sites web, pas les autres document électroniques,
  • ne concerne pas les sites web,
  • pas de sanctions,
  • pas de point de contact pour les plaintes.

Le parlement européen a vu ces lacunes et a formulé toute une série d'amendements à la proposition de directive. Ils ont été acceptés avec 92% des voix le 26 février 2014.

C'était très encourageant mais, depuis lors, il fait très calme du côté des états membres et de la Commission. Le dernier rapport sur l'état d'avancement des travaux relatifs à l'accessibilité du web (PDF-document) de la présidence lettone du Conseil de l'UE, contient des propositions inquiétantes:

  • pas d'applications mobiles,
  • exception pour les documents téléchargeables,
  • exception pour le contenu de tiers (third party content).

Nous appelons le ministre De Croo à balayer ces propositions lorsqu'il prendra part vendredi à la réunion du Conseil de L'union Européenne et à convaincre ses collègues d’adopter la version du Parlement Européen. L'European Blind Union a publié l'année passée ces recommandations pour les membres du conseil de l'UE (document Word) et ces conseils sont toujours entièrement d'actualité.

Il faut une législation. Les plans d'action facultatifs ne produisent pas de résultats. Nous attendons cette directive depuis longtemps et l'échéance ne sera de nouveau pas respectée. L'Agenda Numérique pour l'Europe indique que

La Commission engagera les actions suivantes: (...) présenter en 2011 (...) des propositions visant à garantir que les sites web du secteur public (et ceux qui fournissent des services fondamentaux aux citoyens) soient pleinement accessibles au plus tard en 2015.

Nous sommes en juin 2015 et les états membres sont encore toujours en train de discuter les propositions.

Merci de faire en sorte qu'il y ait une loi, mais surtout que cette loi atteigne son objectif : que les personnes handicapées puissent profiter comme tout le monde du passage vers le numérique.

Réagissez

Accessibilité du Service Public

Sophie Schuermans le 21/05/2015

Aujourd'hui c'est la Global Accessibility Awareness Day, la journée mondiale de sensibilisation à l'accessibilité numérique, #GAAD sur twitter.

The purpose of the day is to get people talking, thinking and learning about digital (web, software, mobile, etc.) accessibility and users with different disabilities.

Nous voulons nous intéresser aujourd'hui au Service Public. A tous les niveaux (fédéral, régional, pouvoir locaux), le Service Public s'engage résolument dans la voie du numérique. C'est une excellente nouvelle car le monde numérique a le potentiel d'être plus accessible que le monde physique. Mais aujourd'hui il est loin de l'être.

logo fédéral logo région Bruxelles Capitale

Les différents niveaux de pouvoir en Belgique partagent notre vœu d'un service public plus accessible. Il n'y a aucun doute à ce sujet. Ils ont signé la convention ONU sur les droits des personnes handicapées et il existe au niveau fédéral une loi pour lutter contre les discriminations. Mais la mise en œuvre n'est pas efficace et ne produit que peu de résultats.

logo Wallonie logo gouvernement Flamand

Un passé peu probant

Depuis 2003 le gouvernement wallon s'est engagé à rendre accessibles la majorité des sites web de la Région Wallonne, comme l'indique la déclaration d'accessibilité de presque tous ses sites. Mais à part les sites de l'AWIPH, cela fait quelques années qu'aucun site du service public wallon n'a plus été labellisé AnySurfer.

Le secteur touristique fait exception et se distingue par son attention pour l'accessibilité de ses sites web. Cela s'explique par le label '5 soleils' qui récompense les attractions touristiques de qualité et exige entre autres l'obtention du label AnySurfer.

Du côté de la Flandre, c'est en 2004 que le gouvernement a décidé que tous ses sites devraient être accessibles. Comme en Wallonie, l'accessibilité fait partie du cahier des charges des appels d'offres. Mais il ne semble pas y avoir de contrôle, de récompense ou de pénalité, quel que soit le résultat. Le projet Toeweb qui avait contribué, entre autres grâce à des formations, à améliorer de manière significative l'accessibilité des sites web flamands a été mis en veille.

Chaque année des dizaines des sites du service public fédéral sont audités à la demande de la Chancellerie du Premier Ministre. Après réception du rapport d'audit, qui est pourtant truffé d'explications, rares sont les sites pour lesquels des corrections sont faites en vue d'améliorer l'accessibilité. Ce n'est pas si étonnant car les rapports d'audit n'ont en général pas été demandés par les responsables des sites.

A Bruxelles trois ordonnances ont été votées en matière d’égalité de traitement et de promotion de la diversité au sein des entreprises privées et des institutions publiques régionales et locales. Elles semblent être respectées pour les nouveaux sites ayant trait à l'emploi. Plusieurs sites de la région Bruxelloise ont été labellisés les deux dernières années et des formations ont également été données à l'intention de fonctionnaires de la région.

Un futur encore incertain

Dans l'accord du gouvernement fédéral il y a deux phrases qui nous intéressent :

L’autorité étudiera les modalités lui permettant de favoriser, de concert avec les communautés et la société civile, l’inclusion numérique, tant sur le plan de l’accessibilité et de l’accès que sur le plan de l’utilisation des TIC dans la vie quotidienne.
Les sites web et les documents numériques seront au maximum accessibles à tous les usagers, en ce compris les personnes âgées, les daltoniens, les malvoyants et les personnes avec un handicap.

Nous pensions que cela se concrétiserait lors du lancement du plan Digital Belgium de monsieur le ministre De Croo. Ce plan d'action numérique définit une vision à long terme pour notre pays et la traduit en ambitions concrètes. Nous n'y avons pas trouvé un mot sur l'accessibilité.

Nous espérons que la proposition de loi sur l'accessibilité numérique se concrétisera. Presque tous les pays Européens ont une législation dans ce domaine. N'attendons pas que la directive Européenne nous y oblige.

En Wallonie l'Agence du Numérique a pour mission de définir et mettre en œuvre les politiques publiques wallonnes en matière de TIC, pour faire de la Wallonie un territoire d'excellence numérique. Sans accessibilité on ne pourra pas parler d'excellence.

La Flandre va investir 10 millions d'Euros dans les 3 prochaines années dans les services numériques. La nouvelle agence 'Informatie Vlaanderen' est chargée du projet.

To do

Que ce soit au niveau fédéral, en Flandres, en Wallonie ou à Bruxelles, l'accessibilité numérique ne fait pas encore partie de manière explicite de l'agenda numérique. Il faut absolument l'y inclure, sans quoi elle sera oubliée.

La législation ne suffit cependant pas pour créer des sites web et services accessibles. Voici quelques points clés pour aller vers un Service Public plus accessible:

  1. Sensibiliser. Les règles d'accessibilité sont perçues comme des contraintes et se heurtent à beaucoup de résistance. Il faut sensibiliser à tous les niveaux de l'organisation pour faire comprendre l'importance de l'accessibilité et vaincre cette résistance.
  2. Placer la responsabilité au bon endroit. Tout le monde a un rôle à jouer, mais il vaut mieux donner la responsabilité du côté technique, à ceux qui produisent les services, plutôt que dans des services liés au handicap où à l'égalité des chances.
  3. Connaissances et expertise. Formez des collaborateurs pour qu'ils aient l'expertise nécessaire en accessibilité, ou engagez des personnes ayant cette expertise. Exigez que les prestataires externes aient un expertise suffisante en accessibilité.
  4. Processus. Intégrez l'accessibilité à chaque étape des processus de production de contenu ou de services en ligne. C'est beaucoup plus efficace que de demander un audit quand tout est fini.
  5. Outils. Choisissez des outils (CMS, plugins, langages de programmation) les plus accessibles possible ou investissez l'amélioration de leur accessibilité. Ré-utilisez un maximum de composants accessibles. Améliorez-les en continu .

Ils l'ont fait

Comme bon exemple, on peut citer le gouvernement canadien. Une personne aveugle avait déposé une plainte parce qu'elle ne pouvait pas postuler en ligne pour un emploi du Service Public. Le Canada a perdu le procès et s'est trouvé dans l'obligation de rendre ses sites web accessibles. En 15 mois le gouvernement canadien a formé 4000 développeurs et rendu accessibles 10 millions de pages web. Voir linterview de David Macdonald, lead accessibility consultant. Ses conseils:

drapeau canadien
  • Get senior management buy-in either by carrot or stick.
  • Choose the IT frameworks carefully
  • Design for accessibility when the cement is wet
  • Get the templates right
  • Train your staff

En conclusion

Au ministre fédéral de l'Agenda Numérique Alexander De Croo,
à la ministre Flamande de l'intérieur et de l'égalité des chances Liesbeth Homans,
à la secrétaire d'état Bruxelloise pour l'egalité des chances, l'informatique et la transition numérique Bianca Debaets,
au ministre Wallon de l'innovation et du Numérique Jean-Claude Marcourt:

Pouvons nous travailler ensemble pour faire avancer l'accessibilité numérique?

Réagissez

Le 21 mai : Global Accessibility Awareness Day

Sophie Schuermans le 18/05/2015

Le 21 mai c'est la journée mondiale de sensibilisation à l'accessibilité numérique, la Global Accessibility Awareness Day. Si vous venez de froncer les sourcils en vous demandant ce que signifie "accessibilité numérique", ce sera l'occasion idéale de le découvrir. Si vous êtes déjà au courant, ce sera l'occasion de partager cette information autour de vous, d'apprendre quelque chose de nouveau ou de poser un acte concret pour améliorer l'accessibilité d'un contenu web.

Le défi que nous vous proposons : le 21 mai, faites un geste pour l'accessibilité numérique et parlez-en autour de vous.

Encore beaucoup à faire

En Belgique 15% de la population a un handicap. L'accessibilité numérique est nécessaire pour que toutes ces personnes puissent participer à la société. Mais l'accessibilité numérique touche bien plus de monde que cela. L'internaute "parfait", qui dispose de toutes ses facultés et qui est parfaitement équipé, est en minorité. Comme le dit Olivier Nourry :

Et pourtant actuellement seuls 14% des sites web en Belgique sont accessibles à tous. Faire ses courses ou ses opérations bancaires en ligne, réserver un billet d'avion par exemple sont des choses qui sont impossibles à faire pour de nombreux internautes, non pas parce que la technologie n'est pas disponible, mais parce que les interfaces sont mal conçues.

Le défi

1. Mettez-vous en situation de handicap

Commencez par vous mettre en situation de handicap, pour quelques minutes ou quelques heures. Choisissez une ou plusieurs des options ci-dessous:

  • Débranchez votre souris et n'utilisez que votre clavier pour naviguer sur internet. Utilisez le TAB pour vous déplacer de lien en lien, et ENTER pour activer un lien.
  • Coupez le son de votre ordinateur pour la journée, même quand vous tombez sur des vidéos.
  • Utilisez NoCoffee Vision Simulator (extension Chrome) pour simuler le daltonisme et une perte de contrastes.

    réglages dans l'extension Nocoffee : color deficiency=deuteranopia, contrast loss=30
  • Remplacez les images par leur alternative textuelle sur les pages que vous visitez. Pour cela, dans Firefox, utilisez l'option 'Replace images with alt attribute' de la barre d'outils web developer.

Si vous rencontrez des problèmes pour consulter, pour percevoir ou pour comprendre le contenu, c'est que le site web n'est pas suffisamment accessible.

2. Améliorez l'accessibilité d'un contenu web

Faites une petite chose qui va améliorer l'accessibilité de votre (futur) site web. Choisissez en fonction de votre profil:

Si vous rédigez du contenu :

Si vous êtes graphiste :

Si vous êtes intégrateur

  • Si le focus n'est pas visible lors de la tabulation, partez à la recherche des outline:none dans le CSS et supprimez-les sans pitié.
  • Vérifiez que les champs de formulaires soient bien visibles et reliés à leur label dans le code HTML. Si ce n'est pas le cas, corrigez.

La liste de propositions est loin d'être exhaustive. Vous pourriez aussi prendre au hasard une des directives AnySurfer et voir si vous pouvez la mettre en pratique.

3. Parlez-en

Nous vous invitons à parler d'accessibilité numérique autour de vous. Partagez ce que vous avez découvert, vantez-vous des améliorations que vous avez faites et n'hésitez pas à nous envoyer vos remarques ou questions. Le hashtag du jour sera #gaad.

Merci d'avoir participé. Vous continuez demain?

Réagissez