Comment débuter dans l’accessibilité numérique ?

Etant sourde, je suis passionnée par l’accessibilité numérique et en tant que développeuse, je débute dans ce domaine. Pour mon projet personnel, j’ai pensé à l’accessibilité.

Qu’est ce que l’accessibilité numérique ?
Un site internet accessible permet de garantir que son contenu est utilisable par n’importe qui, quelle que soit sa situation, son handicap (visuel, auditif, moteur…) et le matériel (ordinateur, navigateur Internet, logiciels spécialisés) utilisé pour y accéder.

Mais comment débuter ?  

Pour débuter, j’ai décidé d’utiliser l’outil Tota11y, découvert sur Twitter, un outil de visualisation des pages web accessibles. Cet outil permet de vérifier les erreurs de développement commises qui empêchent l’accessibilité de vos pages.

Comme page de garde, j’utilise Bootstrap et son template pour les blogs. Je vais me servir comme exemple pour l’article qui mettra bien en évidence les erreurs. Mine de rien, la page, que j’ai créée, a l’air super sympa et sans défaut. Mais méfiez-vous aux apparences. Il y a des choses auxquelles on ne pense pas et, du coup, cela ne facilite pas du tout l’accessibilité de votre page !

access1

Comme vous pourrez le voir, l’outil Tota11y est très facile à installer et à utiliser. Voici les explications.

Installation

Vous pouvez récupérer le script « tota11y.js » sur Github.

Il suffit d’inclure le script JS à la fin du tag « body » comme ainsi

<script src="tota11y.min.js"></script>

Ensuite, au lancement du site, un petit logo « Lunettes » apparaît en bas à gauche. Maintenant voyons comment nous pouvons l’utiliser.access2

Titres

access3

La première option « Headings » permet de vérifier si l’ordre des headings (h1 à h6) est correct. Pour faciliter la navigation des lecteurs d’écran, les headings doivent être dans le bon ordre : h1 > h2 > h3 > h4 > h5 > h6 et il ne doit pas y avoir de trou entre, par exemple, h1 et h3.

Sur cette page, j’ai des h1, h2 et h4. L’alerte, à droite, m’informe qu’il manque un h3. C’est donc une grosse erreur. J’ai deux solutions : soit ajouter un titre en h3, soit remplacer les h4 par des h3 pour les rendre valides.

J’ai donc décidé de remplacer les h4 par des h3.  Tota11y m’indique à présent que la première étape est valide.

access4

Contrastes

La deuxième option concerne les contrastes. Pour les personnes malvoyantes, les personnes atteintes de daltonisme ou les personnes sourdes atteintes du syndrome d’Usher, le contraste est très important. Si la page n’a pas les contrastes suffisants, cela les empêche de bien la visionner car les disparités de couleurs peuvent gêner.

access5Imaginez que vous créiez une section en arrière plan bleu avec un texte en rouge comme ci-contre. Si le contraste n’est pas assez élevé, lire le contenu de votre site pourrait être aussi compliqué que si vous aviez besoin de lire le texte ci-contre.

Donc, revenons à ma page, Tota11y m’indique quelques erreurs :

  • La barre de menu : la couleur choisie comme bleu n’est pas compatible avec le texte également d’une autre variante de bleue
  • Le sous-titre n’est pas assez visible
  • Les liens sont trop clairs
  • Le pied est également insuffisant en contraste (le texte n’est pas visible)

access6

L’outil m’indique les couleurs qui ne sont pas assez visibles et un exemple de couleur dans la même teinte qui pourrait convenir pour la remplacer.

Si vous ne souhaitez pas utiliser les couleurs proposées par Tota11y, vous pouvez consulter le site (EN) ColorSafe et faire la combinaison vous-même tout en respectant les contrastes et le WCAG (Web Content Accessibility Guidelines).

Pour en savoir plus sur la gestion des contrastes, je vous invite à lire un bon article : Grille d’analyse des contrastes d’une charte.

J’ai donc suivi les recommandations données par l’outil et cela donne ceci :

access7

 Liens hypertextes

Tota11y m’indique qu’il y a deux erreurs de liens hypertextes.

Voici deux cas à ne pas faire :access8

