Codez accessible !

Cet article a pour but d’encourager les développeurs comme moi à coder accessible. Beaucoup de développeurs pensent que l’accessibilité est une perte de temps, que c’est long à coder et surtout qu’elle est inutile. J’ai décidé de vous démontrer le contraire ! Vous verrez qu’avec quelques lignes de code en plus, on peut rendre accessible facilement un site internet.

Pourquoi me lancer dans l’accessibilité numérique ?

Parce que c’est utile à tout le monde ! Cela permet de ne plus isoler les personnes présentant un handicap qui empêche de naviguer sur Internet comme tout le monde.

Vous préparez également votre avenir. Si demain, vous commencez à perdre la vue (ce que je ne vous souhaite pas bien évidemment), vous serez content de pouvoir accéder à du contenu accessible. On aura tous besoin de l’accessibilité un jour !

Essayez également de tester votre site web en utilisant seulement votre clavier et non votre souris. Pour naviguer avec le clavier, utilisez la touche Tabulation et essayez de voir si vos éléments sont focusables (sélectionnés). Pour revenir en arrière, enfoncez la touche MAJ et appuyez sur Tabulation. Si les éléments ne sont pas focusables, c’est un problème pour les utilisateurs utilisant seulement le clavier pour naviguer sur Internet.

Récemment à Paris Web, Bertrand Binois, en parlant de son expérience avec PasdeCalais.fr, a mis le doigt sur les préjugés sur l’accessibilité numérique et je tenais à montrer son slide.

Ce qui a le mérite d’être clair !

A l’heure où on pense responsive, il faut aussi penser accessible. En ne rendant pas accessible votre site, vous privez des millions de personnes de votre contenu.

A quel moment puis-je intégrer l’accessibilité numérique sur un projet informatique ?

Dès le début du projet. Pas au milieu, pas à la fin. Dès le début.  Il est nécessaire de penser accessible dès les balbutiements du projet.

Si vous décidez d’intégrer l’accessibilité à votre site alors qu’il est terminé, il va falloir revoir page par page pour s’assurer que chaque page est accessible. Du coup, en repassant chaque page, vous risquez de devoir changer pas mal de choses.

Par exemple, vous décidez de rendre accessible un trottoir à une personne à mobilité réduite parce que la marche ne facilite pas son accès. Il faut donc casser les rebords du trottoir et y faire des abaissements de trottoir. Du coup, cela va coûter plus cher alors qu’il aurait fallu y penser avant, ce qui aurait minimisé le coût. D’autant plus que les bateaux sont très utiles pour les personnes âgées, les parents ayant des poussettes, une personne venant de se casser la jambe et marchant avec des béquilles temporairement.

Il en va de même pour les sites web. Un site accessible est utile pour les personnes handicapées mais aussi les personnes âgées ne sachant pas se servir correctement d’Internet ou une personne venant de se casser le bras temporairement et ne pouvant pas utiliser sa souris.

Pensez aussi aux sites intranet. Si un jour vous avez des employés atteints d’une maladie ou d’un handicap, le site intranet ne leur sera pas accessible. En ne rendant pas accessible les sites internes de vos entreprises, vous isolez les personnes en situation de handicap de la vie de l’entreprise.

Il est donc nécessaire de penser à l’accessibilité sur n’importe quel projet informatique.

Que dois-je faire pour rendre mon site accessible ?

Grâce à HTML5 complété de WAI-ARIA, on peut faciliter l’accessibilité des pages HTML. Voici quelques éléments.

Définir les rôles de votre page

Tout d’abord, définir les principaux rôles de votre page : « main » (contenu principal), « banner » (en-tête), « navigation » (menu), « contentinfo » (pied de page), « search » (zone de recherche).

L’attribut role et ses valeurs permettent de nous donner des informations sur le but de l’élément en question. Est-ce le menu, le contenu principal ou autre ? Les lecteurs d’écran peuvent restituer cette information pour accéder à la page principale, détecter immédiatement la navigation principale du document, etc.

Respecter l’ordre des titres

Il est également important de respecter l’ordre des headings (titres) : h1 > h2 > h3 > h4 > h5 > h6 et il ne doit pas y avoir de trou entre, par exemple, h1 et h3.

Le lecteur d’écran va tout de suite, en scannant la page, détecter la hiérarchie des titres. C’est pourquoi l’ordre des titres importe.

Définir les attributs ARIA

Il faut définir des attributs ARIA (Accessible Rich Internet Application) à chaque interface riche et HTML (popups, carrousels, onglets, menu, boutons, liens, etc.). Les attributs ARIA sont très utiles pour le lecteur d’écran car ils permettent de restituer l’information. Il existe déjà des plugins accessibles pour les interfaces riches donc il n’est pas nécessaire de tout re-coder. Il existe par exemple les plugins accessibles de Nicolas Hoffmann.

