Jouve : Le Livre blanc de l'accessibilite (2014)

© Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 1/32
Livre blanc
Accessibilité numérique
Estelle RENAUD

Jouve
A propos du groupe
Le Groupe Jouve conçoit, enrichit, valorise et diffuse les contenus sur tous les médias. A la pointe des
technologies et expert des nouveaux usages, Jouve renforce l’agilité et la compétitivité de ses clients
dans l’ère du numérique.
Son offre de services est unique : conseil, conception et valorisation de contenus enrichis et
multimédia, leader de la production de livres numériques, dématérialisation des flux documentaires,
IT Solutions, externalisation sécurisée des processus métiers, diffusion multicanale et optimisation des
chaînes d’approvisionnement des imprimés. Acteur international, le Groupe Jouve compte 19 sites
dans le monde dont 9 en France et emploie 2500 personnes.
Des métiers en synergie
Valoriser les contenus numériques des entreprises et dynamiser leur diffusion
 Jouve ITS (Conseil/AMOA, Tests utilisateurs, Responsive Design, Web & Mobilité,
Infogérance) valorise les contenus numériques de ses clients. Sa maîtrise des nouveaux
usages en mobilité et ses solutions créatrices de valeur dynamisent votre diffusion
cross canal.
Renforcer la compétitivité des entreprises
 Spécialiste du BPO, Jouve renforce la compétitivité de ses clients grâce à ses solutions
de dématérialisation des flux documentaires et d’externalisation sécurisée des
processus métiers.
Capitaliser sur tous les formats de l’ère numérique
 Prestataire de services éditoriaux devenu le leader mondial de la production de livres
numériques, Jouve conçoit, valorise et diffuse des contenus adaptés à tous les
supports papier et numérique.
Optimiser les chaînes d’approvisionnement des imprimés
 Imprimeur centenaire et leader de l’optimisation des chaînes d’approvisionnement,
Jouve propose des solutions d’impression innovantes pour renforcer la compétitivité de
ses clients.

Table des matières
Jouve.......................................................................................................2
Table des matières ...................................................................................3
Introduction.............................................................................................5
1 L’accessibilité, pourquoi ? ..................................................................6
1.1 Enjeux .................................................................................................... 6
1.2 Bénéfices ................................................................................................ 6
1.3 Accessibilité, Design, Ergonomie… Quid des idées reçues ? ....................... 6
1.3.1 Responsive Web Design .......................................................................... 6
1.3.2 Design et accessible ?............................................................................. 7
2 Comprendre les référentiels et les niveaux ..........................................8
2.1 Recommandations de la WAI (W3C) : WCAG, ATAG, ARIA ........................... 8
2.2 Technologies d’assistance........................................................................ 8
2.3 AccessiWeb ............................................................................................. 9
2.3.1 Le référentiel .......................................................................................... 9
2.3.2 La labellisation........................................................................................ 9
2.4 RGAA.................................................................................................... 10
2.4.1 Le référentiel ........................................................................................ 10
2.4.2 L’attestation de conformité................................................................... 10
3 Votre site Web est-il accessible ? Comment l’auditer ?........................12
3.1 Choix du référentiel et du niveau ........................................................... 12
3.2 Echantillonnage..................................................................................... 12
3.3 Tests automatisables ............................................................................. 13
3.4 Tests manuels ....................................................................................... 14
3.4.1 Outils d’aide à l’évaluation ................................................................... 14
3.4.2 Compatibilité avec les technologies d’assistance.................................. 14
3.5 Rapport d’audit ..................................................................................... 15
3.5.1 Vue synthétique.................................................................................... 15
3.5.2 Vue détaillée......................................................................................... 16
4 Refonte de site Web, comment s’y prendre ? ......................................17
4.1 Cahier des charges ................................................................................ 17
4.2 Conception ........................................................................................... 17
4.2.1 Ergonomes............................................................................................ 17
4.2.2 Directeurs artistiques et infographistes................................................ 18
4.3 Maquettage HTML.................................................................................. 18
4.4 Spécifications, développements et recette............................................... 18
4.5 Intégration de contenus et mise en ligne ................................................ 19

5 Comment maintenir l’accessibilité de votre site Web ? ........................20
5.1 Texte .................................................................................................... 20
5.2 Hyperliens............................................................................................. 20
5.3 Images.................................................................................................. 21
5.4 Tableaux de données............................................................................. 21
5.5 Documents PDF..................................................................................... 21
5.6 Vidéos .................................................................................................. 22
5.6.1 Recommandations de niveau A............................................................. 22
5.6.2 Recommandations de niveau AAA ........................................................ 22
6 Vos sites et applications mobiles sont-ils accessibles sur smartphones
et tablettes ? ..........................................................................................24
6.1 Comment naviguer sur un smartphone en étant non-voyant ? ................. 24
6.2 Accessibilité des mobiles ....................................................................... 24
6.3 Bientôt… des référentiels d’accessibilité pour les applications mobiles..... 25
7 Autres initiatives en faveur du handicap ............................................26
7.1 Vocalisation des contenus...................................................................... 26
7.2 Personnalisation de l’affichage ............................................................... 26
7.3 Navigation en langage des signes........................................................... 27
8 Conclusion......................................................................................28
Liens utiles ............................................................................................29
Index des acronymes ..............................................................................31
A propos de l’accessibilité de ce document ..............................................32