Le premier cas, l’outil indique que le lien ayant pour titre « About » est confus. Avec le lecteur d’écran utilisé par les personnes aveugles et malvoyantes, l’utilisateur va comprendre que c’est un lien « About » mais le descriptif ne sera pas forcément clair pour lui. Du coup, pour résoudre ce problème, je vais ajouter un attribut ARIA (Accessible Riche Internet Application) à ce lien : aria-label= »about the blog ». Ainsi le lecteur d’écran va traduire que le texte de ce lien est « about the blog » grâce à l’attribut « aria-label » au lieu de « about ».

<a href="/Home/About/" class="blog-nav-item" aria-label="About the blog">About</a>

Le deuxième cas, qui est malheureusement très répandu, est à éviter à tout prix. Une phrase « Click here to see more » ou « Cliquez ici pour en savoir plus » est à proscrire (c’est aussi le point de vue Référencement/SEO). Rien que le mot here ou ici ne donne aucune information sur le lien à cliquer. Pour une meilleure visibilité du lien, il est nécessaire de donner quelques indications pour inciter à cliquer sur ce lien. Donc pour rectifier cela, je propose la solution suivante :

<a href="/Home/Article/1" aria-label="Lire la suite de l’article du passage de Lorem Ipsum standard">Lire la suite de l’article</a>

Ce que nous verrons c’est que c’est un lien pour voir la suite de l’article. Ce que le lecteur va lire, c’est un lien pour voir la suite de l’article du passage de Lorem Ipsum standard.

Pourquoi cette information supplémentaire ?

Imaginez que sur votre même page, il y a 5 articles et 5 liens « Lire la suite de l’article ». Comment différencier ces liens ? Nous pouvons le voir mais ce n’est pas le cas des utilisateurs de lecteurs d’écran. Avec l’information supplémentaire dans l’aria-label, on donne une meilleure visibilité et permet de différencier tous les liens sur une même page.

Labels

access9

Pour tout formulaire, chaque input doit être accompagné d’un label. En ASP.NET MVC, on se retrouve souvent avec les attributs Razor Html.LabelFor() et @Html.TextboxFor()


<div class="form-group">
    @Html.LabelFor(m => m.Libelle)
    @Html.TextBoxFor(m => m.Libelle, new { @class = "form-control"})        
</div>

Qui va se transformer ainsi sur la page HTML :


<div class="form-group">
   <label for="Libelle">Titre</label>
   <input class="form-control" id="Libelle" name="Libelle" type="text" value="">
</div>

Mine de rien, le titre du label associé à l’input grâce à l’attribut for aide énormément à l’identification pour le lecteur d’écran. Imaginez un formulaire avec 3 champs textes à saisir, comment les identifier ? Avec le label associé à chaque champ, on va pouvoir les différencier de manière claire. L’attribut for doit comporter l’id du champ pour que le label soit bien lié au champ.

access10

Donc j’ai deux solutions pour ma page :

La première solution pour l’input text de Recherche, je vais donc ajouter un label et le masquer aux yeux des utilisateurs mais qui sera visible pour le lecteur d’écran. Oui c’est possible !

<label for="Libelle" class="invisible">Mot à rechercher</label>
<input type="text" class="form-control" id="Libelle" name="Libelle" placeholder="Entrer un mot">

Avec la classe invisible que j’ai créée, je vais masquer le label « Mot à rechercher »

.invisible {
    left: -99999px;
    position: absolute;
    overflow: hidden;
}

Par défaut, on a tendance à mettre display:none mais cette valeur empêche la lecture d’écran.

Avec display :none, le label disparaît hors de l’écran et hors du lecteur d’écran. Donc avec ma classe invisible, je rends le label accessible pour le lecteur d’écran et cela reste invisible pour nos yeux. Ingénieux, n’est-ce pas ?

La deuxième solution pour le bouton. Il me suffit d’ajouter l’attribut aria-label pour expliquer la fonction de mon bouton.

<button aria-label="Bouton rechercher" type="submit" id="btnRecherche" class="btn btn-default" />

Grâce à ces deux astuces, j’améliore l’accessibilité de mes inputs facilement !

Images

access11Concernant les images, j’ai remarqué que beaucoup trouvent inutile de mettre l’attribut alt dans la balise « img ». Or, il a une grande utilité. Sans le savoir l’attribut alt facilite grandement l’accessibilité.

Grâce à l’attribut alt, on peut décrire le contenu de l’image. Sur ce cas précis, je vais décrire que cette image représente un coucher de soleil ! Ainsi le lecteur d’écran va informer l’utilisateur que l’image présente est un joli coucher de soleil ! J

