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

  • 264 views
Uploaded on

Comment faciliter l'accessibilité de tous vos contenus web

Comment faciliter l'accessibilité de tous vos contenus web

More in: Marketing
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
264
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
11
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 1/32 Livre blanc Accessibilité numérique Estelle RENAUD
  • 2. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 2/32 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.
  • 3. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 3/32 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
  • 4. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 4/32 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
  • 5. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 5/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
  • 6. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 6/32 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
  • 7. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 7/32 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
  • 8. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 8/32 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).
  • 9. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 9/32 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.
  • 10. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 10/32  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
  • 11. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 11/32  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.
  • 12. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 12/32 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é
  • 13. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 13/32  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
  • 14. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 14/32 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é.
  • 15. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 15/32 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
  • 16. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 16/32 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.
  • 17. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 17/32 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
  • 18. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 18/32 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.
  • 19. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 19/32 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
  • 20. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 20/32 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é.
  • 21. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 21/32 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
  • 22. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 22/32  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.
  • 23. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 23/32 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
  • 24. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 24/32 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.
  • 25. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 25/32 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
  • 26. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 26/32 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
  • 27. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 27/32 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
  • 28. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 28/32 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.
  • 29. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 29/32 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
  • 30. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 30/32 Outils Tanaguru Opquast Ocawa Wave Addons Web Developper Accessible Table Builder
  • 31. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 31/32 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
  • 32. © Jouve - Tous droits réservés - Livre blanc « Accessibilité numérique » - Mars 2014 32/32 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 »