Introduction
Un site Web accessible est un site qui pourra être consulté par un maximum de personnes, y compris
les personnes handicapées équipées de dispositifs techniques spécifiques dites « technologies
d’assistance ». En augmentant leur autonomie sur le Web, l’accessibilité est un facteur d’intégration
sociale, professionnelle et culturelle. En France plus de 4 millions de personnes sont touchées par le
handicap, et près de 40 millions en Europe.
Les premières initiatives en faveur de l’accessibilité du Web ont été amorcées en 1996 avec la création
de la WAI1, par le W3C2. Tim Berners-Lee, directeur du W3C, définit l’accessibilité du Web de la façon
suivante :
« Mettre le Web et ses services à la disposition de tous les individus, quels que soient leur matériel ou
logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique,
ou leurs aptitudes physiques ou mentales. »
Tous les concepteurs de sites, savent que cette phrase interprétée au sens le plus strict, est très
ambitieuse. Pour répondre au mieux à cette problématique, le W3C diffuse des recommandations qui
permettent de rendre les sites Web accessibles à un maximum d’utilisateurs, et ce en considérant trois
niveaux d’accessibilité : A, AA et AAA.
Les recommandations du W3C sont reconnues au niveau international, sans pour autant être imposées
par la loi. Chaque pays dispose d’une législation qui lui est propre, avec généralement des distinctions
entre les obligations du service public et celles des sociétés privées. Il existe également des labels de
qualité permettant aux éditeurs de sites Web de justifier auprès de leurs internautes d’un niveau
d’accessibilité reconnu.
Après avoir rappelé les enjeux et bénéfices de l’accessibilité, nous dresserons dans le second chapitre
un tour d’horizon des référentiels, labels… dont la multitude d’acronymes rend la compréhension
complexe. L’objet des chapitres suivants sera de vous donner les clés pour améliorer l’accessibilité de
vos sites Web et applications mobiles. Votre site Web est-il accessible ? Comment l’auditer ? Comment
mener à bien un projet de création ou de refonte de site Web Accessible ? Comment maintenir votre
site Web accessible après la mise en ligne ? Quelles sont les recommandations à suivre pour
l’accessibilité des applications mobiles ? Enfin, nous conclurons avec des initiatives complémentaires
aux normes mises en place.
1 WAI - Web Accessibility Initiative
2 W3C - World Wide Web Consortium

1 L’accessibilité, pourquoi ?
L’objet de ce premier chapitre est de rappeler les enjeux de l’accessibilité en France et au niveau
international et l’ensemble de ses bénéfices sociaux, financiers et techniques.
1.1 Enjeux
En France, l’enjeu principal est de respecter la loi n° 2005-102 du 11 février 2005 pour l'égalité des
droits et des chances, la participation et la citoyenneté des personnes handicapées. Cette loi impose :
 Pour le secteur public, de rendre accessible l’ensemble de ses contenus et services en
ligne : Internet et Intranet inclus, en respectant le RGAA (équivalent niveau AA des
WCAG/W3C)
 Pour le secteur privé, de rendre accessible tous les contenus et services liés au
recrutement (Contact, Offres d’emplois) en respectant a minima le niveau A des
WCAG/W3C
A l’étranger, la loi varie d’un pays à l’autre, mais la recommandation est souvent de répondre au
niveau AA des WCAG/W3C, et a minima au niveau A.
1.2 Bénéfices
Les bénéfices de l’accessibilité sont nombreux et il serait restrictif de penser que l’accessibilité ne
s’adresse qu’au public handicapé. Ainsi, grâce à l’accessibilité, on pourra :
 Augmenter le nombre potentiel d'utilisateurs
 Respecter le cadre légal
 Etre dans une démarche citoyenne et véhiculer une meilleure image
 Etre mieux référencé par les moteurs de recherche
 Favoriser la consultation multi support (ordinateurs, tablettes, mobiles…)
 Faciliter la maintenance de votre site (code réutilisable, optimisation des processus)
 Optimiser la taille des pages (diminution du temps de chargement, économie de coûts
d’hébergement)
1.3 Accessibilité, Design, Ergonomie… Quid des
idées reçues ?
1.3.1 Responsive Web Design
RWD3 et accessibilité, est-ce compatible ?
Oui, techniquement rien n’empêche de faire un site Web RWD et accessible. De plus, les deux
convergent vers un site plus ergonomique et utilisable en toutes circonstances. En effet, alors que
3 RWD – Responsive Web Design

l’accessibilité tend à rendre les contenus accessibles à un maximum d’utilisateurs, le RWD tend à en
faciliter la consultation quelle que soit la taille de l’écran.
Et pourtant cette question est souvent abordée car grâce au RWD, on peut adapter la mise en avant des
contenus à des situations de mobilité. Par exemple, dans le cadre d’une mission d’assistance à maîtrise
d’ouvrage pour le Ministère de la Défense, les équipes de Jouve ont pris le parti de mettre en avant les
contenus destinés aux jeunes sur la version mobile. Les autres contenus ont également été rendus
accessibles sur la version mobile à travers d’autres scénarios de navigation.
1.3.2 Design et accessible ?
La même question se pose pour le design … Oui, un site Web accessible pourra être ‘beau’. Une seule
contrainte pour les graphistes en accessibilité : les textes doivent être lisibles. Qu’est ce qu’un texte
lisible ? C’est un texte utilisant une fonte lisible, une taille suffisante, et une couleur suffisamment
contrastée avec la couleur de fond. Pour cela, il y a des standards à respecter en terme de fonte et des
outils permettant de vérifier les contrastes. Mais en aucun cas ce critère n’aura un impact négatif sur le
design du site.
Depuis décembre 2013, un nouvel outil destiné aux graphistes a vocation à donner des idées de
couleurs aux contrastes accessibles : Tanaguru Contrast-Finder 0.1
Figure 1 - Vue Mobile Figure 2 - Vue Desktop

2 Comprendre les référentiels et les
niveaux
Comprendre les codes de l’accessibilité n’est pas simple : WAI, WCAG, RGAA4, A, AA, AAA… la liste de
sigles ou acronymes est longue. Ce chapitre a pour vocation de présenter les bases et concepts clés de
l’accessibilité.
2.1 Recommandations de la WAI (W3C) : WCAG,
ATAG, ARIA
Le W3C qui travaille sur les standards présents sur le Web a crée en 1996 la WAI. La WAI est un
organisme diffusant différents types de recommandations, largement répandues et reconnues par la
communauté internationale. Parmi ces recommandations, les principales destinées aux concepteurs de
sites Web sont les suivantes :
 WCAG5 2.0 : une recommandation pour améliorer l’accessibilité des contenus Web. La
version 2.0 des WCAG est la version de référence depuis décembre 2008.
 ATAG6 2.0 : une recommandation pour améliorer les outils de création de sites Web
(éditeurs HTML WYSIWYG) tels que Dreamweaver®, TinyMCE®, CKeditor®… ; et les
outils de gestion de contenus (également appelé CMS) tels que Drupal®, eZpublish®,
Typo3®, Wordpress®… La version 2.0 des ATAG est la version de référence depuis
novembre 2013.
 UAAG 2.0 : une recommandation pour l'accessibilité des navigateurs, lecteurs
