---
title: Accessibilite web et bonnes pratiques
tags: support, accessibility, good practice
robots: noindex, nofollow
author: Giuseppe Militello
---
# Accessibilité web & bonnes pratiques
*L’accessibilité : quoi et pourquoi ?*
> © [Giuseppe Militello](https://www.linkedin.com/in/giuseppe-militello-22406ab0/) - All rights reserved for educational purposes only
---
## Introduction
Un site, une application web sont consultable par tous. Cela s’applique également pour les handicapés (visuel, moteur, auditif ou dyslexique) ou quelqu’un a du mal à s’habituer à la nouvelle technologie qu’est internet (personnes âgées, parents ou simple débutant du web).
Dans mon expérience professionnel il m’est arrivé souvent de poser cette question avant une analyse complète du site web. La plus part du temps le client répondait : « je l’espère… » mais il ne savait pas à quoi cela consistait, rendre un site accessible à tous publics même hors-ligne. La seule chose qui me venait à l’esprit c’était de lui dire : imaginez de regarder un film étranger sans dispositif de sous-titre ni doublage, comprendriez vous l’intrigue?
Les règles de l’accessibilité visuel et web à l’information ce n’est pas une tendance actuelle, cela date déjà d’une vingtaine d’année à l’époque où on commençait à en comprendre les enjeux.
De ce constat le W3C a réagit et mis en place des règles de conceptions stricte pour la réalisation des sites web, il leur restait seulement à semsibiliser les professionnels à se former aux nouvelles normes. Ci-dessous les points importants
* Définitions de l’accessibilité pour tous
* Handicaps et accessibilité
* Mode de navigation logiciel et outils
* Démonstration pratique
## Normes et recommandations
* W3c, WAI, WCAG et [RGAA](https://www.numerique.gouv.fr/publications/rgaa-accessibilite/) (Référentiel général d'amélioration de l'accessibilité)
* Importance des contenus alternatifs
* Hiérarchie des informations
* Structure sémantique des pages
## Évaluation de l’accessibilité : méthode & outils
* Analyse, logiciels et outils
* Evaluation par l’analyse pas à pas
* Impact organisationnel, design et technique
* Exercice pratique
## Exploration des WCAG
* Comment ceux atteints d’une déficience visuelle perçoivent nos pages
* Niveaux de conformité de A, AA et AAA
* Exercice pratique
## Outils d’audit
* Installation du logiciel dédié aux non-voyants NVDA : [Voir le site](https://www.nvda-fr.org/)
* Vérification ou installation de LightHouse sur Chrome et FireFox
* Extension outils pour les navigateurs : Accessibility monitor, Color contrast analyzer et [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) accessibility audit
## Dans les grandes lignes
Toutes ces personnes ont elle aussi besoin d’accéder aux services web et doivent pouvoir avoir accès à toutes les parties de votre site y compris les formulaires.
Pensez aux applications importante comme: Doctolib, la Caf et tout ce qui concerne l'information de façon générale.
Le niveau du label e-accessible, certifie le niveau d'accessibilité Rgaa pour les personnes en situation de handicap. L'Espace Mon Compte du caf.fr est totalement conforme.
## Mise en place d'une structure sémantique
Une des solutions techniques réfléchis pour le web sont : UX (User experience) pour les applications web et la sémantique pour la structuration des pages web.
Le HTML5 a été officialisé depuis 2014 pour donner plus de sens aux contenus web et ce dans le but d’aider à développer des dispositifs spéciaux pour les handicapés et les rendre plus efficaces pour la navigation sans clavier ni souris.
Le HTML5 comporte bon nombre d'éléments possédant un sens sémantique fort, mais il n'est pas facile de savoir quand les utiliser, par exemple pour afficher les articles ou les commentaires dans un blog. Quand faut-il utiliser la balise ```<nav>``` ? La balise ```<aside>``` ? Plutôt ```<div>``` ou ```<section>``` ? Et pourquoi pas ```<header>``` pour les en-têtes des articles ?
Avant de commencer, un petit rappel sur la structure minimale d'une page en HTML 5 s'impose :
```htmlembedded=
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>The Grid in html and css</title>
<link rel="icon" type="image/png" href="./asset/logo.png">
<link rel="stylesheet" href="./css/grid.css">
</head>
<body>
<header>
<h1>The grid in html & css</h1>
</header>
<main>
<!--content -->
</main>
<footer>
<!--info for this page -->
</footer>
</body>
</html>
```
## 😁 Mais pour les sites où le contenu est dynamique?
```htmlembedded=
<%- include("header"); %>
<body>
<header>
<h1>The grid in html & css</h1>
</header>
<main>
<section>
<p>
<%= message %>.
This is my app
</p>
<ul>
<% tab.forEach((index)=> { %>
<li>
<strong><%= index.nom %></strong> :
<em><%= index.annee %></em>
</li>
<% }); %>
</ul>
</section>
</main>
<footer>
<p>
©<%= copy %>
</p>
</footer>
<script src="./assets/js/app.js"></script>
</body>
</html>
```
Cela ne change rien aux bonnes pratiques, il suffit de les appliquer
* ```<header>``` va englober tout ce qui se trouve dans l'en-tête de la page visible, à savoir la bannière, une éventuelle barre de menu, un logo
* ```<main>``` va correspondre au corps de la page, c'est-à-dire l'endroit où se trouvera le contenu principale
* ```<footer>``` va englober les informations du pied de page : copyright, liens de contact, mentions obligatoires
Dans la version xHtml pour englober tous les contenants de la page on avait l’habitude d’utiliser une balise ```<div>``` dite « balise générique » qui contenait un id souvent nommé « wrapper ». Cela avait un sens semi sémantique car de sémantique il n’y avait que le contenu de l’id. Le W3C a eu la brillante idée de créer une balise fortement sémantique pour envelopper tous les contenants de la page : la balise ```<main>``` (balise principale). Cela permet aux moteurs de recherche d’accéder directement aux contenus de la page sans faire des analyses supplémentaire dans la phase d’indexation.
Afin d’enrichir ce côté sémantique le W3C crée d’autres balises enveloppante pouvant annuler la généralité des balises ```<div>```.
La balise ```<section>``` a été créée à ce propos. Les éléments de section peuvent donc être utilisés dans le but de hiérarchiser une page. Voici un exemple correct d'une telle utilisation :
```htmlembedded=
<main>
<section>
<h2>
#section title level 2
</h2>
<p>
#content
</p>
</section>
</main>
```
# 😏Y a-t-il une raison de mettre une entête dans une section?
Cela est fortement recommandé par W3C car en absence d'entête le validateur signalera un warning.
De la même manière il y a d'autres règles qui peuvent s'appliquer pour d'autres balise.
Par exemple la balises ```<aside> ```. Cette balise a pour vocation d'afficher un contenu complémentaire donc à ne pas placer à l'interieur de la balise ```<main>``` qui affiche essentiellement le contenu principale.
# 😇Sémantique vs générique 😈
On m'a souvent demandé : *si je place des éléments div dans ma page que se passe-t-il*?
Souvent je répond qu'il faut voir ce que les navigateur affichent comme résultat.
Exemple de structure générique:
```htmlembedded=
<body>
<div class="header">
<h1>Les roles & ARIA</h1>
</div>
<div class="article">
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Odit mollitia hic natus maxime provident alias maiores eum voluptate rem. Ad enim, nemo magni ipsum autem exercitationem! Quod debitis, suscipit architecto.
<dfn>html</dfn>
</p>
</div>
<div class="presentation">
<h2>La sémantique web</h2>
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Enim quae, eaque delectus.
</p>
</div>
<div class="footer">
<p><abbr title="Web Accessibility Initiative">WAI</abbr></p>
</div>
</body>
```
**Réponse du navigateur dans l'inspecteur:**
**Inversement quand le navigateur détecte une accessibilité des éléments:**
# La norme ARIA «Accessible Rich Internet Applications »
Vous avez peut-être déjà aperçu des attributs « role » dans certains codes HTML, notamment ceux issus de WordPress. Ces attributs font partie d'une spécification du W3C : WAI-ARIA. Cette norme, couramment appelée ARIA, a été introduite pour pallier le manque d'accessibilité des applications Internet et plus particulièrement des widgets.
On entend par widget des morceaux de code HTML et Javascript servant à créer des éléments de contrôle, comme des barres de progression, des sélecteurs de couleurs, des fausses cases à cocher avec un état "semi-coché" et d'autres choses impossibles via les éléments HTML classique. ARIA date d'avant l'avènement d'HTML5. Alors qu'HTML5 se veut plus accessible, plus sémantique, autant en profiter pour introduire ARIA, une norme peu utilisée et méconnue, mais pourtant implémentée au sein des outils d'aide à la lecture pour les personnes non voyantes. ARIA n'est donc pas quelque chose qui va être utile pour les navigateurs, mais bien par les outils d'assistance à la lecture comme les lecteurs d'écran à synthèse vocale.
La norme ARIA introduit l'attribut role, qui peut s'utiliser au sein des éléments HTML. Le but de cet attribut est d'indiquer quel est le rôle de l'élément en question. À cela s'ajoute un grand nombre d'attributs dont le nom commence par **aria-** . Le plus connu est certainement **aria-required** qui est une manière d'indiquer qu'un champ de formulaire doit être remplis.
Mais, en HTML 5, les champs possèdent déjà un attribut required. Pourquoi utiliser **aria-required** ?
Parce que leur utilité n'est pas la même. Required sera reconnue par le navigateur, et ce dernier empêchera l'utilisateur d'envoyer le formulaire tant que le champ n'est pas rempli. **aria-required** va indiquer à la synthèse vocale que l'élément doit être renseigné. En quelque sorte, c'est l'équivalent pour les non-voyants du petit astérisque que l'on place pour indiquer que le champ ne peut être omis.
Exemple sur le code:
```htmlembedded=
<figure role="group" aria-label="Superman au coucher de soleil [Description]">
<img src="51606704.jpg" alt="Superman au coucher de soleil">
<figcaption>
<h3>Description</h3>
<p>Plus vite que la lumière et au delà</p>
</figcaption>
</figure>
<address>
<ul aria-labelledby="ville">
<li id="ville">Paris</li>
<li>14 rue du repos</li>
<li>75020</li>
<li>
<a href="mailto:addresse@gmail.com">Nous contacter »</a>
</li>
</ul>
</address>
</figure>
```
# Les valeurs de l'attribut role
L'attribut role possède un certain nombre de valeurs prédéfinies classées en catégories. Deux catégories vont nous intéresser : Document Structure et [Landmark](https://https://www.w3.org/TR/wai-aria-practices/examples/landmarks/main.html, "landmarks") Roles. La première, Document Structure, recense les rôles utilisés pour décrire la structure du contenu de la page. On y trouve les rôles suivants:
* banner
* main
* region
* contentinfo
* goup
* heading
* article
* directory
* document
* img
* navigation
* search
* alert
* complementary
* definition
* figure
* dialog
* form
Attention les attributs "role" peuvent être utilisés de deux façon: soit dans une balise parent sémantique mais pas systématiquement, soit dans une balise généric exemple;
```htmlembedded=
<figure role="group" aria-label="Superman au coucher de soleil">
<img src="51606704.jpg" alt="Superman">
<figcaption>
<h3>Description</h3>
<p>Plus vite que la lumière et au delà</p>
</figcaption>
</figure>
<!-- exemple sémantique -->
```
## Exemple générique
```htmlembedded=
<div role="banner">
<h1>page title identifying website<h1>
.... banner content....
</div>
```
Dans le navigateur la balise div qui contient le role "banner", sera considérée comme un landmark
Nous allons donc ajouter des attributs role là où il en faut. Le premier élément qui peut posséder un role est <body> : on va en profiter pour dire qu'il s'agit d'un document et non d'une application : <body role="document">.
Dans le cas où vous avez une balise ```<main>``` il n'est pas conseillé d'ajouter un role de la même valeur, cela sera considéré comme une erreur W3C : <del>```<main role="main">```</del>`
# </> La balise article
Chaque article sera contenu dans un élément ```<article>```, lequel peut contenir un ```<h2>``` et un ```<p>```. Aucun attribut role est nécessaire pour donner du sens au contexte, il s'agit bien d'un article.
```htmlembedded=
<article>
<h2>La face caché de la toile</h2>
<time datetime="2003-01-19">Edité le : 19 janvier 2003</time>
<p>
Lorem ipsum, dolor sit amet consectetur
adipisicing elit. Dicta, beatae?
</p>
</article>
```
L’entête contient le titre de l'article ainsi que les informations de publication comme la date. Ces informations temporelles se placent par le biais d'un élément sémantique ```<time>```. En SEO par exemple est très important diffuser des informations avec une notion temporelle et géographique, ces balises sémantiques le font très bien. C'est dans ce cas que le sens des balises vient renforcer le référencement naturel des pages web
# Les microdonnées
Depuis toujours, les développeurs ont cherché à donner du sens aux éléments HTML pour en faciliter la lecture par les robots de référencement ou des scripts de conversion et d'analyse. A l'époque, ça se faisait avec les moyens du bord : l'attribut class. Plusieurs spécifications de microformats existent, en fonction de leur utilité. Par exemple, la spécification geo permet d'indiquer des latitudes et des longitudes. **hCalendar**, de sont côté, rassemble des classes pour définir un calendrier.
Vous avez peut-être même déjà croisé la spécification **hAtom** sans le savoir, notamment au sein du célèbre CMS WordPress. Cette spécification définit des classes pour la publication. On y retrouve des classes comme **hentry**, **entry-title**, **entry-summary**, **author**, **bookmark...**
Jouer avec des noms de classes n'est pas l'idéal, car ce n'est pas fait pour ça.
# Compliquons tout : RDFa
(Resource Description Framework dans des Attributs)
La norme RDFa est un standard du W3C qui permet de décrire n'importe quelle donnée présente dans une page Web (XHTML) ou un document XML. Il "suffit" de créer un document RDF qui décrit l'utilisation des données, puis d'utiliser les nouveaux attributs property et content pour identifier les données.
Comme ça nécessite d'utiliser des espaces de nom (c'est compatible XML), du RDF ainsi qu'XHTML1.1, autant dire que ça n'a pas conquis grand monde.
Voici à quoi ressemble un fichier RDF :
```RDFa
@prefix dbp: <http://dbpedia.org/property/> .
@prefix dbr: <http://dbpedia.org/resource/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
dbr:Albert_Einstein dbp:dateOfBirth "1879-03-14"^^xsd:date .
dbr:Albert_Einstein
foaf:depiction <http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg> .
```
# Fraîcheur avec HTML 5 : Microdata <small>(Décrivez vos contenus !)</small>
1. itemscope : crée un nouvel item
2. itemtype : spécifie l'URL contenant le vocabulaire utilisé au sein de l'item
3. itemid : définit un identifiant unique pour l'item
4. itemprop : indique la nature du contenu
5. itemref : permet de créer une référence, c'est-à-dire lier un item avec un autre, qui fournirait
Ça peut paraître compliqué, mais c'est en fait assez simple. Supposons que l'on veuille donner du sens à cette adresse :
```htmlembedded=
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>schema.org</title>
</head>
<body>
<main>
<h2>Mon adresse : </h2>
<address>
<span>Boulevard des Caloducs, 42</span><br/>
<span>1337</span><br/>
<span>Pentium-sur-Meuse</span><br/>
<span>Belgique</span>
</address>
</main>
```
## Optimisation du code
```htmlembedded=
<address itemscope itemtype="https://schema.org/PostalAddress">
<ul>
<li itemprop="streetAddress">Boulevard des Caloducs, 42</li>
<li itemprop="postalCode">1337</li>
<li itemprop="addressLocality">Pentium-sur-Meuse</li>
<li itemprop="addressCountry">Belgique</li>
</ul>
</address>
```
Sign in with Wallet
Connect another wallet