Un exemple : imaginez que vous avez plusieurs articles sur votre site et vous avez plusieurs liens qui permettent de voir la suite des articles. Mais comment différencier ces liens ? Nous verrons « Lire la suite » de l’article en question facilement mais ce n’est pas le cas des utilisateurs de lecteur d’écran.

<a href="…" aria-label="Codez accessible (Lire la suite)">Lire la suite</a>

Grâce à aria-label, les utilisateurs de lecteurs d’écran vont pouvoir savoir qu’il s’agit d’un lien qui permet d’aller vers la suite de l’article « Codez accessible ».

N’hésitez donc pas à utiliser les attributs ARIA, qui se révèlent très utiles et surtout très faciles à implémenter.

Voici quelques exemples d’attributs ARIA :

• aria-labelledby : description d’un élément
• aria-required : élément obligatoire
• aria-checked : élément coché
• aria-invalid : élément invalide
• aria-live : restitution du contenu à la suite d’un nouvel événement déclenché
• aria-expanded : élément déplié/replié
• aria-hidden : élément caché

Réaliser un formulaire accessible

Faites un formulaire accessible. Le label qui accompagne un champ doit toujours avoir l’attribut for avec l’id de l’input.

Exemples avec et sans l’attribut for et avec le lecteur d’écran.

Sans l’attribut for	Avec l’attribut for
<label>Email</label> <input type=”text” id=”email” />	<label for=”email”>Email</label> <input type=”text” id=”email” />
Le lecteur d’écran va restituer ces informations : édition vide	Le lecteur d’écran va restituer ces informations : Email  édition vide

En conclusion, grâce à l’attribut for, on restitue correctement le libellé accompagnant le champ texte. Il fait toute la différence ! C’est aussi valable avec les listes déroulantes, les radio boutons, les cases à cocher et autres.

Assurez-vous que les informations restituées sont accessibles comme les boutons radios (s’ils sont cochés ou non), les champs obligatoires, l’élément sélectionné dans la liste, etc., grâce aux attributs ARIA.

À noter, il faut éviter les CAPTCHA. Ceux-ci ne sont pas du tout accessibles car le texte proposé est souvent illisible et le bouton pour traduire le texte en version orale est inaccessible. Privilégiez les questions simples ou mathématiques.

Avoir un focus sur chaque élément

Les personnes malvoyantes et aveugles utilisent un lecteur d’écran et/ou le clavier pour naviguer sur le web. Il y a aussi des personnes ayant des tremblements de la main qui préfèrent l’utilisation du clavier plutôt que la souris. Donc pensez au focus de chaque élément.

A chaque focus (clic de la souris ou du clavier) ou hover (flottement de la souris) sur un élément (par exemple un lien ou un bouton), il est conseillé qu’il soit visible par un outline (contour de l’élément) avec éventuellement un fond de couleur et une taille assez large à définir grâce au CSS. Cela donne pour tous les utilisateurs une meilleure visibilité et, surtout, cela permet de mieux voir sur quel lien ou bouton on veut cliquer, avec la souris ou en tabulant. Si les éléments n’ont pas de focus et d’outline, je ne sais pas sur quel lien ou bouton je veux cliquer.

Créer des raccourcis

Il est également conseillé de créer des raccourcis : « aller au menu », « aller à la recherche », « aller au contenu » ou autre. Grâce aux raccourcis, on peut aller directement à la section en question avec la tabulation ou la souris. Ils peuvent être utiles à tous, y compris aux personnes âgées.

Définir le contraste, la police et le descriptif des images

Enfin, pensez également au contraste. Si votre site affiche un fond bleu et un texte en rouge, tout utilisateur ne pourra pas voir le texte à cause du fond ou de la couleur du texte qui gênent la lecture.

N’oubliez pas non plus de prendre en compte la police de caractère. Certaines tailles de police, ou la police elle-même, peuvent gêner la lecture du site notamment pour les personnes atteintes de dyslexie.

N’hésitez pas à décrire le contenu de vos images dans l’attribut alt de l’élément <img>.

Quels sont mes outils de travail pour tester l’accessibilité de mon site ?

Le clavier et un lecteur d’écran ! Mettez-vous dans la peau d’un utilisateur qui n’utilise que son clavier et/ou un lecteur d’écran (NVDA, Jaws, VoiceOver, TallBack).

Pour ma part, j’utilise NVDA avec visionneuse de paroles. (Étant sourde, je ne peux pas entendre la voix du lecteur d’écran, je me rabats donc sur la visionneuse de paroles.)

Il existe aussi des extensions, des navigateurs ou des plugins pour tester les pages accessibles. Quand j’ai codé pour la première fois de façon accessible, je ne savais pas comment tester. J’ai donc utilisé Tota11y, vous pouvez retrouver un de mes articles comment débuter dans l’accessibilité numérique sur le blog de Soft’it.

En conclusion

Vous avez maintenant tous les outils pour rendre votre site Internet accessible à tous et je vous conseille de consulter les notices d’AcceDe Web pour vous aider. Vous n’avez aucune raison de ne pas le faire. A chaque étape, pensez accessible et codez accessible !