multimédia, applications Web et technologies d'assistance. A noter que la version 2.0
des UAAG est une version non encore stabilisée en cours de relecture depuis
novembre 2013.
 ARIA : une spécification qui offre la possibilité de définir une description des rôles,
des états et des propriétés pour les widgets7 personnalisés, de manière à ce qu’ils
soient reconnaissables et utilisables par les utilisateurs de technologies d’assistance.
2.2 Technologies d’assistance
Les technologies d’assistance sont les outils d’assistance à la navigation pour les personnes
handicapées (lecteur d’écran, synthèse vocale). Le lecteur d’écran et la synthèse vocale sont deux outils
complémentaires qui permettent la restitution vocale des contenus. Le lecteur d’écran lit le contenu, et
la synthèse vocale le restitue vocalement.
4 RGAA - Référentiel Général d'Accessibilité pour les Administrations
5 WCAG - Web Content Accessibility Guidelines
6 ATAG - Authoring Tool Accessibility Guidelines
7 Widget - Assemblage d'HTML, de CSS et de Javascript, les widgets sont des applications utilisées pour
de petits outils permettant d'obtenir de l'information (exemple : widget météo).

Un lecteur d’écran transforme le texte affiché sur l’écran en un texte en braille lu via une tablette ou un
texte oral lu via une synthèse vocale.
Les principaux lecteurs d’écran utilisés sous Windows sont Jaws, NVDA et Window Eyes. Sous Mac,
Voice Over est un lecteur d’écran fourni comme élément intégral de Mac OS depuis sa version 10.4.
Source : WEB Accessibility In Mind
2.3 AccessiWeb
2.3.1 Le référentiel
AccessiWeb est un référentiel méthodologique d’application des WCAG créé par Braillenet8. Depuis
décembre 2013, deux référentiels Accessiweb cohabitent : "AccessiWeb HTML5/ARIA" pour les sites
Web en HTML5 et "AccessiWeb 2.2" pour les sites Web en HTML4. Les sites Web en HTML4 n’étant plus
d’actualité, nous n’irons pas plus loin dans la description du référentiel "AccessiWeb 2.2" qui va
progressivement devenir obsolète.
Le référentiel HTML5/ARIA, pour sa part, a encore le statut de « document de travail », il a été construit
sur la base de 3 spécifications HTML5, WCAG2.0 et ARIA. On notera que la terminologie des niveaux
Bronze / Argent/ Or a été abandonnée au profit des niveaux A / AA / AAA tel que les WCAG. Ce
référentiel est composé de thématiques, critères et tests : 133 critères répartis dans 13 thématiques.
Un certain nombre de tests sont associés à chaque critère. Au total, 330 tests sont à passer pour
atteindre le niveau AAA. La liste exhaustive est disponible en ligne : AccessiWeb HTML5/ARIA
Ce référentiel est particulièrement intéressant car bien documenté et animé par une communauté
d’experts francophone dynamique. Ci-dessous quelques éléments de documentation à ne pas
manquer :
 L'équivalence avec les critères du RGAA et des WCAG.
 Le glossaire
 La base de référence
 Les notes techniques
2.3.2 La labellisation
Dans une démarche de qualité, il est possible d’effectuer une demande de labellisation. Le label
AccessiWeb est une procédure contractuelle établie entre l’association Braillenet et un propriétaire de
site Web, permettant de vérifier et de communiquer qu'un site Web est conforme aux critères du
référentiel AccessiWeb.
Les labels de qualité en accessibilité du Web ont deux intérêts :
 Une marque de qualité visible et reconnue par des professionnels
8 Braillenet est une association française ayant pour but d'encourager l'accessibilité numérique,
notamment à destination des personnes handicapées visuelles.

 Un site sous contrôle, garantissant l’accessibilité sur le long terme
Un site peut respecter l’ensemble des critères du label sans pour autant être labellisé. La labellisation
nécessite une démarche auprès d’un organisme certifié. Certains pays ont développé des labels de
qualité, par exemple : ‘AccessiWeb’ en France ou ‘Anysurfer’ en Belgique. Chacun de ces labels repose
sur les WCAG du W3C, avec des variations sur quelques critères.
Au niveau européen, le label Euracert a été créé pour harmoniser les standards d'accessibilité du Web
et faciliter la reconnaissance de sites labellisés localement au sein des pays de l'Union. Le label
Euracert n'est pas un label d'accessibilité du Web de plus. Il est attribué à un site Web en complément
du label délivré par un organisme de labellisation de l'accessibilité du Web. Cet organisme doit être
habilité (tel que le sont AccessiWeb, Anysurfer et Techno site).
2.4 RGAA
2.4.1 Le référentiel
Le SGMAP9 diffuse un référentiel méthodologique d’application des WCAG, destiné aux
administrations : le RGAA. Le RGAA 2.2.1 est un référentiel d’application des WCAG quasi-équivalent
au référentiel AccessiWeb 2.2. Il distingue 3 niveaux de conformité : A / AA / AAA. Ce référentiel est
composé de thématiques, critères et tests : 61 critères répartis dans 12 thématiques. Un certain
nombre de tests sont associés à chaque critère. Au total, 187 tests sont à passer pour atteindre le
niveau AAA. La liste exhaustive est disponible en ligne sur le site du SGMAP.
Quant au guide d’accompagnement, c’est une lecture incontournable dans laquelle on retrouvera
quelques spécificités liées au RGAA :
 L’attestation de conformité est une attestation à produire et à mettre en ligne dans
une page dédiée (voir ci-dessous).
 La notion de dérogation permet aux administrations de déroger à l’accessibilité de
certaines parties de leurs sites Web dans le respect des règles énoncées dans le
chapitre 5.5 du guide.
A ce jour, on préférera utiliser le référentiel AccessiWeb qui a été adapté pour les sites en HTML5. Un
appel d’offres pour la mise à jour du RGAA est en cours en 2014.
2.4.2 L’attestation de conformité
Les administrations ont pour obligation de produire une attestation de conformité (voir chapitre 5.4 du
guide d’accompagnement du RGAA). L’attestation peut faire l’objet d’une page spécifique ou bien être
incluse dans une page d’aide, de politique d’accessibilité ou dans les mentions légales. Mais elle doit
être accessible depuis toutes les pages du site.
Ci-dessous un rappel des éléments à faire paraître dans cette page :
 adresse du site,