<img src="/images/coucher-de-soleil.jpg" alt="coucher de soleil" />

Par contre, si votre image est purement décorative, comme le suggère tota11y, vous pouvez seulement donner un rôle à à la balise img.

access12

<img src="/images/coucher-de-soleil.jpg" role="presentation" />

L’outil tota11y va le valider en mettant une alerte : « this image is decorative »

Conclusion

En résolvant les erreurs grâce à Tota11y, cela permet d’améliorer l’accessibilité de votre site et ce n’est qu’un pas.

A part Tota11y, il existe d’autres solutions pour tester l’accessibilité de votre site. Parmi elles, il y a Accessibility Developer Tools, un plugin de Chrome (EN) pour développeurs, que je n’ai pas encore testé, afin de repérer les erreurs.

Vous pouvez étudier les règles du WCAG et WAI-ARIA pour rendre totalement accessible votre site.

Consultez votre site en utilisant un lecteur d’écran (NVDA, VoiceOver, TalkBack pour en citer parmi d’autres) pour vous mettre dans la peau d’un utilisateur aveugle ou malvoyant afin de déterminer si votre site est clair et accessible.

Essayez également de naviguer sans votre souris et seulement avec votre clavier. Vous verrez que ce n’est pas facile d’aller sur internet quand votre contenu n’est pas accessible.

Selon l’étude BrailleNet, on estime que seulement 4% des sites internet publics français sont accessibles. Et si, vous aussi, vous sautiez le pas pour rendre accessible votre site à tous ?

Documentations :

4 réflexions sur “Comment débuter dans l’accessibilité numérique ?

  1. Olivier Nourry

    Hello,
    Merci pour l'article! Je suis sûr qu'il va aider bon nombre de gens qui ne savent pas par quoi commencer.
    Dans la même veine que Tota11y, il existe des feuilles de style dédiées au diagnostic de code, notamment pour l'accessibilité. Un bon exemple est a11y.css, l'oeuvre de Gaël Poupard (alias @ffoodd_fr): http://ffoodd.github.io/a11y.css/. Dans son repo Github, Gaël fournit une liste complète de ressources similaires.
    L'avantage est que c'est facile à transformer en bookmarklet ou feuille de style utilisateur, du coup plus besoin de toucher au code.
    Petite précision: pour les images de déco, même si la spec HTML5 autorise (sous certaines conditions) d'omettre alt, il est recommandé de conserver un alt="", qui a pour effet d'indiquer au navigateur qu'il s'agit d'une image à ignorer dans le flow. L'attribut role peut en effet ne pas être correctement supporté dans certaines config anciennes.

    J'aime

  2. Regis Lapeze

    Bonjour,

    C'est un article très intéressant. J'utilise déjà Totally depuis quelques temps et je trouve cette outil très utile pour pallier aux défauts de la Web developper Tools bar de Chrome. Surtout pour la hiérarchie de titre.

    J'utilise également l'outil Tanaguru (www.tanaguru.com) pour me faire une première idée de l'accessibilité d'une page. Cela me permet également de lister les éléments en erreurs.

    J'utilise également Tanaguru Contrast-Finder (http://contrast-finder.tanaguru.com/) pour trouver des couleurs suffisamment contrastées.

    Enfin je test ma page avec NVDA pour déceler les derniers écueils restants.

    J'aime

  3. Emmanuelle

    Bonjour Olivier,
    Merci beaucoup pour tes remarques. Je ne connaissais pas du tout a11y.css, je testerais à l'occasion.
    C'est super intéressant, il y a pleins de possibilités et d'outils qui font qu'on peut réaliser facilement un site web accessible.
    Pour l'attribut alt, je pensais qu'il était déconseillée de laisser l'attribut vide. Maintenant je saurais que c'est possible.

    J'aime

  4. Emmanuelle

    Bonjour Régis,

    Merci pour ton commentaire très instructif. Je ne connaissais pas l'outil Tanaguru et Contrast-Finder, je testerais surement à l'occasion.

    J'ai également utilisé NVDA avec la visionneuse de paroles (tout ce qui est dit oralement est retranscrit à l'écran, pratique pour les personnes sourdes et malentendantes comme moi).
    NVDA est vraiment utile pour se rendre compte si les éléments renvoient bien ou non les bonnes informations.

    J'aime

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s