9 SGMAP – Secrétariat Général pour la Modernisation de l’Action Publique

 date de réalisation,
 version du RGAA de référence,
 nom et adresse email du déclarant,
 technologies utilisées sur le site,
 liste des agents utilisateurs et technologies d’assistance utilisées pour vérifier
l’accessibilité des contenus,
 liste des pages du site ayant fait l’objet de la vérification de conformité, avec au
minimum lorsqu’elles existent :
 Page d'accueil
 Page contact
 Page mentions légales
 Page politique d'accessibilité
 Page aide
 Page plan du site
 Page recherche
 Toutes les pages composant le processus d'un service en ligne
 Pages d'accès aux contenus ou fonctionnalités principales
 Pages représentatives des types de contenus disponibles sur le site
 Pages ayant le plus grand nombre de visiteurs
 résultat des tests : Indiquez le niveau d’accessibilité visé (A, AA préconisé, AAA).
Précisez par niveau d’accessibilité, le pourcentage de tests conformes, non conformes,
non applicables et le taux de conformité.
 justification des dérogations : Indiquez les éléments non accessibles et pour quelles
raisons. Précisez la démarche que vous souhaitez mettre en place pour améliorer
l’accessibilité de ces éléments.
 détection d’éventuels défauts d’accessibilité : proposez un ou plusieurs moyens de vous
contacter (adresse postale, téléphone, adresse électronique, formulaire…) en cas de
détection d’un défaut d’accessibilité non signalé dans l’attestation.
A titre d’exemples, on pourra consulter le site du Service Public ou le site de l’Elysée qui reprennent
correctement la structure de cette attestation.

3 Votre site Web est-il accessible ?
Comment l’auditer ?
L’idéal est de prendre en compte l’accessibilité en amont de la création d’un site. Mais si votre site Web
vient d’être refondu sans prendre en compte les problématiques d’accessibilité, il est conseillé de
réaliser un audit pour mesurer le niveau actuel et planifier des actions correctives.
3.1 Choix du référentiel et du niveau
La première étape est de choisir le référentiel à utiliser et de se fixer un objectif de niveau à atteindre.
Qu’il s’agisse d’un site du secteur public ou privé, il est possible d’utiliser le RGAA ou AccessiWeb.
Néanmoins, nous conseillerons plutôt d’opter pour le référentiel AccessiWeb puisqu’il donne les
équivalences avec le RGAA.
La recommandation du W3C et du RGAA est le niveau AA. Cependant, atteindre le niveau A est déjà un
gage de très grande qualité sur la toile.
3.2 Echantillonnage
Le choix des pages à auditer est important car il doit être représentatif du site visé et respecter le
cadre du RGAA lorsqu’il s’agit d’un site du service public. Cette étude préalable doit donc prendre en
compte les gabarits de page les plus fréquents et les pages les plus visitées.
La liste détaillée des pages à auditer est décrite dans le chapitre 5.4 du « Guide d'accompagnement du
RGAA »:
 Accueil du site ;
 Page de contact ;
 Mentions légales ;
 Page sur la politique d'accessibilité avec en particulier l’attestation d’accessibilité ;
 Page aide pour faciliter l’utilisation du site ;
Figure 3 - Etapes d'un audit d'accessibilité

 Plan du site ;
 Recherche et résultats de la recherche ;
 Toutes les pages composant le processus d'un service en ligne
 Pages d’accès aux contenus ou fonctionnalités principaux : cela correspond aux
gabarits récurrents comme les pages de rubrique ou les pages de liste ;
 Pages représentatives des types de contenus disponibles : il s’agit ici de vérifier la
bonne intégration de contenus dans le respect des règles d’accessibilité (tableaux,
illustration, formulaires…) ;
 Pages ayant le plus grand nombre de visiteurs : ces pages étant les plus demandées
par les internautes, il est important d’y attacher une attention particulière afin de les
rendre accessibles.
A noter que cette liste de pages à auditer est également une bonne base de travail pour les sites des
sociétés privées.
Après cette phase d’échantillonnage, la phase de tests repose sur deux étapes :
 Audit automatique avec un outil d’automatisation des tests,
 Audit manuel pour vérifier l’exhaustivité des critères
Nous détaillons ci-dessous les outils utilisés pour chacune de ces deux étapes.
3.3 Tests automatisables
L’audit automatique est une phase qui permet d’accélérer le processus et d’éviter les erreurs pour les
tests automatisables. Il existe de nombreux outils basés sur différents référentiels. Selon les
préférences ou habitudes de nos clients, nous utilisons l’un des outils suivants : Ocawa, Opquast,
Tanaguru ou Wave.
Ocawa Opquast Tanaguru Wave
Audit de pages ✓ ✓ ✓ ✓
Audit de sites ✓ ✓ ✓ —
Audit de fichiers et scénarios ✓ — ✓ —
WCAG 2.0 ✓ ✓ ✓ ✓
RGAA 2.3 ✓ ✓ ✓ —
AccessiWeb 2.2 (HTML4) — ✓ — —
AccessiWeb HTML5/ARIA — — — —
Offre Gratuit à
payant10
Gratuit à
payant
Gratuit et open
source
Gratuit
Tableau 1 - Comparatif des outils de tests automatisables réalisés par Jouve en 2013
10 Gratuit à payant en fonction du volume d’audits et installation serveur

Figure 4 – Exemple d’audit d’un site de 9753 pages avec Tanaguru
3.4 Tests manuels
En complément des tests automatisables, la phase de tests manuels est indispensable. L’objet de cette
phase est de réaliser les tests que les outils de tests automatiques n’ont pas pu réaliser et de statuer
sur les résultats des outils automatiques lorsque ces derniers émettent un doute.
3.4.1 Outils d’aide à l’évaluation
La liste des outils de tests est longue et variable en fonction des préférences des experts d’audits en
accessibilité. On pourra citer les principaux comme étant :
 Firebug,
 Web Developper Toolbar,
 Web Accessibility Toolbar,
 Color Contrast Analyser
3.4.2 Compatibilité avec les technologies d’assistance
Dans le cadre de ces tests, il faudra également vérifier que le site Web est compatible avec les
technologies d’assistance, c’est-à-dire qu’il est correctement restitué avec les lecteurs d’écran et
synthèses vocales. On pourra alors suivre la méthodologie proposée dans le référentiel AccessiWeb
HTML5/ARIA : lorsqu'un critère, un test ou une condition de test demande de vérifier la restitution d'un
dispositif il faut s'assurer que ladite restitution est compatible avec l'accessibilité.

Le test consiste à vérifier que la restitution est pertinente pour au moins une des combinaisons de la
base de référence11 utilisée pour déclarer qu'un élément, un dispositif ou une alternative est
"compatible avec l'accessibilité".
Par exemple : le test 1.3.7 du référentiel AccessiWeb HTML5/ARIA demande de vérifier que l'alternative
d'une image porteuse d'information vectorielle est correctement restituée. On procède alors à un test
avec les combinaisons suivantes :
 NVDA (dernière version) et Firefox,
 JAWS (version précédente) et IE9+
 Voice Over (dernière version) et Safari
Le test est validé si l'alternative est correctement restituée.
Source : http://www.accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-
html5aria.html#baseref
3.5 Rapport d’audit
Un rapport d’audit peut prendre des formes variables, généralement avec des schémas pour faciliter la
lecture des résultats et des propositions d’actions correctives dans la perspective d’améliorer le niveau
d’accessibilité du site Web. Les rapports d’audit Jouve se décomposent en 2 parties :
 Une vue synthétique qui liste les pages testées en indiquant le nombre de critères
valides et non valides. Elle présente le taux de qualité global.
 Une vue par thématique permet d’identifier éventuellement les types de lacunes.
3.5.1 Vue synthétique
Un tableau récapitulatif détaille pour chaque page auditée le nombre de critères valides, non valides et
non applicables. Un taux de qualité en est déduit.
De la même manière, un graphe illustre pour chaque thématique du référentiel les critères valides et
non valides.
Nom des pages
auditées
Critères validés
Critères non
validés
Critères non
applicables
Taux de qualité
(%)
Accueil 56 21 77 73%
Crédits 52 23 79 69%
Partenaires 54 19 81 74%
11 La base de référence est constituée des configurations (technologie d'assistance, système
d'exploitation, navigateur) qui permettent de déclarer qu'un dispositif HTML5/ARIA est "compatible
avec l'accessibilité" tel que définie par WCAG 2

Nom des pages
auditées
Critères validés
Critères non
validés
Critères non
applicables
Taux de qualité
(%)
Contact 55 19 80 74%
Mentions légales 52 21 81 71%
Plan du site 52 21 81 71%
Accessibilité 54 20 80 73%
Actualité 51 26 77 66%
Article Thème 51 46 57 53%
Tableau 2 – Exemple de tableau de synthèse listant la qualité des pages auditées
Figure 5 - Exemple de graphe de synthèse présentant les critères valides/non valides par thématique
3.5.2 Vue détaillée
Chaque page auditée fait l’objet d’un rapport détaillé évaluant chacun des critères associés au
référentiel et niveau choisi.
Le rapport réalisé reprend pour chaque page :
 L’url testée,
 La date du test,
 La liste des critères du référentiel et leur niveau,
 Le point à corriger pour les critères non conformes en détaillant notre
recommandation,
 Le type de correction pour orienter l’intervention vers un profil d’intervenant
(contributeur, graphiste, développeur),
 La difficulté de la correction.

4 Refonte de site Web, comment s’y
prendre ?
L’objet du présent chapitre est de montrer l’importance de chacun des acteurs d’un projet Web. Les
responsabilités sont partagées entre l’équipe de réalisation du site (du concepteur au développeur) et
l’équipe de contributeurs-rédacteurs.
4.1 Cahier des charges
L’idéal est de prendre en compte l’accessibilité dès la phase de rédaction du cahier des charges afin de
bien spécifier les besoins du projet. Le cahier des charges devra préciser : le choix du référentiel et le
niveau d’accessibilité attendu, le besoin d’assistance transverse tout au long du projet, les besoins de
formations et l’assistance à mise en ligne d’une attestation de conformité dans le cas des sites du
service public.
4.2 Conception
L’accessibilité doit être prise en compte dès la phase de conception d’un site Web, avec une
intervention des ergonomes et des graphistes.
4.2.1 Ergonomes
L’ergonome devra proposer un maximum d’aides à la navigation, dont voici quelques exemples : un
plan de site, une page d’aide, un moteur de recherche avec un mode d’emploi, un fil d’Ariane, une
page décrivant l’accessibilité du site. Ces éléments ne sont pas tous obligatoires selon le niveau
d’accessibilité souhaité.
L’ergonome devra également s’assurer de la stabilité du positionnement des contenus d’une page à
l’autre. Par exemple, un même menu de navigation ne devra pas changer de place d’une page à l’autre.
Pour les formulaires, chaque intitulé de champ devra être placé à coté de son champ associé.
Figure 6 - Etapes de création d'un site Web

Enfin, pour les fichiers en téléchargement, des informations relatives à leur consultation doivent être
présentes. Par exemple, on indiquera « Rapport d’avancement 2014 (PDF, 345 ko) » plutôt que «
Rapport d’avancement 2014 ». Dans cet exemple, un lien complémentaire permettant de télécharger le
plugin Acrobat Reader devra être présent sur la page. Cela permet aux utilisateurs ne disposant pas de
ce logiciel, de l’installer sans difficulté, et ainsi de consulter le document à télécharger.
4.2.2 Directeurs artistiques et infographistes
Le rôle essentiel du directeur artistique sera d’offrir un contenu lisible avec des contrastes de couleurs
entre le texte et le fond suffisamment élevés.
Dans le cadre de la déclinaison graphique, l’infographiste a pour mission de conserver la lisibilité des
contenus. Le directeur artistique peut avoir prévu une couleur par rubrique avec une alternance de
couleurs claires et foncées. L’infographiste doit alors penser à faire varier la couleur de la fonte avec
les variations de couleur de fond selon les rubriques.
Dans le cas de formulaires, les infographistes s’assureront qu’aucune information n’est véhiculée
uniquement par la couleur. Par exemple, une mauvaise pratique est d’indiquer en rouge les champs
obligatoires. La présence d’un astérisque sera indispensable pour les daltoniens par exemple.
4.3 Maquettage HTML
La phase de maquettage HTML est essentielle et devra être réalisée par un développeur front-end
ayant la double compétence des technologies (HTML/CSS/JS/ARIA) et de l’accessibilité. Nous n’allons
pas ici dresser la liste des critères à respecter, car elle est longue et les référentiels sont une bien
meilleure lecture. Selon les projets, 50% à 80% des critères sont à traiter dans cette phase.
Les incontournables du développeur front-end :
 W3C
 WAI
 AccessiWeb HTML5/ARIA
 AccessiWeb 2.2
 RGAA
4.4 Spécifications, développements et recette
Au même titre que la phase d’intégration HTML, les phases de spécifications et de développements
sont deux étapes importantes en accessibilité. Le CMS proposé doit répondre aux objectifs
d’accessibilité suivants :
 Générer des contenus accessibles, c’est-à-dire s’assurer que la génération
automatique de code HTML respecte le maquettage accessible initial.
 Permettre aux rédacteurs de créer des contenus accessibles en renseignant les balises
d’alternatives textuelles. Par exemple, l’insertion d’une image ne se limite pas à
l’insertion d’un fichier jpg, Il faudra prévoir un champ supplémentaire pour
l’alternative textuelle.

En fonction du CMS et de l’éditeur WISIWYG choisi pour le projet, les développeurs devront se
documenter quant aux paramétrages liés à l’accessibilité. A titres d’exemples, ci-dessous quelques
CMS et un éditeur WYSIWIG qui permettent de réaliser des sites Web Accessibles :
 DRUPAL : un site communautaire d’échanges dédiés à l’accessibilité dans Drupal et un
site d’informations sur l’accessibilité avec Drupal
 TYPO3 : site d’informations sur l’accessibilité avec Typo3
 SPIP, un site sur l’accessibilité pour les contributeurs sous SPIP et un site sur les
plugins et l’accessibilité pour SPIP
 CKeditor : site d’information sur l’accessibilité avec CKeditor
Lors de la recette, il est conseillé de repasser les tests d’accessibilité afin de vérifier que l’intégration
des pages HTML au sein du CMS n’a pas altéré la qualité d'accessibilité.
4.5 Intégration de contenus et mise en ligne
Comme pour les phases précédentes, l’intégration de contenus doit être maitrisée par les
contributeurs (rédacteurs ou webmasters) qui sont des acteurs clés dans l’accessibilité d’un site Web.
En effet, le prestataire de développement de votre futur site Web devra offrir un outil permettant de
générer du contenu accessible. Ensuite il est fondamental que les contributeurs utilisent leur outil de
gestion de contenus à bon escient, et que tout nouveau contenu créé ou mis à jour respecte les
critères d’accessibilité du Web. La formation des contributeurs à l’accessibilité est donc primordiale.
Il existe différents types de formations en fonction des rôles de chacun des contributeurs. A titre
d’exemples :
 Intégrer des contenus accessibles avec votre CMS
 Rendre vos documents PDF accessibles avec Adobe Acrobate Pro
 Créer des documents Word accessibles
 Créer des vidéos accessibles

5 Comment maintenir l’accessibilité de
votre site Web ?
L’objet de ce chapitre est de fournir des exemples de bonnes pratiques pour les contributeurs.
L’exhaustivité des critères est disponible au sein de chaque référentiel d’accessibilité.
5.1 Texte
Concernant le texte, il faudra correctement structurer le contenu en utilisant les styles appropriés. Par
exemple, il ne faudra pas passer du style de niveau 2 au style de niveau 4 sous prétexte que l’on a une
préférence pour les effets de mise en forme. Autre exemple, si le rédacteur insère une citation en
anglais dans un article en français, il faudra alors renseigner le changement de langue afin qu’il soit
correctement interprété par les lecteurs d’écran.
5.2 Hyperliens
Lors de l’insertion des hyperliens dans le texte, le contributeur devra parfois renseigner le titre du lien
(attribut title) en complément du libellé du lien. Ci-dessous quelques exemples :
 Si le lien s’ouvre dans une nouvelle fenêtre du navigateur, l’internaute doit en être
averti avec une mention du type ‘’nouvelle fenêtre’’ positionné dans le titre du lien par
exemple
 Si le lien est un fichier en téléchargement, le poids et le format du fichier doivent être
indiqués
 Si le lien n’est pas explicite hors contexte comme « en savoir plus » ou « lire la
suite », le titre du lien (title) peut être utilisé.

5.3 Images
L’insertion d’une image accessible est relativement simple mais il y a souvent une confusion entre les
images porteuses d’information et les images de décoration. Il est donc important de bien comprendre
que l’alternative textuelle n’est à ajouter que sur les images porteuses d’information. Ci-dessous un
exemple :
5.4 Tableaux de données
On réservera l’usage des tableaux pour des données et non pour de la mise en forme. Cependant,
l’insertion de tableaux est à limiter et doit être réalisée par des contributeurs ayant une bonne
connaissance du HTML. Un tableau de données mal codé peut très vite devenir incompréhensible pour
les non-voyants utilisant une synthèse vocale. A titre d’exemple, voici quelques règles essentielles à
respecter :
 Entêtes de colonnes obligatoires (th)
 Titre obligatoire et pertinent (caption)
 Bon usage des attributs headers/id pour les tableaux complexes (ex. cellules
fusionnées)
Il existe un outil en ligne d’aide à la construction de tableaux accessibles : Table Builder.
5.5 Documents PDF
Pour les documents PDF en téléchargement sur votre site Web, il est nécessaire de les rendre
accessibles à la source (exemples : Word, OpenOffice, InDesign…) puis de les convertir au format PDF
en conservant les propriétés d’accessibilité lors de la conversion. Si la source a été perdue, il est
également possible de rendre le document PDF avec le logiciel Adobe Acrobat Pro, ce qui est moins
efficace que de travailler à la source.
Ci-dessous quelques bonnes pratiques à respecter pour ce type de documents :
 le titre, la date, l’auteur et la langue du document sont renseignés
 La structure du document est indiquée par des «tags» (signets)
 l’ordre de lecture doit être clair et simple à suivre
Figure 7 – Image de décoration Figure 8 - Image porteuse d'information

 les alternatives textuelles aux images porteuses d’information sont renseignées
Il est a noter que pour les documents issus de la PAO (xPress, InDesign), la problématique est un peu
plus complexe. Par exemple, l’ordre de lecture des éléments dépend du positionnement des calques
(arrière plan, avant plan). Par ailleurs, on préférera utiliser plutôt InDesign que xPress car InDesign
propose des solutions pour rendre accessible les documents.
Exemple : une brochure de 2 pages réalisée sous InDesign pourra être rendu accessible en 1 journée
alors qu’un compte-rendu Word de 2 pages pourra être rendu accessible en 1 heure.
5.6 Vidéos
5.6.1 Recommandations de niveau A
Les éléments obligatoires à prévoir pour que les vidéos soient accessibles (dès le niveau A) sont :
 un sous-titrage
 une audiodescription
 une transcription textuelle
Si le budget le permet, on peut également aller plus loin en proposant une vidéo alternative en
langages des signes. Ce critère est de niveau AAA.
5.6.2 Recommandations de niveau AAA
Proposer des vidéos en langage des signes en complément des contenus est une initiative très
appréciée du public sourd, car environ 70% des personnes sourdes de naissance sont en situation
d’illettrisme. En effet, l’apprentissage d’une langue passe avant tout par l’ouïe. Au fur et à mesure de
l’apprentissage de notre langue maternelle, nous avons créé des équivalences entre oral et écrit. Pour
les enfants nés sourds, la langue maternelle est le langage des signes. Le problème est que ce langage
n’est pas basé sur des mots et des constructions de phrases mais sur des idées. Il n y a donc aucune
équivalence directe entre le langage des signes et l’écriture.

La législation en faveur de l’accessibilité n’impose pas de mettre des vidéos en langage des signes.
Néanmoins, cette initiative est très favorable à l’accès au Web pour le public sourd qui communique en
langage des signes. Certains sites proposent également des services de contact sur rendez-vous avec
une webcam.
Figure 9 - Exemple de lecteur vidéo avec une alternative en langue des
signes pourtous.lesite.tv

6 Vos sites et applications mobiles sont-
ils accessibles sur smartphones et
tablettes ?
6.1 Comment naviguer sur un smartphone en étant
non-voyant ?
Dans le cas de la navigation Web sur ordinateur par les non-voyants, le concept est plus facile à
imaginer par les voyants car on peut s’imaginer que la personne non-voyante a mémorisé
l’emplacement des touches d’un clavier. Dans le cas d’une navigation tactile, le fonctionnement de
base est le suivant : chaque fois que l’utilisateur pose son doigt quelque part, la synthèse vocale
annonce le nom et le type d’élément sur lequel on se trouve. S’il veut l’activer, il tape deux fois dessus.
Il existe ainsi toute une série de gestes qui sont spécifiques pour l’utilisation avec le lecteur d’écran.
Ainsi, une personne non-voyante peut parcourir une page web de titre en titre, de lien en lien, de
tableau en tableau, d’élément de formulaire en élément de formulaire etc.
Sur les derniers smartphones, un système de commande vocale permet aux utilisateurs de dicter leurs
requêtes :
 Siri à partir de l’iOS6,
 Voice Search introduit via Voice Actions sous Android 2.2 et nettement amélioré dans
les versions 4 d'Android pour aboutir à un outil assez performant.
Les non-voyants peuvent ainsi surfer sur le Web et utiliser les applications mobiles installées sur leurs
smartphones, à condition qu’elles soient accessibles (voir chapitre 6.3). Quant à la question « est-ce
que les aveugles ont une préférence entre la navigation sur les applications mobiles et celle sur les
sites Webmobile ? », nous n’avons pas de chiffres sur ce sujet et il semblerait que les deux soient
d’usage.
Pour comprendre ce fonctionnement en tant que personne « voyante », il existe de nombreuses vidéos
en ligne qui présente des aveugles en situation, par exemple : Navigating a web page with VoiceOver
on an iPhone
6.2 Accessibilité des mobiles
Aujourd’hui, les deux systèmes qui permettent d’utiliser au mieux un smartphone avec un lecteur
d’écran sont iOS (Iphone) et Android.
Pour l’instant, l’Iphone offre une navigation sur Internet acceptable. Le lecteur d’écran VoicerOver est
installé en standard sur tous les produits Apple. Ce qui permet d’être autonome dès l’initialisation du
produit au déballage.

Talkback, quant à lui, est un lecteur d’écran, depuis peu en standard sur les plateformes Android pures
(celles livrées par Google). Mais pour les Android ajoutant des surcouches, l’utilisation du mobile est
plus complexe. Les personnes aveugles peuvent donc désormais naviguer de façon acceptable sous
Android s’il s’agit d’une version sans surcouche.
Il existe également une application BlackBerry Screen Reader qui fournit un dispositif d’assistance
vocale basée sur les informations visuelles affichées à l’écran. Néanmoins, le BlackBerry ne connait pas
un grand succès auprès des non-voyants.
Quant à Windows Phone Mobile, Microsoft a annoncé en octobre 2013 la présence d’un lecteur d’écran
au sein de la prochaine version de son système mobile (Windows Phone 8 GDR 3).
6.3 Bientôt… des référentiels d’accessibilité pour
les applications mobiles
Pour développer des applications mobiles accessibles les développeurs ne disposent pas de référentiels
méthodologiques pour l’accessibilité, comme pour les sites Web. Braillenet en a présenté les avancées
lors du séminaire du GTA12 en décembre 2013 :
 Pour Android : un référentiel d'accessibilité pour les applications mobiles développées
avec le SDK Android, est en cours d'écriture. Ce référentiel a la même structure que
celui d’AccessiWeb (des thématiques, des critères, des tests) mais il est complexe à
mettre en place de par le manque de documentation sur l'accessibilité sous Android :
sortie probable courant 2014.
 Pour IOS : dans un second temps, sera établi le référentiel d'accessibilité pour les
applications mobiles développées avec le SDK IOS.
Liens utiles :
 Mobile Accessibility (W3C/WAI)
 Accessibilité pour les développeurs sous ANDROID
 Accessibilité pour les développeurs sous IOS
En ce qui concerne les recommandations pour l’accessibilité des sites Webmobile, le référentiel
HTML5/ARIA semble suffisant pour travailler sur l'accessibilité d'une application HTML5.
12 Groupe de Travail AccessiWeb

7 Autres initiatives en faveur du handicap
Nous avons abordé dans les chapitres précédents la notion d’accessibilité du Web pour tous. Nous
allons présenter ci-après quelques initiatives complémentaires qui consistent à proposer des contenus
pour des publics spécifiques.
7.1 Vocalisation des contenus
Certains sites proposent une alternative audio à chaque contenu texte. La vocalisation des contenus
n’est pas une solution primordiale pour l’accessibilité d’un site. Car des personnes en situation de
handicap (personnes non-voyantes par exemple), disposent déjà de l’environnement adéquat pour
parvenir à lire un site.
Néanmoins ces solutions permettent de transformer en fichier audio toutes les informations
pertinentes du site, afin que l’internaute puisse les écouter ultérieurement ou lors d’un déplacement.
De même, les personnes malvoyantes qui ne sont pas équipées de lecteur d’écran et synthèse vocale,
apprécieront grandement ces aides à la consultation des contenus.
Exemples d’outils de vocalisation de page Web : ReadSpeaker, VoxReader, TextHelp(BrowseAloud)
7.2 Personnalisation de l’affichage
Certains sites Web proposent de personnaliser l’affichage avec un grossissement de la police et un
changement de la couleur des contrastes. Cette fonctionnalité apporte un confort de lecture pour les
malvoyants.
Figure 10 - Exemple sur argos-service.com

7.3 Navigation en langage des signes
Il est également possible de proposer une navigation en langue des signes au sein même du menu de
navigation, tel que le propose le site de WebSourd.
Cette option est une alternative très intéressante pour les personnes qui communiquent exclusivement
en langue des signes. Il est à noter qu’il existe deux types de langages signés francophones :
 la LSF (Langue des Signes Française) est la langue des signes utilisée par les sourds
francophones
 le LPC (Langage Parlé Complété) est un codage manuel des sons de la langue française
qui peut être utilisé en complément de la lecture labiale par les personnes sourdes et
malentendantes.
Figure 11 - Exemple de menu de navigation en langue des signes

8 Conclusion
Les initiatives en faveur de l’accessibilité du Web permettent de diffuser les contenus de la toile, à un
maximum d’internautes, quels que soient leur équipement et leur handicap.
En dehors du cadre législatif qui incite les services publics à rendre accessible leurs contenus
numériques, les éditeurs de sites Web du secteur privé ont tout intérêt à communiquer à un maximum
d’internautes.
Il est important de retenir que les recommandations de référence restent celles de la WAI (W3C), à
savoir les WCAG 2.0 niveau AA comme objectif des politiques d’accessibilité globale. Les référentiels et
labels nationaux sont tous construits à partir de ces recommandations. On retiendra que le RGAA est le
référentiel pour les administrations françaises et AccessiWeb est le label national français.
Enfin, concevoir un site Web accessible nécessite d’être porté par une équipe projet pluridisciplinaire.
Des concepteurs aux développeurs, la première étape sera de produire un site Web techniquement
accessible. Puis, les efforts mis en phase de réalisation devront être maintenus lors des mises à jour,
par les rédacteurs et contributeurs formés à l’accessibilité des contenus.

Liens utiles
Spécifications, Techniques et Référentiels
W3C
WAI
WCAG 2.0
Traduction française des WCAG 2.0
ATAG 2.0
ARIA
Mobile Accessibility
AccessiWeb HTML5/ARIA
AccessiWeb 2.2
RGAA
Accessibilité et Mobilité
Mobile Accessibility (W3C/WAI)
Accessibilité pour les développeurs sous ANDROID
Accessibilité pour les développeurs sous iOS
Labels d’accessibilité
Label AccessiWeb en France
Label Euracert en Europe
Législation en faveur de l’accessibilité
En France : Loi n°2005-102 du 11 février 2005 - Article 47 et site du SGMAP
Aux Etats-Unis : Section 508 de la loi sur la réhabilitation de 1973 et ADA - Americans with Disabilities
Act
Accessibilité des documents PDF
Notices AcceDe PDF
Accessibilité des PDFs (recommandations Adobe)
Accessibilité des documents Word
Accessibilité des documents avec Word 2010
Accessibilité des documents avec Word 2007

Outils
Tanaguru
Opquast
Ocawa
Wave
Addons Web Developper
Accessible Table Builder

Index des acronymes
AJAX - Asynchronous JavaScript and XML
ARIA - Accessible Rich Internet Applications
ATAG - Authoring Tool Accessibility Guidelines
CMS – Content Management System
CSS - Cascading Style Sheets
GTA – Groupe de Travail AccessiWeb
HTML - HyperText Markup Language
LSF – Langue des Signes Française
LPC – Langage Parlé Complété
PDF - Portable Document Format
RWD – Responsive Web Design
RGAA – Référentiel Général d’Accessibilité pour les Administrations
SGMAP – Secrétariat Général pour la Modernisation de l’Action Publique
W3C - World Wide Web Consortium
WAI - Web Accessibility Initiative
WCAG - Web Content Accessibility Guidelines
WYSIWYG – What You See Is What You Get
XML - eXtensible Markup Language

A propos de l’accessibilité de ce
document
Ce document respecte l’ensemble des principes abordés jusqu’ici pour assurer l'accessibilité de ce
contenu pour tout utilisateur de technologie(s) d'assistance.
Ainsi, par exemple:
 Le document est structuré avec une utilisation appropriée des styles hiérarchiques
pour l’identification des chapitres, sections et paragraphes ;
 Chaque élément non textuel est accompagné d'une alternative textuelle ;
 En terme de présentation, le contenu est mis en forme à l'aide des styles de mise e n
forme et garanti un contraste valide entre les éléments de premier plan (par exemple,
le texte proprement parler) et les éléments de second plan, la page ;
 Le contenu ainsi proposé dispose d’aides à la navigation ;
 Etc.
Nous avons vérifié l’accessibilité de ce contenu avec le vérificateur d’accessibilité de Word 2010, puis
enregistré le document au format PDF en sélectionnant les options suivantes :
 « Créer des signets à l’aide des titres »
 « Inclure les propriétés du document »
 « Inclure les balises de structure de document »

Jouve : Le Livre blanc de l'accessibilite (2014)

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Jouve : Le Livre blanc de l'accessibilite (2014)

Similaire à Jouve : Le Livre blanc de l'accessibilite (2014) (20)

Jouve : Le Livre blanc de l'accessibilite (2014)