Guide du concepteur RGAA 3 - GitHub Pages...Guide du concepteur RGAA 3 – juillet 2017 • Voir...

Guide du concepteur RGAA 3 – juillet 2017

GUIDE DU CONCEPTEUR RGAA

LICENCE D’UTILISATION

Ce document est la propriété du Secrétariat général à la modernisation de l'action publique français (SGMAP). Il est placé sous la licence ouverte 1.0 ou ultérieure, équivalente à une licence Creative Commons BY. Pour indiquer la paternité, ajouter un lien vers la version originale du document disponible sur le compte GitHub de la DInSIC.

https://www.etalab.gouv.fr/licence-ouverte-open-licence


https://github.com/DISIC




SommaireINTRODUCTION........................................................................................................ 4

À qui s’adresse ce guide ?.................................................................................................4Mode d’emploi du guide.................................................................................................... 4Plan du guide.....................................................................................................................5Conception web et RGAA 3............................................................................................... 5Ressources connexes et références.................................................................................. 5

CONCEPTION FONCTIONNELLE.....................................................................................6FICHE 1 : IMAGES.................................................................................................... 7

Synthèse............................................................................................................................7Introduction - cas utilisateurs............................................................................................7Captcha............................................................................................................................. 7Description détaillée des images porteuses d’information complexe...............................8Voir ailleurs / Ressources...................................................................................................9Critères RGAA 3.................................................................................................................9

FICHE 2 : TABLEAUX...............................................................................................10Synthèse..........................................................................................................................10Introduction - cas utilisateurs..........................................................................................10Tableaux de données simples..........................................................................................10Tableaux de données complexes.....................................................................................10Voir ailleurs / Ressources.................................................................................................12Critères RGAA 3...............................................................................................................12

FICHE 3 : FORMULAIRES..........................................................................................13Synthèse..........................................................................................................................13Introduction - cas utilisateurs..........................................................................................13Étiquettes........................................................................................................................ 14Listes de choix.................................................................................................................16Regroupement de champs.............................................................................................. 16Modification, mise à jour ou récupération des données..................................................17Aides à la saisie............................................................................................................... 17Erreurs de saisie.............................................................................................................. 18Voir ailleurs / Ressources.................................................................................................18Critères RGAA 3...............................................................................................................18

FICHE 4 : NAVIGATION............................................................................................ 19Synthèse..........................................................................................................................19Introduction - cas utilisateurs..........................................................................................19Liens d’accès rapide........................................................................................................19Deux systèmes de navigation au moins..........................................................................20Plan du site......................................................................................................................21Collection de pages......................................................................................................... 21Page en cours de consultation dans le menu..................................................................22Fil d’Ariane.......................................................................................................................22Voir ailleurs / Ressources.................................................................................................22Critères RGAA 3...............................................................................................................22

FICHE 5 : CONSULTATION.........................................................................................23Synthèse..........................................................................................................................23Introduction - cas utilisateurs..........................................................................................23Fichiers en téléchargement............................................................................................. 23Expressions inhabituelles ou idiomatiques, jargon.........................................................24Textes complexes............................................................................................................ 24Voir ailleurs / Ressources.................................................................................................24Critères RGAA 3...............................................................................................................24

CONCEPTION GRAPHIQUE......................................................................................... 25

Propriété du Secrétariat général à la modernisation de l’action publique français (SGMAP).Document placé sous la licence ouverte 1.0 ou ultérieure. /42



FICHE 6 : COULEURS.............................................................................................. 25Synthèse..........................................................................................................................25Introduction - cas utilisateurs..........................................................................................25L’information donnée par la couleur............................................................................... 26Contrastes....................................................................................................................... 28Voir ailleurs / Ressources.................................................................................................29Critères RGAA 3...............................................................................................................30

FICHE 7 : PRÉSENTATION......................................................................................... 31Synthèse..........................................................................................................................31Introduction - cas utilisateurs..........................................................................................31Visibilité des liens par rapport au texte environnant......................................................31Alternatives pour l’information donnée par la forme, taille et position...........................32Personnalisation de l’affichage........................................................................................32Voir ailleurs / Ressources.................................................................................................34Critères RGAA 3...............................................................................................................34

CONCEPTION MULTIMÉDIA.........................................................................................35FICHE 8 : MULTIMÉDIA............................................................................................ 35

Synthèse..........................................................................................................................35Introduction - cas utilisateurs..........................................................................................36Identifier le média........................................................................................................... 36Permettre la compréhension d’un média sans le son.....................................................36Permettre la compréhension d’un média sans l’image................................................... 39Médias non temporels..................................................................................................... 40Voir ailleurs / Ressources.................................................................................................40Voir aussi......................................................................................................................... 41Critères RGAA 3...............................................................................................................41Note concernant les niveaux de conformité....................................................................41

GLOSSAIRE........................................................................................................... 42Attribut title..................................................................................................................... 42Lecteur d’écran............................................................................................................... 42Jusqu’à ou à partir de 150% (1.5em) de la taille de police par défaut sans effet de graisse. Jusqu’à ou à partir de 120% (1.2em) de la taille de police par défaut en gras. 42Maquette fonctionnelle - wireframe................................................................................ 42Texte de remplacement...................................................................................................42




INTRODUCTIONCe guide du concepteur vous est proposé dans le cadre des ressources accompagnant la prise en main de la version 3 du référentiel général d’accessibilité pour les administrations (RGAA 3).

Toutes les règles et tous les exemples d’implémentation donnés ici se réfèrent à la version 3 du RGAA.

Le RGAA 3 est composé d’un document d’introduction, d’un guide d’accompagnement et d’un référentiel technique. Cet ensemble de documents a une portée réglementaire puisqu’ils ont été rendus officiels par l’arrêté du 29 avril 2015, lui-même venant préciser l’article 47 de la loi 2005-102 du 11 février 2005 et l’arrêté 2009-546 du 14 mai 2009.

Les ressources complémentaires sont des supports sans valeur réglementaire et visent à vous aider à rendre vos contenus numériques accessibles et conformes au RGAA 3.

À QUI S’ADRESSE CE GUIDE ?Ce guide s’adresse aux designers d’expérience utilisateur (UX), aux ergonomes, aux architectes de l’information, aux directeurs artistiques, aux designers d’interfaces (UI), aux web designers, aux graphistes, aux designers de contenus multimédia, aux vidéastes, mais aussi aux chefs de projet, aux directeurs de création ainsi qu’aux responsables de la maîtrise d’œuvre.

Il n’est pas nécessaire de savoir lire ni écrire du code HTML pour utiliser ce guide.

À CHACUN SON MÉTIER

Certaines problématiques ne sont volontairement pas abordées, car elles dépendent d’autres acteurs que le concepteur. Par exemple, le sens de lecture, la structure du document ou les légendes d’images ne sont pas du ressort du concepteur, mais de l’intégrateur. Ces problématiques sont abordées dans le Guide de l’intégrateur RGAA 3. Les problématiques liées à la contribution quant à elles sont abordées dans le Guide Contribuer sur le web de manière accessible.

MODE D’EMPLOI DU GUIDE

Il est fréquent qu’une même personne exerce différentes fonctions, notamment dans les structures de petite taille. Aussi, les problématiques d’accessibilité couvertes par ce guide sont organisées par type de conception, plutôt que par profil de concepteur.

Ce guide a donc été pensé sous forme de fiches pratiques, réunies par type de conception, et construites sur le même modèle pour en faciliter l’utilisation. Vous pouvez les lire en fonction de vos besoins, sans avoir à suivre un ordre particulier, chaque fiche étant indépendante.

Chaque fiche contient les sections suivantes :

• Synthèse : nous y résumons les points essentiels de chaque fiche à retenir ;

• Enjeux pour l’utilisateur handicapé : cette section vient expliciter l’importance des

recommandations décrites pour les utilisateurs concernés ;

En fonction des fiches, vous pourrez également trouver :


http://disic.github.io/guide-contribuer_accessible/index.html

http://disic.github.io/guide-contribuer_accessible/index.html

https://disic.github.io/guide-integrateur/

http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000030540064&categorieLien=id

http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000809647&fastPos=1&fastReqId=1497340759&categorieLien=cid&oldAction=rechTexte#LEGIARTI000006682279

http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000809647&fastPos=1&fastReqId=1497340759&categorieLien=cid&oldAction=rechTexte#LEGIARTI000006682279

http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000030540064&dateTexte=20150921

http://references.modernisation.gouv.fr/rgaa/criteres.html

http://references.modernisation.gouv.fr/rgaa/guide-accompagnement-RGAA.html

http://references.modernisation.gouv.fr/rgaa/introduction-RGAA.html



• Voir aussi : nous y indiquons des liens vers d’autres guides édités dans le cadre des

ressources complémentaires au RGAA 3 ; • Voir ailleurs : nous listons une sélection de ressources tierces dont la qualité et la

complémentarité à l’approche adoptée dans ce guide nous semblent intéressantes.

Enfin, vous retrouverez toujours au bas de la fiche :

• Correspondances RGAA 3 : les correspondances avec les critères du référentiel

technique du RGAA 3.

PLAN DU GUIDE

• Conception fonctionnelle

• Fiche 1 : Images

• Fiche 2 : Tableaux

• Fiche 3 : Formulaires

• Fiche 4 : Navigation

• Fiche 5 : Consultation

• Conception graphique

• Fiche 6 : Couleurs

• Fiche 7 : Présentation

• Conception multimédia

• Fiche 9 : Multimédia

CONCEPTION WEB ET RGAA 3Thématiques du RGAA 3 abordées à travers ces fiches :

• Images

• Couleurs

• Multimédia

• Tableaux

• Présentation de l’information

• Formulaires

• Navigation

• Consultation

RESSOURCES CONNEXES ET RÉFÉRENCES

• Défauts d’accessibilité : impacts sur les utilisateurs

• Guide de l’intégrateur RGAA 3

• Contribuer sur le web de manière accessible

• Méthodologie de test RGAA 3

• Liste des techniques et échecs WCAG 2.0 (ressource en anglais)


https://www.w3.org/TR/WCAG20-TECHS/

http://disic.github.io/rgaa_methodologie/

http://disic.github.io/guide-contribuer_accessible/


https://github.com/DISIC/guide-impacts_utilisateurs

https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#consultation

https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#navigation

https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#formulaire

https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#presentation

https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#tableaux

https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#multimedia

https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#couleurs

https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#images



CONCEPTION FONCTIONNELLELa conception fonctionnelle a pour objectif de définir le fonctionnement et les fonctionnalités d'un site web, en tenant compte des objectifs de celui-ci et des besoins de ses utilisateurs. La conception fonctionnelle démarre à la réception du cahier des charges, et intervient avant la phase de conception graphique.

Elle est généralement conduite par des designers d'expérience utilisateur (UX), des ergonomes, des architectes de l'information, mais peut également être menée par des designers d'interfaces (UI), des web designers, voire même des graphistes dans de petites équipes polyvalentes. Les chefs de projet et les directeurs artistiques peuvent également être amenés à participer à la conception fonctionnelle.

En déterminant l'architecture de l'information, le système de navigation, la structuration des pages, mais également la chorégraphie responsive et la façon dont l'utilisateur va pouvoir interagir avec le site, le concepteur fonctionnel prend des décisions stratégiques qui vont fortement impacter l'utilisabilité du site, c'est à dire la facilité avec laquelle l'utilisateur pourra interagir avec lui.

La conception fonctionnelle joue donc un rôle crucial en matière d'accessibilité web : puisque son rôle est d'améliorer l'expérience utilisateur, elle doit alors également permettre aux utilisateurs en situation de handicap d'utiliser le site. En effet, l’expérience utilisateur des personnes handicapées peut être complètement différente de celle d’un utilisateur valide utilisé comme persona. Ainsi, l’expérience utilisateur doit être inclusive et tenir compte des besoins spécifiques des personnes handicapées.

Lorsque les besoins spécifiques des utilisateurs handicapés sont pris en compte dès la conception fonctionnelle, en amont de la production graphique et technique du site, alors l'accessibilité est plus simple et moins coûteuse à mettre en œuvre qu'en fin de chaîne de production.

Les fiches suivantes abordent les problématiques d'accessibilité qui concernent la conception fonctionnelle dans le RGAA 3 :

• Fiche 1 : Images

• Fiche 2 : Tableaux

• Fiche 3 : Formulaires

• Fiche 4 : Navigation

• Fiche 5 : Consultation




FICHE 1 : IMAGES• Introduction - cas utilisateurs

• Captcha

• Description détaillée des images porteuses d’information complexe

• Voir ailleurs / Ressources

• Critères RGAA 3

SYNTHÈSE

• Prévoir une alternative au Captcha.

• Prévoir une description détaillée adjacente aux images porteuses d’information

complexe.

INTRODUCTION - CAS UTILISATEURS

Les images véhiculent parfois une information importante. Cette information, qui peut aider à comprendre le contenu auquel elle se rapporte, doit pouvoir être accessible à tous.

Fournir une alternative aux images porteuses d’information est indispensable pour les utilisateurs qui ne perçoivent pas, ou perçoivent mal, le contenu visuel. C’est le cas des personnes aveugles ou malvoyantes. Un lecteur d’écran va pouvoir accéder à cette alternative et le restituer à l’utilisateur.

De même, pour les personnes qui présentent des difficultés de compréhension face à certaines représentations visuelles (iconographie, peintures, représentations multi-dimensionnelles, graphiques…), une alternative peut aider à en comprendre le sens ou à en extraire l’information importante.

Pour toutes ces raisons, il est essentiel de traduire de manière textuelle l’information nécessaire et suffisante qu’apportent les images.

Attention cependant : lorsque ces images constituent des liens, ce n’est alors plus l’information qu’elles véhiculent qui est essentielle, mais la fonction du lien qu’elles constituent. Dans cette situation, elles permettent aux logiciels pilotés à la voix par une personne en situation de handicap moteur, de localiser plus facilement le lien à activer.

CAPTCHA

Les images tests (Captcha) doivent posséder une alternative, mais contrairement aux images porteuses d’information, cette alternative ne doit pas décrire le contenu visible du Captcha, mais doit permettre à l’utilisateur de comprendre la nature et le rôle de l’image. En général, cette alternative est gérée pendant la phase de développement technique du site.

Lorsque le Captcha est une image, ce mécanisme peut être complété par une méthode alternative permettant à l’utilisateur de résoudre le test. Par exemple, si une maquette fonctionnelle présente un Captcha image, il peut être utile de proposer l’implémentation d’une alternative sonore.




DESCRIPTION DÉTAILLÉE DES IMAGES PORTEUSES D’INFORMATION COMPLEXE

Le texte de remplacement n’est à utiliser que dans le cas d’images qu’il est simple de décrire en une phrase. Dans le cas d’une image complexe, qui demande la rédaction d’un paragraphe entier (par exemple un plan de quartier, un graphique, un histogramme), vous devez fournir une description détaillée. Vous pouvez par exemple indiquer ces textes alternatifs sous forme d’annotations sur vos maquettes, afin que les intégrateurs puissent facilement les prévoir dans leurs gabarits HTML.

Lorsqu’une image demande une description détaillée, il faut prévoir, sous cette image, un texte correctement structuré qui la décrit. Ce texte peut être un paragraphe, mais il peut également prendre d’autres formes. Par exemple, dans le cas d’un graphique complexe, la description détaillée pourrait reprendre l’information sous la forme d’un tableau ou d’une liste. C’est au concepteur fonctionnel de juger de la meilleure structuration possible pour que l’information soit correctement restituée, après consultation d’un intégrateur en cas de doute.

Pour permettre à un utilisateur de lecteur d’écran de faire le lien entre l’image et sa description détaillée, vous devrez préciser le titre de l’image au début de cette description détaillée. Par exemple, dans le cas d’un plan : « Plan d’accès (description détaillée) : Pour accéder à… ». Les intégrateurs ou contributeurs quant à eux s’assureront que la mention Plan d’accès se trouve dans le texte de remplacement, et seulement elle : en effet, il ne faut pas reprendre la description détaillée dans le texte de remplacement.

Une fois que cette description détaillée est prévue, il existe plusieurs façons de la traiter visuellement :

• soit on affiche cette description détaillée telle quelle sous l’image concernée ;

• soit on masque cette description détaillée par défaut, et on met en place un bouton

sous l’image qui permettra à l’utilisateur d’afficher et de masquer la description détaillée si besoin ;

• soit on ajoute un lien adjacent juste après l’image : ce lien devrait être intitulé

« Description détaillée », et devrait mener vers une page intitulée elle aussi « Description détaillée » qui contient la description détaillée de l’image correctement structurée. Cette page peut être intégrée dans le gabarit du site comme toutes les autres pages, mais il peut également s’agir d’une page blanche contenant uniquement ce texte-là : tout ce qui compte, c’est que la page contenant la description détaillée soit conforme au même titre que les autres pages. L’intitulé du lien menant à cette page ne doit surtout pas être remplacé par un intitulé abstrait de type « En savoir plus ».

• Il est également possible d’utiliser un attribut longdesc pendant la phase d’intégration.




EXEMPLE D’UNE IMAGE COMPLEXE AVEC UNE DESCRIPTION DÉTAILLÉE

Ci-dessous l’exemple d’une image complexe. Il s’agit d’un plan de localisation. Un texte de remplacement n’est pas suffisant pour retranscrire toute l’information présente sur ce plan. Il faut donc prévoir la présence de cette description détaillée dans les spécifications et sur les maquettes fonctionelles.

Description détaillée du plan d’accès au musée d’histoire naturelleL’entrée du musée d’histoire naturelle est accessible depuis la rue Voltaire.

Depuis la rue Athénas, descendre vers la rue Voltaire et prendre sur la gauche, l’entrée du musée est située sur votre gauche.

Depuis la rue Lesage, descendre vers la rue Voltaire et prendre sur la droite, l’entrée du musée est située sur votre droite.

Depuis la Rue Marivaux, redescendre vers la rue Lesage, continuer tout droit pour atteindre la rue Voltaire, l’entrée du musée est située sur votre droite.

VOIR AILLEURS / RESSOURCES

• Impacts utilisateurs des défauts d’accessibilité des images

• Fiche « Quand une image vaut mille mots » du guide Contribuer sur le web de manière

accessible

CRITÈRES RGAA 3• 1.4 [A]

• 1.5 [A]

• 1.6 [A]

• 1.7 [A]


http://disic.github.io/guide-contribuer_accessible/images.html

http://disic.github.io/guide-contribuer_accessible/images.html

https://disic.github.io/guide-impacts_utilisateurs/images.html



FICHE 2 : TABLEAUX• Introduction - cas utilisateurs

• Tableaux de données simples

• Tableaux de données complexes



SYNTHÈSE

• Attribuer un titre pertinent à chaque tableau de données.

• Prévoir un résumé pour chaque tableau de données complexe.


Un tableau est toujours complexe à utiliser avec un lecteur d’écran. Une personne aveugle n’a pas une vision globale du tableau. Elle le parcourt de manière séquentielle : une case après l’autre et ligne à ligne. Afin d’améliorer son expérience, les lecteurs d’écran offrent des fonctionnalités de parcours étendues en utilisant les flèches de direction.

TABLEAUX DE DONNÉES SIMPLES

Un tableau est considéré comme simple s’il ne possède pas de cellules fusionnées qui rendent la compréhension délicate et s’il ne présente pas une structure (notamment des sous-contextes) qui rend sa compréhension dépendante d’une mise en forme.

Lors de la phase de conception, il est nécessaire de prévoir un titre pertinent pour chaque tableau. Ce titre doit permettre de comprendre les données du tableau. Par exemple : « Chiffres d’affaires des différents secteurs d’activités. » ou « Accessibilité des lignes du réseau de surface RATP » dans l’exemple ci-dessous.

Accessibilité des lignes du réseau de surface RATP

Équipements Nombre de lignes Pourcentage du total de lignesRampe d’accès 260 70,46 %Annonce sonore 318 86,17 %

Ces données sont issues du site data.gouv.fr. Leur exploitation dans ce contexte n’est faite qu’à titre d’illustration, elle ne relève en rien d’une statistique officielle.

Il est possible de masquer ce titre de manière accessible : il sera alors masqué visuellement, mais toujours accessible aux utilisateurs de lecteurs d’écran.

TABLEAUX DE DONNÉES COMPLEXES

Les tableaux de données complexes sont généralement des tableaux qui possèdent des cellules fusionnées ou des sous-contextes.

Voici un exemple de tableau de données complexe :


https://www.data.gouv.fr/fr/datasets/accessibilite-des-lignes-du-reseau-de-surface-ratp-ratp/



Nombre de gares et points d’arrêts TER, en fonction du type de handicap et du type de dispositif par handicap

Malvoyants AveuglesObstacles contrastés Portes contrastées Obstacles détectables à la canne Guidage en braille73 65 103 0138 103

Ces données sont issues du site data.gouv.fr (Accessibilité des gares et points d’arrêt TER aux personnes à mobilité réduite en 2013). Leur exploitation dans ce contexte n’est faite qu’à titre d’illustration, elle ne relève en rien d’une statistique officielle.

Comme les tableaux de données simples, les tableaux de données complexes doivent posséder un titre.

De plus, chaque tableau de données complexe doit posséder un résumé : le contenu de ce résumé doit être prévu lors de la phase de conception. Ce résumé a pour objectif d’expliciter la structure du tableau, en décrivant de façon factuelle son organisation spaciale. Ce résumé ne sera pas affiché visuellement sous le tableau : il sera contenu dans une balise HTML dédiée (caption).

Ci-dessous un exemple de tableau complexe (issu et adapté du site de l'INSEE). Vous y trouvez des en-têtes de colonnes fusionnées (« Variation (en %) au cours ») ainsi que des en-têtes qui titrent des parties du tableau (toutes les lignes fusionnées du type « a) Ensemble des ménages - France »).

Dans ce cas de tableau complexe, pour faciliter la lecture, il serait par exemple possible de découper ce tableau en 3 tableaux distincts, chacun correspondant aux 3 sections (a, b et c).

Si ce tableau reste en l'état, un résumé pertinent pourrait être : « Répartition des ménages en France en fonction du type d'achats. On y trouve 3 grands regroupements :

• un premier regroupement concerne l'ensemble des ménages en France ;

• un second regroupement concerne les ménages urbains dont le chef est ouvrier ou

employé ;


https://www.data.gouv.fr/fr/datasets/accessibilite-des-gares-et-points-d-arret-ter-aux-personnes-a-mobilite-reduite-en-2013-npc/

https://www.data.gouv.fr/fr/datasets/accessibilite-des-gares-et-points-d-arret-ter-aux-personnes-a-mobilite-reduite-en-2013-npc/

http://data.gouv.fr/



• un troisième regroupement concerne les ménages du 1er quintile de la distribution des

niveaux de vie.

Pour chacun des regroupements :

• la première colonne représente les pondérations pour l'année 2015 ;

• la seconde colonne représente l'indice pour le mois d'août 2015 ;

• la troisième colonne représente la variation en pourcent au cours du dernier mois ;

• la dernière colonne représente la variation en pourcent au cours des 12 derniers mois.

Note : bien qu’il soit préférable que le titre et le résumé des tableaux complexes soient affichés, vous pouvez demander à votre équipe d’intégrateurs de les positionner hors écran sans utiliser de propriétés CSS qui les rendraient invisibles pour un lecteur d’écran (cf. Liens d’accès rapides dans le Guide de l’intégrateur RGAA 3).

Pour faciliter la compréhension d’un tableau complexe, on peut également le scinder en plusieurs tableaux simples. Toutefois, cette scission n’est pas toujours possible, car il peut y avoir énormément de redondance d’un tableau à l’autre. Aussi, une alternative consiste à scinder un tableau complexe en listes. Dans ce cas-là, on peut donc prévoir un lien « Version accessible du tableau » avec une liste en-tête / données, en-tête / données, en-tête / données, etc. Et on aura exactement la même restitution vocale pour une personne aveugle. De plus, pour une personne handicapée mentale, la répétition des en-têtes sera la seule façon de comprendre.


• Impacts utilisateurs des défauts d’accessibilité des tableaux

• Fiche « Des tableaux pour présenter des données » dans le guide Contribuer sur le web

de manière accessible


• 5.2 [A]

• 5.4 [A]

• 5.5 [A]

• 5.6 [A]

• 5.7 [A]


http://disic.github.io/guide-contribuer_accessible/tableaux.html

http://disic.github.io/guide-contribuer_accessible/tableaux.html

https://disic.github.io/guide-impacts_utilisateurs/tableaux.html

https://disic.github.io/guide-integrateur/2-navigation.html#liesnrapide




FICHE 3 : FORMULAIRES• Introduction - cas utilisateurs

• Étiquettes

• Pertinence des étiquettes de champs

• placeholder, attention.

• Pertinence des intitulés de boutons

• Étiquettes accolées

• Listes de choix

• Regroupement de champs

• Modification, mise à jour ou récupération des données

• Aides à la saisie

• Champs obligatoires

• Format attendu

• Erreurs de saisie


• Critères RGAA

SYNTHÈSE

• Définir une étiquette pertinente pour chaque champ de formulaire, y compris les listes

de choix. • Ne pas utiliser placeholder comme étiquette.

• Définir des intitulés de boutons pertinents.

• Accoler chaque étiquette au champ qu’elle définit.

• Regrouper les options des listes de choix si besoin, et attribuez une étiquette pertinence

à chaque regroupement. • Indiquer les champs obligatoires dans l’étiquette du champ si besoin, à l’aide d’une

mention ou d’un symbole dont la légende se trouve avant le formulaire. • Indiquer le format de saisie dans l’étiquette des champs obligatoires.

• Insérer l’erreur de saisie à côté du champ concerné et indiquer un exemple de saisie

réelle lorsque nécessaire.


L’identification des champs de formulaire est un élément essentiel. Beaucoup d’utilisateurs handicapés vont accéder aux champs de manières très diverses.

Les utilisateurs de lecteurs d’écran disposent de raccourcis clavier leur permettant de naviguer rapidement d’un champ à l’autre et certains dispositifs de navigation vocale proposent d’accéder aux champs par leur nom.

Dans ce type de contexte, il est important que chaque champ de formulaire possède une étiquette liée, afin qu’elle soit restituée lors de la prise de focus. Cela permettra aux personnes aveugles d’utiliser à profit les raccourcis clavier et aux utilisateurs de navigation vocale d’accéder rapidement aux champs. En effet, quand on clique sur l’étiquette d’un champ, cela active le champ. Une étiquette correctement reliée à un champ permet donc d’étendre la




surface de clic et améliore ainsi l’efficacité des manipulations, en particulier pour les utilisateurs de dispositifs de pointage adapté.

ÉTIQUETTES

Une étiquette de champ est un texte qui permet d’expliquer quelle donnée est attendue par le champ (nom, prénom, date de naissance, courriel, etc.).

Pour être conforme, une étiquette doit :

• être pertinente ;

• être correctement reliée au champ correspondant.

PERTINENCE DES ÉTIQUETTES DE CHAMPS

Une étiquette est pertinente si elle permet de comprendre la fonction du champ auquel elle est reliée. Il faut rester concis : l’objectif est que l’utilisateur comprenne ce qu’on attend de sa saisie. Par exemple, pour les données d’identité, une étiquette « Nom », une étiquette « Prénom » et une étiquette « Téléphone » sont des étiquettes pertinentes qui permettent de comprendre ce que l’on doit y inscrire.

De plus, une étiquette associée à un champ de formulaire ayant la même fonction et répétée plusieurs fois dans une même page ou dans un ensemble de pages doit être cohérente.

Note : pour un champ de recherche, il est toléré de positionner l’étiquette hors écran, si elle reste accessible aux lecteurs d’écran, parce que le contexte permet d’en comprendre la fonction.

placeholder, attention.Un placeholder est un texte décoratif qui peut être ajouté au niveau d’un champ de

formulaire. C’est un texte grisé qui disparaît lorsque l’utilisateur débute la saisie.

Exemple de placeholder, vu sur le site « Infos-Parents » du Ministère de l’Éducation nationale

Bien qu’il soit fréquemment utilisé par les designers web, placeholder n’est pas considéré

comme une étiquette valide au regard du RGAA pour les raisons suivantes :

• son contraste est insuffisant (ce qui peut éventuellement être corrigé avec CSS) ;

• il n’est pas restitué de manière uniforme par les lecteurs d’écran, ce qui le rend

inaccessible aux utilisateurs aveugles ou malvoyants.

En outre, un utilisateur pourrait penser que le placeholder constitue la valeur du champ, ce

qui l’induirait en erreur et pourrait perturber sa saisie.

Si vous souhaitez malgré tout utiliser placeholder à des fins esthétiques, assurez-vous que le

champ possédant le placeholder possède également un attribut title valide et pertinent.

Pour cela, l’attribut title reprendra exactement le même intitulé que le placeholder. En effet,

une information que vous ajouteriez dans le placeholder pour aider certains utilisateurs doit

nécessairement être présente dans l’étiquette du champ, afin d’être accessible à tous.


http://infos-parents-accessibles.education.gouv.fr/



PERTINENCE DES INTITULÉS DE BOUTONS

Les boutons qui permettent d’interagir avec le formulaire doivent avoir des intitulés pertinents qui permettent à l’utilisateur de comprendre l’action du bouton. Ils sont essentiels pour les utilisateurs aveugles afin qu’ils soient sûrs de l’action qu’ils réalisent.

Par exemple des intitulés comme « Envoyer », « Ok », « Valider »… ne seront pas suffisamment pertinents.

À l’inverse, des intitulés qui explicitent l’action sont pertinents : par exemple : « M’inscrire au cours de danse », « Réserver mes billets en ligne ».

Cependant, il est également possible de conserver un intitulé de bouton court, et de le rendre pertinent à l’aide d’un attribut title par exemple. Cette implémentation est conforme, mais

nous vous invitons à n’utiliser cette implémentation que dans des cas restreints. En effet, l’attribut title n’est visible qu’au survol de la souris. Or, un utilisateur voyant qui navigue

exclusivement au clavier n’accédera pas à cette information. Il existe des scripts qui permettent de faire apparaître le contenu de l’attribut title lors de la tabulation (par exemple

AccessTooltip).

Faute d’intitulé pertinent sur un bouton de type image, les lecteurs d’écran vocaliseraient le nom du fichier image, ce qui serait incompréhensible pour les utilisateurs aveugles. Il faut donc prévoir l’intitulé du bouton lors de la phase de conception, et le communiquer aux équipes techniques, même s’il s’agit d’un bouton qui ne contient a priori qu’une image. Demandez à votre équipe d’intégrateurs de prévoir cet intitulé dans le code HTML et de le positionner hors écran sans utiliser de propriétés CSS qui le rendraient invisible pour un lecteur d’écran (cf. Liens d’accès rapides dans le Guide de l’intégrateur RGAA 3).

ÉTIQUETTES ACCOLÉES

Pour aider l’utilisateur à comprendre le lien entre une étiquette et un champ, il faut accoler l’étiquette au champ de façon prévisible.

Une technique courante consiste à positionner l’étiquette immédiatement avant le champ auquel elle se rattache, soit à côté à gauche ou au-dessus à gauche du champ pour les langues qui s’affichent de gauche à droite, soit à côté à droite ou au-dessus à droite pour les langues qui s’affichent de droite à gauche. De même, une étiquette reliée à un bouton radio ou à une case à cocher est généralement positionnée après le champ.

Ces techniques sont les plus courantes mais il n’est pas exclu de faire autrement à partir du moment où étiquette et champ sont accolés.

Une étiquette accolée à un champ de manière prévisible aide l’utilisateur à se repérer plus facilement dans le formulaire, et à identifier plus facilement l’action qu’il doit effectuer pour chaque champ. C’est particulièrement important pour les utilisateurs ayant recours à une loupe d’écran : si l’étiquette est trop éloignée du champ qu’elle concerne, l’utilisateur la perdra de vue et ne saura pas quel champ il remplit.



http://access42.net/AccessTooltip-rendre-le-title-accessible-au-clavier.html



LISTES DE CHOIX

Les listes de choix (également appelées listes déroulantes) doivent être, comme tout champ de formulaire, étiquetées correctement.

Si la liste de choix propose un certain nombre d’options pour lesquelles il est possible de faire des regroupements, alors il faut prévoir ces regroupements et leurs étiquettes respectives. Ces regroupements visuels et sémantiques aideront les utilisateurs à se repérer dans des listes de choix particulièrement longues.

REGROUPEMENT DE CHAMPS

Dans certains formulaires, il est nécessaire de créer des regroupements de champs. Ces regroupements de champs sont utiles pour ne pas induire certains utilisateurs, notamment aveugles, en erreur.

Par exemple, un formulaire d’achat en ligne propose un formulaire avec la saisie d’une adresse de livraison et une adresse de facturation. Puisque les deux vont posséder des champs avec des étiquettes similaires, il est impératif de créer un regroupement pour que l’utilisateur comprenne quelle adresse il renseigne.




Les autres cas typiques de regroupements nécessaires sont les groupes de cases à cocher ou de boutons radio.

En outre, les regroupements de champs doivent posséder eux aussi une étiquette pertinente.

MODIFICATION, MISE À JOUR OU RÉCUPÉRATION DES DONNÉES

Chaque formulaire devrait permettre à l’utilisateur de modifier, mettre à jour ou récupérer les informations qu’il a saisies. C’est particulièrement important pour les données à caractère financier, juridique ou personnel.

Pour les formulaires en une page, cela ne pose pas de problème particulier de conception du moment que les champs de saisie concernés restent modifiables à tout moment avant validation du formulaire.

Si les champs sont désactivés au fur et à mesure de la saisie, par exemple, il faut prévoir une page récapitulative avec la possibilité de modifier chaque champ.

AIDES À LA SAISIE

L’objectif des aides à la saisie est d’éviter aux utilisateurs de faire des erreurs lorsqu’ils remplissent un formulaire. Ces aides contextuelles ne sont nécessaires que lorsque l’étiquette rattachée au champ ne suffit pas à décrire le type de saisie attendue.

Deux types d’aides à la saisie peuvent ainsi être prévus dans les formulaires : d’une part, l’indication des champs obligatoires ; d’autre part, l’indication du format attendu.

CHAMPS OBLIGATOIRES

Le RGAA n’impose pas que les champs obligatoires soient systématiquement indiqués à l’utilisateur (par exemple, il est inutile de le faire sur le seul champ d’un moteur de recherche). Par contre, si vous indiquez les champs obligatoires, cela doit être fait de manière accessible. On identifie trois façons principales de faire.

Indication textuelle dans l’étiquetteL’indication de champ obligatoire peut être mise directement dans son étiquette, par exemple : « Nom (champ obligatoire) ». C’est la solution la plus simple.

Indication par un symboleIl est aussi très courant de trouver l’indication de champs obligatoire au moyen d’un astérisque. Cette pratique est tout à fait conforme si vous donnez une légende à ce symbole, et ce avant le formulaire concerné.

Indication par la couleurSi vous décidez de placer les étiquettes des champs obligatoires en rouge pour signifier les champs obligatoires, assurez-vous que cette couleur soit toujours doublée d’un symbole clairement explicité. En effet, un utilisateur aveugle n’a pas accès aux couleurs, et un utilisateur ne distinguant pas les couleurs ne pourra pas non plus les percevoir.




FORMAT ATTENDU

L’aide contextuelle peut également informer l’utilisateur du format de saisie attendu.

Par exemple, si un champ de date attend que les valeurs jour, mois et année soient distinguées par une barre oblique pour être conforme, vous devez donc indiquer « jj/mm/aaaa », qui correspond au format de saisie.

La solution la plus simple est d’ajouter ce texte d’aide dans l’étiquette : il sera alors accessible à tous les utilisateurs, quel que soit leur handicap.

Mais il est également possible de recourir à des méthodes alternatives pour le faire de manière accessible (cf. la fiche consacrée aux formulaires dans le « Guide de l’intégrateur RGAA 3 »).

ERREURS DE SAISIE

Lorsque le formulaire retourne des erreurs après validation, l’erreur doit être mentionnée de manière explicite soit :

• dans l’étiquette du champ ;

• dans un passage de texte situé avant le formulaire, qui rassemble la liste de tous les

champs erronés ; • dans un passage de texte relié techniquement au champ de saisie.

Au niveau AA, les messages d’erreur de saisie relative à l’utilisation d’un mauvais format de données, par exemple une erreur de saisie de courriel, doivent comporter un exemple de saisie réelle. Cela aide l’utilisateur à comprendre son erreur et à la corriger.

Note : si les erreurs sont indiquées au niveau de chaque champ, il n’est pas nécessaire de lister l’ensemble des erreurs en début de formulaire.


• Impacts utilisateurs des défauts d’accessibilité des formulaires

• Fiche « Formulaires » du « Guide de l’intégrateur RGAA 3 »

• Page de démonstration de la construction HTML des étiquettes de formulaire

• Page de démonstration pour les regroupements de champs


• 11.2 [A]

• 11.3 [AA]

• 11.4 [A]

• 11.5 [A]

• 11.6 [A]

• 11.7 [A]

• 11.8 [A]

• 11.9 [A]

• 11.10 [A]

• 11.11 [AA]

• 11.12 [AA]

• 11.13 [AA]

• 11.14 [AAA]

• 11.15 [AAA]


http://guide-concepteur.loc/demo/6-formulaires/regroupement.html

https://disic.github.io/guide-integrateur/demo/6-formulaires/etiquettes.html

https://disic.github.io/guide-integrateur/6-formulaires.html

https://disic.github.io/guide-impacts_utilisateurs/formulaires.html

https://disic.github.io/guide-integrateur/6-formulaires.html#aidessaisie



FICHE 4 : NAVIGATION• Introduction - cas utilisateurs

• Liens d’accès rapide

• Deux systèmes de navigation au moins

• Plan du site

• Collection de pages

• Page en cours de consultation dans le menu

• Fil d’Ariane


• Critères RGAA

SYNTHÈSE

• Prévoir un lien d’accès rapide au contenu.

• Prévoir un lien d’accès rapide à la navigation principale si nécessaire.

• Prévoir des liens d’accès rapide pour tous les groupes de liens importants.

• Prévoir deux systèmes de navigation au moins.

• Prévoir des liens facilitant la navigation dans les collections de pages.


Vous devez fournir aux utilisateurs au moins deux systèmes de navigation afin de couvrir un plus large spectre de stratégies de navigation dans les contenus du site. En effet, tous les utilisateurs ne naviguent pas de la même manière et certains systèmes de navigation peuvent s’avérer trop complexes à utiliser. Par exemple, un menu de navigation trop riche, comme un méga-menu, peut nécessiter beaucoup d’actions pour un utilisateur qui ne navigue qu’au clavier et donc rendre sa recherche d’information laborieuse. Proposer un second système permet d’aider ces utilisateurs qui ont des stratégies de navigation différentes.

Certains utilisateurs peuvent avoir des difficultés à atteindre la zone de contenu principal. Par exemple : les utilisateurs malvoyants qui utilisent une loupe d’écran ne voient pas la page dans sa globalité. Il peut être laborieux pour ces utilisateurs de devoir scroller tous les éléments communs des pages d’un site (l’en-tête, la navigation) pour atteindre le contenu principal à chaque fois. De même, les utilisateurs aveugles qui ont une lecture linéaire de la page doivent parcourir tous les éléments redondants (titre principal, navigation, etc.) avant d’atteindre le contenu principal.

Les utilisateurs qui ne peuvent pas utiliser de souris ou un système de navigation adapté restent néanmoins ceux qui rencontrent le plus de difficultés. Pour ces utilisateurs, la zone de contenu principal, comme tous les autres éléments du site ne peut être atteinte qu’avec la tabulation, ce qui peut être particulièrement laborieux.

Les liens d’accès rapide en début de contenu leur permettent de réduire considérablement leur temps de consultation, ils peuvent directement atteindre la zone de contenu principal.

LIENS D’ACCÈS RAPIDE

Vous devez fournir aux utilisateurs des liens d’accès rapide (également appelés liens d’évitement). Les liens d’accès rapide sont des ancres vers certains éléments de la page. Sans




ces liens d’accès rapide, les utilisateurs tétraplégiques doivent faire des centaines et des centaines de tabulations pour atteindre un élément de la page. C’est pourquoi ce critère RGAA est non négociable.

Ainsi sur votre site, vous devez implémenter :

• un lien qui permet d’accéder à la zone de contenu principale ;

• un lien qui permet d’accéder à chaque groupe de liens importants (par exemple la

navigation).

Note : le lien d’accès à la zone de contenu principale devrait toujours être présent. En revanche, le lien d’accès à la navigation principale n’est utile que s’il y a beaucoup de contenus tabulables avant le menu de navigation principal. Quand ce n’est pas le cas, le lien d’accès à la navigation principale n’est pas forcément utile.

Ces liens d’accès rapide doivent de préférence toujours être visibles. En effet, ils sont utiles aux utilisateurs aveugles, aux utilisateurs qui naviguent au clavier, mais également aux utilisateurs malvoyants qui utilisent une loupe d’écran. Ces derniers naviguent à la souris et si ces liens sont positionnés hors écran, il leur est impossible de les utiliser.

Bien qu’il soit préférable que ces liens soient toujours visibles, vous pouvez indiquer à votre équipe d’intégrateurs que ces liens doivent être rendus accessibles à la prise de focus (cf. Liens d’accès rapides dans le Guide de l’intégrateur RGAA 3).

Pour qu’ils soient efficaces, les liens d’accès rapide au contenu et à la navigation doivent être positionnés en début de code et en haut de page. En faire les premiers liens du code de votre page est la meilleure solution.

Important : ces liens doivent toujours être situés à la même place dans la présentation. De plus, afin que les utilisateurs aveugles, qui ont une lecture linéaire de votre site, puissent s’y retrouver, ces liens doivent toujours être dans le même ordre dans le code source.

Page de démonstration des cas d’implémentation des liens d’accès rapide

DEUX SYSTÈMES DE NAVIGATION AU MOINS

Un site web doit proposer deux systèmes de navigation au moins, parmi :

• une navigation principale ;

• un moteur de recherche ;

• un plan du site.

Pour que le moteur de recherche puisse être considéré comme un élément de navigation, il doit indexer toutes les pages du site. Ainsi, un moteur de recherche dans un catalogue qui ne permet pas de trouver la page des mentions légales du site n’est pas considéré comme un moteur de recherche. Le moteur de recherche doit également être atteignable de manière identique depuis chaque ensemble de pages.

Le plan du site quant à lui doit être représentatif de la structure générale du site. Il n’est pas demandé que soient référencées toutes les pages du site, mais seulement les pages menant aux rubriques principales. Par exemple, si le site dispose d’une rubrique « Actualités », il n’est pas nécessaire d’y faire figurer toutes les actualités publiées.

Il existe des cas particuliers pour lesquels cette recommandation est non applicable :


https://disic.github.io/guide-integrateur/demo/2-navigation/access-rapide.html





• un site composé d’un faible nombre de pages (deux à trois pages) peut ne fournir qu’un

menu de navigation menant vers ces pages, le menu étant alors identique au plan du site ;

• un site monopage (« Single Page Application ») peut ne fournir que des liens d’accès

rapide aux différentes sections de la page, la fonction de recherche du navigateur (Ctrl

F) permettant de chercher dans tout le contenu du site.

ORDRE COHÉRENT ET PRÉSENTATION COHÉRENTE

Chaque système de navigation doit avoir sur chaque ensemble de pages un ordre et une présentation cohérente :

• le système de navigation est accessible depuis une fonctionnalité identique (par

exemple, pour le plan du site, la fonctionnalité est un lien ayant pour intitulé « Plan du site ») ;

• la fonctionnalité est située à la même place dans la présentation (par exemple, le lien

vers le plan du site est toujours situé en haut à gauche sur la page) ; • la fonctionnalité est toujours dans le même ordre relatif dans le code source (par

exemple, le lien vers le plan du site est toujours le premier élément texte et le premier lien de la page).

PLAN DU SITE

Le plan du site n’est pas obligatoire, il fait partie des trois systèmes de navigation reconnus.

Si vous intégrez un plan de site, vous devrez vous assurer que tous les liens qui y sont listés sont pertinents et fonctionnels. Vous pouvez utiliser l’outil de validation des liens du W3C pour vous en assurer.

Vous devrez également vous assurer que le plan du site est atteignable de la même façon depuis chaque ensemble de pages.

COLLECTION DE PAGES

Une collection de pages est un ensemble de pages reliées les unes aux autres par des liens et ayant un thème ou une nature commune. Par exemple, les pages de résultats d’un moteur de recherche ou les pages d’un catalogue sont des collections de pages.

Pour les pages d’une collection de pages, vous devez mettre à disposition de l’utilisateur :

• un lien permettant d’accéder à la page suivante ;

• un lien permettant d’accéder à la page précédente ;

• des liens permettant d’accéder à toutes les pages de la collection.

Collection de pages issue du site Service-public.fr

Lorsque le nombre de pages est très important, il est illusoire de vouloir mettre un lien vers chaque page. Dans ce cas, il est acceptable de présenter les liens par groupe de 10 liens par exemple (« 20-30 »).


https://www.service-public.fr/particuliers/recherche?keyword=test&rubricFilter=fichePratique&page=2

https://validator.w3.org/checklink



D’autres systèmes permettant d’atteindre une page quelconque d’une collection de pages peuvent être utilisés comme un champ de formulaire ou une liste de sélection.

Page de démonstration des cas d’implémentation de la navigation dans les collections de pages

PAGE EN COURS DE CONSULTATION DANS LE MENU

Indiquer la page en cours de consultation aux utilisateurs permet de leur donner des points de repère quant à leur localisation dans le site.

Note : cette recommandation est de niveau AAA, elle n’est donc pas obligatoire.

Attention : lorsque vous indiquez la page en cours dans le menu de navigation, ne véhiculez pas cette information uniquement par la couleur et/ou par la forme. Par exemple, si vous décidez de modifier la couleur d’arrière-plan du lien actif, n’oubliez pas de prévoir un titre (title) sur le lien, sur le modèle « [Titre de la page] en cours de consultation ». Communiquez

cette demande aux équipes techniques en charge de l’intégration du site.

La meilleure des implémentations consiste à couvrir la plus grande part d’utilisateurs, et donc :

• utiliser une couleur de fond pour signifier la page active ;

• utiliser une forme adjacente au lien, par exemple une icône (pour les utilisateurs qui

perçoivent mal ou pas les contrastes de couleurs) ; • ajouter un title sur le lien de la page active (pour les utilisateurs aveugles ou les

utilisateurs qui utilisent des feuilles de styles utilisateurs).

Page de démonstration pour la mise en évidence de la page active dans le menu de navigation

FIL D’ARIANE

Un fil d’Ariane est un moyen de navigation rapide et un repère dans le site : il doit permettre à l’utilisateur de s’orienter dans le site web.

Note : cette recommandation est de niveau AAA, elle n’est donc pas obligatoire. L’absence d’un fil d’Ariane a un impact limité. Toutefois, c’est un outil qui peut faciliter la navigation des aveugles et grands malvoyants, ainsi que des handicapés mentaux ou cognitifs.

S’il est prévu, le fil d’Ariane doit donc être représentatif de la position de la page dans l’arborescence du site. Par exemple, les pages parentes doivent y être représentées.


• Impacts utilisateurs des défauts d’accessibilité de la navigation

CRITÈRES RGAA 3• 12.1 [AA]

• 12.2 [AA]

• 12.3 [AA]

• 12.4 [AA]

• 12.5 [AA]

• 12.6 [AA]

• 12.7 [AA]

• 12.8 [AAA]

• 12.9 [AAA]

• 12.11 [A]

• 12.12 [AAA]


https://disic.github.io/guide-impacts_utilisateurs/navigation.html

https://disic.github.io/guide-integrateur/demo/2-navigation/page-active.html

https://disic.github.io/guide-integrateur/demo/2-navigation/collection.html

https://disic.github.io/guide-integrateur/demo/2-navigation/collection.html



FICHE 5 : CONSULTATION• Introduction - cas utilisateurs

• Fichiers en téléchargement

• Expressions inhabituelles ou idiomatiques, jargon

• T extes complexes



SYNTHÈSE

• Indiquer le poids, le format et la langue de chaque fichier téléchargeable.

• Créer un glossaire pour les expressions inhabituelles, les expressions idiomatiques ou le

jargon. • Proposer une alternative aux textes nécessitant un niveau de lecture avancé.


L’accessibilité des documents en téléchargement relève des mêmes enjeux que l’accessibilité d’un contenu web. Chaque document doit être correctement structuré avec des titres, des listes, etc. pour permettre aux utilisateurs de pouvoir naviguer et de se repérer aisément. Toutes les autres problématiques s’appliquent également : les descriptions d’images, les tableaux, les couleurs, les liens, etc.

L’absence d’accessibilité des fichiers en téléchargement est toujours un problème grave qui empêche l’accès à l’information. Les principaux utilisateurs impactés sont les utilisateurs aveugles, malvoyants ou ayant des difficultés de lecture.

Si votre site est accessible, mais qu’une partie de l’information est transmise à vos utilisateurs via des documents bureautiques (.doc, .pdf, etc.) non accessibles, votre contenu n’est pas accessible. Vous empêchez alors des utilisateurs d’accéder à cette information.

Par ailleurs, les expressions inhabituelles, les expressions idiomatiques et le jargon empêchent les utilisateurs handicapés mentaux de comprendre un texte, si ces éléments de langage ne sont pas définis ou accompagnés d’une alternative en langage courant.

FICHIERS EN TÉLÉCHARGEMENT

Lorsqu’un fichier en téléchargement est proposé dans une page web, il faut indiquer les informations nécessaires à sa consultation, telles que :

• le poids du fichier ;

• le format du fichier ;

• la langue du fichier, si elle diffère de la langue de la page.

La solution la plus simple et la plus accessible est d’indiquer ces données dans l’intitulé du lien qui permet de télécharger le fichier, par exemple : « Télécharger le guide du concepteur RGAA 3 (PDF, 1 Mo) ». Mais ces informations supplémentaires peuvent également se trouver dans le contexte du lien.


https://references.modernisation.gouv.fr/rgaa-accessibilite/glossaire.html#contexte-du-lien



Les documents en téléchargement doivent être accessibles, sauf si leur contenu est déjà accessible ailleurs sur le site, par exemple si le document n’est qu’une version imprimable du contenu de la page. Autrement, si les documents en téléchargement ne sont pas accessibles, ils doivent disposer d’une version alternative accessible, clairement identifiable (par exemple un lien adjacent). Il faut donc prévoir la réalisation de versions alternatives accessibles de ces documents. Par exemple, cela peut prendre la forme d’une page HTML qui reprend le contenu intégral du document téléchargeable. Il ne sera pas nécessaire de styler ces pages, dans la mesure où elles s’adressent aux utilisateurs aveugles.

EXPRESSIONS INHABITUELLES OU IDIOMATIQUES, JARGON

Les éléments de jargon et expressions inhabituelles sont un réel frein à la compréhension pour les utilisateurs handicapés mentaux s’ils ne sont pas définis ou accompagnés d’une alternative en langage courant.

Ainsi, il peut être utile de prévoir la création d’un glossaire pour lister et expliciter les expressions inhabituelles et le jargon spécifique d’un site. Ce glossaire doit être accessible depuis toutes les pages du site.

Il s’agit cependant d’un critère de niveau AAA, qui n’a pas de caractère obligatoire, bien que sa mise en œuvre puisse améliorer considérablement l’expérience des utilisateurs handicapés mentaux.

TEXTES COMPLEXES

Pour faciliter la compréhension des textes qui nécessitent un niveau de lecture plus avancé que le premier cycle de l’enseignement secondaire, on peut prévoir un certain nombres d’outils et de méthodes :

• une iconographie de soutien (illustrations ou symboles graphiques) adaptés au niveau

de lecture du premier cycle de l’enseignement secondaire ; • une version en Langue des signes (LSF). Voir un exemple de texte traduit en LSF sur

l’article « Fournitures scolaires » du site Infos-Parents du Ministère de l’Éducation nationale (activer l’option « Activer la langue des signes ») ;

• une version Facile À Lire et à Comprendre (FALC). Consulter les règles du FALC ;

• une version vocalisée du texte ;

• un résumé adapté au niveau de lecture du premier cycle de l’enseignement secondaire ;

• voire une version en écriture simplifiée (phonétique).

Important : ces alternatives demandent le recours à des prestataires spécialisés.

Ce critère est de niveau AAA : à ce titre, il n’a pas de caractère obligatoire, bien que sa mise en œuvre puisse améliorer considérablement l’expérience des utilisateurs handicapés mentaux.


• Impacts utilisateurs des défauts d’accessibilité en matière de consultation

CRITÈRES RGAA 3• 13.6 [A] • 13.9 [AAA] • 13.14 [AAA]


https://disic.github.io/guide-impacts_utilisateurs/consultation.html

http://www.unapei-lr.org/articles-6/42-101-les-regles-du-facile-a-lire-et-a-comprendre-falc/

http://infos-parents-accessibles.education.gouv.fr/pid35173/fournitures-scolaires.html

http://infos-parents-accessibles.education.gouv.fr/pid35173/fournitures-scolaires.html



CONCEPTION GRAPHIQUELa conception graphique et la conception fonctionnelle sont souvent confondues. En réalité, elles se complètent.

La conception graphique concrétise le projet défini lors de la phase de conception fonctionnelle, et la traduit en une interface graphique utilisable et attrayante. Pour cela, les concepteurs graphiques mettent au point une charte et définissent des motifs de conception qui serviront de référence lors de la création graphique des différentes pages du site.

Les décisions prises lors de la phase de conception graphique peuvent avoir des conséquences considérables en matière d’accessibilité web, en particulier en matière de couleurs et de présentation de l’information.

Les fiches suivantes ont pour objectif d’aider les concepteurs graphiques à prendre conscience des impacts utilisateurs de leurs décisions dans ces domaines, et de leur fournir des pistes concrètes pour améliorer l’accessibilité du design dont ils ont la responsabilité.

Les fiches suivantes abordent les problématiques d'accessibilité qui concernent la conception graphique dans le RGAA 3 :

• Fiche 6 : Couleurs

• Fiche 7 : Présentation

FICHE 6 : COULEURS• Introduction - cas utilisateurs

• L’information donnée par la couleur

• Contrastes



SYNTHÈSE

• Prévoir une alternative textuelle à l’utilisation signifiante de la couleur sur un texte.

• S’assurer que le contraste entre la couleur du texte et la couleur de l’arrière-plan est

suffisant. • Fournir des méthodes de personnalisation de l’interface par l’utilisateur si les contrastes

prévus par la charte graphique sont insuffisants.


Les couleurs sont une problématique importante pour les utilisateurs qui ne perçoivent pas du tout les couleurs, notamment les personnes aveugles, les grands malvoyants et les personnes ayant des déficiences de perception des couleurs (daltonisme par exemple) ou des contrastes.

Si une personne aveugle ne peut pas du tout voir les couleurs, beaucoup d’utilisateurs n’ont qu’une vision partielle ou dégradée des couleurs. Cela peut concerner une seule couleur, plusieurs couleurs ou des combinaisons de couleurs particulières.

Le déficit de perception des couleurs est très répandu et ses conséquences peuvent être désastreuses pour la perception et la compréhension des contenus et des fonctionnalités.




Or, la couleur est parfois le seul vecteur utilisé pour donner de l’information. Par exemple, dans une liste, vous avez mis en rouge les éléments obligatoires et laissé en noir les éléments optionnels. Aussi, un utilisateur qui ne peut pas voir ces couleurs n’aura pas accès à cette information. Aussi, vous devez toujours fournir un autre moyen que la couleur, de préférence textuel, pour que tous les utilisateurs, quelle que soit leur capacité de perception, puissent avoir accès à cette information.

Une autre problématique liée à la couleur concerne les contrastes. Pour un utilisateur qui a des difficultés à percevoir les contrastes, certains textes peuvent être impossibles à lire si la couleur d’écriture n’est pas suffisamment contrastée par rapport à la couleur du fond.

L’INFORMATION DONNÉE PAR LA COULEUR

Lorsqu’une information est donnée par la couleur, elle doit obligatoirement être donnée aussi par une autre méthode, par exemple par un texte qui donne la même information.

En effet, dans certains cas, l’absence d’accès à l’information donnée par la couleur a pour conséquence une perte d’information. Mais ce problème d’accessibilité rend bien souvent les contenus ou les fonctionnalités complètement inutilisables pour les utilisateurs aveugles, très malvoyants ou ceux qui perçoivent mal les couleurs.

Par exemple, on utilise souvent la couleur rouge pour signaler une erreur de saisie dans un formulaire. Or, un utilisateur aveugle, très malvoyant ou percevant mal les couleurs (daltonisme par exemple) ne percevra pas cette couleur, et passera donc à côté d’une information pourtant capitale. Cela l’empêchera même de comprendre pourquoi il ne peut pas valider le formulaire et passer à l’étape suivante.

D’autres cas typiques d’utilisation de la couleur pour véhiculer de l’information :

• une fonctionnalité de sélection multiple dans une liste d’objets : si l’objet sélectionné est

indiqué uniquement par la couleur, les utilisateurs aveugles, très malvoyants ou ne percevant pas ou mal la couleur se retrouveront dans l’incapacité d’utiliser la fonctionnalité. Dans ce cas, il faudra indiquer textuellement que l’objet est sélectionné ;

• l’indication de la page active dans un menu : si le statut actif de la page est indiqué

uniquement par la couleur, alors les utilisateurs aveugles ou qui ne perçoivent pas ou mal les couleurs ou les contrastes ne sauront pas qu’il s’agit de la page active. Dans ce cas, on pourra tout simplement ajouter dans le titre du lien une mention sur le modèle : « Accueil - page active », par exemple.

Lors du travail de conception graphique, il faut donc s’assurer que chaque mot ou ensemble de mots dont la mise en couleur est porteuse d’information, possède une alternative (par exemple textuelle) qui transmet la même information. Dans le cas de l’utilisation de motifs (par exemple hachures, pointillés…), le problème reste le même pour les utilisateurs aveugles, qui ne percevront pas la différence d’une couleur à l’autre ou d’un motif à l’autre. Il faut donc, là aussi, prévoir une alternative accessible.

Cela est également valable pour les images ou les médias porteurs d’information : cette information ne doit pas être donnée uniquement par la couleur. Par exemple, dans le cas des diagrammes, des cartes et des graphiques, il vaut mieux prévoir une légende textuelle en plus d’une légende à base de couleurs. Ainsi, il sera plus facile pour les utilisateurs ayant des problèmes de vue de comprendre l’information véhiculée par ces éléments graphiques.

Il n’existe pas de technologie d’assistance efficace pour traiter ces problèmes d’accessibilité : le rôle des concepteurs graphiques à ce sujet est donc crucial.




Important : À noter que l'utilisation d'une information donnée par la forme comme alternative à une information donnée par la couleur sera insuffisante, les utilisateurs aveugles ne voyant ni forme ni couleur.

EXEMPLE D’INFORMATION DONNÉE PAR LA COULEUR DANS UN GRAPHIQUE

Ci-dessous un exemple de graphique où l’information par la couleur est indispensable pour le comprendre. La couleur symbolise un élément et cette couleur est définie dans une légende. La meilleure alternative à cette présentation est alors de rédiger une description détaillée du graphique. Note : il est possible de traiter visuellement cette description détaillée de différentes façons : cf. Description détaillée des images porteuses d’information complexe.

Répartition de la population par taille de communes (description détaillée du graphique) :

• Les communes de moins de 1 000 habitants représentent 22,3% de la population.

• Les communes qui comptent entre 1 000 et 5 000 habitants représentent 23,5% de la

population. • Les communes qui comptent entre 5 000 et 10 000 habitants représentent 12,3% de la



population. • Les communes de plus de 50 000 habitants représentent 13,2% de la population.

EXEMPLE D’INFORMATION DONNÉE PAR LA COULEUR DANS UNE ILLUSTRATION

Sur les images, la couleur peut apporter une information. Par exemple, sur l’image ci-dessous, la couleur met en évidence la zone du cerveau concernée dans un article associé. L’information véhiculée ici est la position de la zone en question. Cette information doit se retrouver dans le texte adjacent à l’image. Par exemple, on pourra retrouver dans le texte : « Le noyau est situé à l’arrière du cerveau ».




Il est important que cette information ne soit pas uniquement présente dans le texte de remplacement de l’image. En effet, le texte de remplacement n’est bien souvent accessible qu’aux personnes qui utilisent un lecteur d’écran. Les personnes qui ont des difficultés de perception des couleurs n’utilisent pas ces logiciels et n’auront pas accès au texte de remplacement. C’est pourquoi il est important que la description de l’information donnée par la couleur soit réalisée de manière textuelle et visible.

CONTRASTES

Les contrastes de couleurs concernent le rapport de contraste entre la couleur d’écriture d’un texte et sa couleur d’arrière-plan.

Ces contrastes concernent :

• les textes HTML ;

• les textes présents dans les images ;

• les textes incrustés dans les vidéos.

Il existe des valeurs qui assurent un contraste minimum suffisant pour une large part des utilisateurs ayant des difficultés à percevoir les couleurs. Les rapports de contraste attendus varient en fonction de la taille de texte, de sa graisse et du niveau d’accessibilité visé.

Pour le niveau AA, les rapports de contraste minimaux sont les suivants :

• Rapports de contraste attendus pour du texte sans effet de graisse, niveau

AA :• si la taille du texte sans effet de graisse est inférieure à 150% de la taille de

police par défaut (ou 1.5em), le rapport de contraste entre la couleur du texte (y

compris le texte en image) et son arrière-plan doit être de 4.5:1, au moins ; • si la taille du texte sans effet de graisse est supérieure ou égale à 150% de la

taille de police par défaut (ou 1.5em), le rapport de contraste entre la couleur du

texte (y compris le texte en image) et son arrière-plan doit être de 3:1, au moins. • Rapports de contraste attendus pour du texte en gras, niveau AA :

• si la taille du texte en gras est inférieure à 120% de la taille de police par défaut

(ou 1.2em), le rapport de contraste entre la couleur du texte (y compris le texte

en image) et son arrière-plan doit être de 4.5:1, au moins ;


http://guide-concepteur.loc/glossaire.html#taille-caracteres-contraste








• si la taille du texte en gras est supérieure ou égale à 120% de la taille de police

par défaut (ou 1.2em), le rapport de contraste entre la couleur du texte (y

compris le texte en image) et son arrière-plan doit être de 3:1, au moins.

Il est possible d’améliorer encore ces contrastes grâce aux rapports de niveau AAA :

• Rapports de contraste attendus pour du texte sans effet de graisse, niveau

AAA :

◦ si la taille du texte sans effet de graisse est inférieure à 150% de la taille de police

par défaut (ou 1.5em), le rapport de contraste entre la couleur du texte (y compris le

texte en image) et son arrière-plan doit être de 7:1, au moins ;

◦ si la taille du texte sans effet de graisse est supérieure ou égale à 150% de la taille

de police par défaut (ou 1.5em), le rapport de contraste entre la couleur du texte (y

compris le texte en image) et son arrière-plan doit être de 4:5:1, au moins.

• Rapports de contraste attendus pour du texte en gras, niveau AAA :

◦ si la taille du texte en gras est inférieure à 120% de la taille de police par défaut (ou

1.2em), le rapport de contraste entre la couleur du texte (y compris le texte en

image) et son arrière-plan doit être de 7:1, au moins ;

◦ si la taille du texte en gras est supérieure ou égale à 120% de la taille de police par

défaut (ou 1.2em), le rapport de contraste entre la couleur du texte (y compris le

texte en image) et son arrière-plan doit être de 4:5:1, au moins.

OUTILS D’ÉVALUATION DE CONTRASTE

Les outils suivants vous permettront de tester vos combinaisons de couleurs et d’évaluer leur contraste :

• Colour Contrast Analyser (site et application en anglais) : application pour Windows et

MacOS qui permet de calculer le rapport de contraste entre deux codes hexadécimaux, et d’évaluer leur conformité WCAG ;

• Tanaguru Contrast Finder : un outil en ligne en français qui permet d’évaluer le contraste

entre deux couleurs et de trouver des contrastes alternatifs en cas de non-conformité ; • Contrast Ratio (en anglais) cet outil en ligne vous permet de saisir un code couleur pour

l’arrière-plan et un code couleur pour le texte, puis il calcule le rapport de contraste pour vous et vous indique le niveau WCAG atteint ;

• Colour Contrast Check (en anglais) : un outil en ligne qui permet une vérification de

contraste encore plus fine ; • Color Safe (en anglais) : une application en ligne qui permet d’expérimenter des

combinaisons de couleurs immédiatement conformes.

Important : les couleurs d’une charte graphique ne sont pas concernées par cette obligation de contraste. Ainsi, si les couleurs d’une charte graphique sont insuffisamment contrastées, la solution consiste à mettre à disposition des utilisateurs un mécanisme de personnalisation de l’interface. Voir à ce sujet Personnalisation des couleurs et contrastes.


• Impacts utilisateurs des défauts d’accessibilité en matière de couleurs


https://disic.github.io/guide-impacts_utilisateurs/couleurs.html

http://colorsafe.co/

http://colorsafe.co/

https://snook.ca/technical/colour_contrast/colour.html#fg=33FF33,bg=333333

https://snook.ca/technical/colour_contrast/colour.html#fg=33FF33,bg=333333

http://leaverou.github.io/contrast-ratio/

http://leaverou.github.io/contrast-ratio/

http://contrast-finder.tanaguru.com/

https://www.paciellogroup.com/resources/contrastanalyser/

https://www.paciellogroup.com/resources/contrastanalyser/













• Color Accessibility Workflows (en anglais)


• 3.2 [A]

• 3.3 [AA]

• 3.4 [AAA]


https://alistapart.com/article/color-accessibility-workflows

https://alistapart.com/article/color-accessibility-workflows



FICHE 7 : PRÉSENTATION• Introduction - cas utilisateurs

• Visibilité des liens par rapport au texte environnant

• Alternatives pour l’information donnée par la forme, taille et position

• Personnalisation de l’affichage

• Alignement des textes

• Interlignage

• Largeur des textes

• Personnalisation des couleurs et contrastes

• Exemple de mécanisme de personnalisation



SYNTHÈSE

• S’assurer que l’information n’est pas donnée uniquement par la forme ou la position

d’un élément. • S’assurer que les liens sont correctement identifiables.

• S’assurer que l’interlignage est suffisant.

• S’assurer que la largeur des blocs de texte n’excède pas 80 caractères.

• Donner la possibilité à l’utilisateur de contrôler la justification des textes.

• Permettre à l’utilisateur de personnaliser la couleur de texte et la couleur d’arrière-plan

lorsque les contrastes prévus par la charte graphique sont insuffisants.


La mise en forme des textes est une problématique qui touche principalement les personnes ayant des troubles cognitifs (dyslexiques par exemple).

Par exemple, un interlignage trop faible est une difficulté supplémentaire pour ces utilisateurs. Il en sera de même pour une police fantaisiste, difficile à déchiffrer. En effet, certains utilisateurs ayant des difficultés de décodage (dyslexiques notamment) ont besoin d’avoir un texte calibré d’une certaine manière, afin de ne pas encombrer la compréhension. Une mise en forme qui ne respecte pas certains standards demande un effort supplémentaire à ces utilisateurs pour décoder, au détriment de la compréhension.

VISIBILITÉ DES LIENS PAR RAPPORT AU TEXTE ENVIRONNANT

Les liens dont la nature n’est pas évidente sont des liens qui peuvent être confondus avec un texte normal non cliquable, lorsqu’ils sont signalés uniquement par la couleur et qu’ils ne sont pas soulignés.

Par exemple, dans le texte « Nouvelle grève à la SNCF », si le mot « grève » est un lien signalé uniquement par la couleur, sa nature peut être ignorée par les utilisateurs ne percevant pas la couleur et accédant au contenu CSS activées. En revanche, dans le texte « Nouvelle grève à la SNCF, lire la suite », si « lire la suite » est un lien, un utilisateur ne percevant pas les couleurs n’aura pas de problème pour en comprendre la nature.




La meilleure des solutions est de conserver le soulignement natif des liens s’ils se trouvent au sein d’un texte.

Autrement, si ces liens sont uniquement signalés par la couleur, alors vous devez vous assurer que le rapport de contraste entre la couleur du texte du lien et du texte environnant respecte un niveau minimum (3:1). La fiche « Couleurs » contient une liste d’outils d’évaluation de contrastes à votre disposition pour tester ces éléments.

De plus, si vos liens en environnement de texte sont signalés uniquement par la couleur, votre seconde obligation est de définir un état au survol et à la prise de focus, qui ne soit pas un changement de couleur : par exemple, l’apparition d’un soulignement ou d’une forme.

ALTERNATIVES POUR L’INFORMATION DONNÉE PAR LA FORME, TAILLE ET POSITION

Comme pour les couleurs (cf. Fiche 6 : Couleurs), l’absence d’une alternative à une information donnée par la forme, la taille ou la position peut rendre un processus inutilisable ou un contenu incompréhensible pour les aveugles et les grands malvoyants.

Exemples d’indications données par la forme, la taille ou la position :

• indication donnée par la position : présence d’un marqueur visuel, pour indiquer la page

active dans un menu de navigation ; • indication donnée par la forme : mise en avant-plan pour indiquer un onglet actif ;

• indication donnée par la taille : modification de la taille de police dans un nuage de tags ;

• ou tout autre effet graphique similaire.

Pour toute information donnée par la forme, la taille ou la position dans un texte, une image, un média temporel ou non temporel, il faut s’assurer qu’il existe un autre moyen d’accéder à cette information, et que cet autre moyen est pertinent, c’est-à-dire qu’il permet de transmettre l’information dans tous les contextes de consultation et pour tous les utilisateurs.

Pour en savoir plus, vous pouvez consulter la fiche Informations par la forme et la couleur contenue dans le Guide de l’intégrateur RGAA 3.

PERSONNALISATION DE L’AFFICHAGE

Important : les recommandations ci-dessous ne relèvent pas du niveau minimum légal français. Il s’agit de recommandations de niveau AAA qui permettent l’accès à l’information à certains utilisateurs. Certaines sont parfois difficiles à mettre en œuvre. Elles restent malgré cela des recommandations importantes, voire indispensables, pour l’accès à l’information de certains utilisateurs.

Sachez donc que certaines des recommandations suivantes peuvent être atteintes en mettant en place des systèmes de configuration à disposition des utilisateurs. Par exemple, vous pouvez proposer un bouton sur votre site qui permettra de retirer toutes les justifications de texte, ou un bouton pour augmenter les interlignages. Rapprochez-vous de l’équipe technique en charge de votre site pour en savoir davantage sur ces mécanismes de personnalisation. Vous pouvez également voir un exemple de mécanisme de personnalisation plus loin dans cette page.



https://disic.github.io/guide-integrateur/10-infos-forme-couleur.html



ALIGNEMENT DES TEXTES

Afin de conserver un espacement entre les mots qui reste constant, il est recommandé de ne pas justifier les textes. En effet, justifier un texte va modifier tous les espacements entre les mots, rendre ces espacements différents à chaque fois, et perturber la lecture et la compréhension des utilisateurs qui présentent des troubles de la lecture. Pour ces utilisateurs, il est préférable de conserver un espacement constant et donc de ne pas justifier les textes.

Cependant, la justification n’est pas interdite : il faut juste avoir conscience qu’elle peut perturber la lecture et la compréhension du texte chez certains utilisateurs.

Il est possible de donner la possibilité à l’utilisateur de désactiver la justification des textes présents sur un site, grâce à une barre d’outils spécialisée.

INTERLIGNAGE

Il est préférable d’avoir un interlignage suffisamment large. On demande à ce que l’interlignage, c’est à dire l’espace entre les lignes et les paragraphes, soit au moins équivalent à 1,5 fois la taille du texte.

Faute de quoi, on peut prévoir un mécanisme qui permet d’augmenter la valeur de l’interligne à 1,5 fois la taille du texte, au moins.

LARGEUR DES TEXTES

Pour certains utilisateurs déficients visuels utilisant des loupes d’écrans ou ne disposant pas de visions centrale ou périphérique, une largeur de texte trop importante est très gênante pour la lecture.

On considère qu’une largeur de 80 caractères est la limite au-delà de laquelle les difficultés de lecture deviennent trop importantes.

Cette problématique est très difficile à prendre en charge sur une maquette habituelle et peut nécessiter de mettre en place des dispositifs de recomposition de la page, par exemple afficher le site sur une seule colonne de largeur maximale de 80 caractères.

Si le site est responsive, le mécanisme peut constituer à simuler sur un écran large l’affichage du site comme sur un mobile par exemple.

PERSONNALISATION DES COULEURS ET CONTRASTES

Dans la Fiche 6 : Couleurs, nous avons vu que le contraste doit être suffisant entre la couleur de texte et la couleur d’arrière-plan des textes d’un site.

Cependant, les couleurs d’une charte graphique ne sont pas concernées par cette obligation de contraste. Ces couleurs et contrastes immuables peuvent toutefois poser des problèmes de lisibilité.

Ainsi, si les couleurs d’une charte graphique sont insuffisamment contrastées, la solution consiste à mettre à disposition des utilisateurs un mécanisme de personnalisation de l’interface. Dans l’idéal, ce mécanisme permettra :

• de renforcer les contrastes ;

• d’inverser les contrastes : par exemple en proposant une feuille de style passant le

texte en jaune clair et les arrière-plans en bleu foncé ;




• de laisser l’utilisateur sélectionner la couleur de texte et la couleur d’arrière-plan de son

choix, et de mémoriser cette préférence à l’aide d’un cookie par exemple.

EXEMPLE DE MÉCANISME DE PERSONNALISATION

Sur le site Infos-Parents, une barre d’outils intitulée « Paramètres d’accessibilité » permet de modifier le contraste entre la couleur de texte et la couleur d’arrière-plan du site, la police d’écriture, l’interlignage, mais permet également de sélectionner des couleurs personnalisées.


• Impacts utilisateurs des défauts d’accessibilité en matière de présentation

• Impacts utilisateurs des défauts d’accessibilité en matière de liens


• 10.8 [AAA]

• 10.9 [AAA]

• 10.11 [AAA]

• 10.12 [AAA]

• 10.14 [A]


https://disic.github.io/guide-impacts_utilisateurs/liens.html

https://disic.github.io/guide-impacts_utilisateurs/presentation.html

http://infos-parents-accessibles.education.gouv.fr/



CONCEPTION MULTIMÉDIALa conception multimédia pour le web est en plein essor, grâce à la démocratisation des outils de création de contenus vidéo et audio.

Les concepteurs multimédia professionnels sont des architectes produit, qui mettent au point le déroulement, la navigation, l’arborescence et l’ergonomie du média sur lequel ils travaillent. Ils veillent à ce que ce média soit facile et agréable à utiliser.

Afin de produire des contenus multimédia accessibles, il faut tenir compte en amont d’un certain nombre de critères d’accessibilité. Certains sont faciles à mettre en œuvre (par exemple, ajouter un titre avant l’insertion d’une vidéo ou d’un podcast dans une page web) ; d’autres exigent d’être prévues et préparées en amont (par exemple, traduire en Langue des Signes française (LSF) le contenu d’une vidéo).

La prise en compte et l’application de ces critères permet aux personnes handicapées – en particulier les aveugles, malvoyants, sourds, malentendants, ainsi que les handicapés moteur – de comprendre et d’interagir facilement avec les différents types de médias. Pour ces personnes en effet, l’accès à la lecture des vidéos diffusées sur le web peut s’avérer être un vrai parcours du combattant faute d’alternatives accessibles mises à leur disposition (sous-titres, transcription textuelle, audiodescription, etc.).

Les fiches suivantes abordent les problématiques d'accessibilité qui concernent la conception multimédia dans le RGAA 3 :

• Fiche 8 : Multimédia

FICHE 8 : MULTIMÉDIA• Introduction - cas utilisateurs

• Identifier le média

• Permettre la compréhension d’un média sans le son

• Permettre la compréhension d’un média sans l’image

• Médias non temporels


• Voir aussi

• Critères RGAA

• Note concernant les niveaux de conformité

SYNTHÈSE

• Faire précéder tous les médias d’un titre.

• Accompagner chaque vidéo d’une transcription textuelle ou d’une audiodescription

synchronisée. • Fournir des sous-titres synchronisés pour chaque vidéo.

• S’assurer que les dialogues sont suffisamment audibles.

• Accompagner chaque vidéo d’une traduction en langue des signes si possible.

• Ne pas déclencher de média automatiquement.

• Fournir un lien clairement identifié permettant d’accéder à l’alternative accessible des

médias non temporels.





La majeure partie des contenus multimédias que vous rencontrerez sont des vidéos (avec ou sans bande-son) ou des fichiers sons.

Entrent également dans la catégorie de contenus multimédias, les éléments interactifs comme les animations ou publicités en Flash par exemple.

Tous les utilisateurs sont impactés par cette thématique puisque tous les sens sont sollicités dans la plupart des vidéos : la vue pour voir les images et les actions à l’écran, l’ouïe pour entendre les paroles et la motricité pour arrêter ou relancer la vidéo.

La grande majorité des critères de la thématique « Multimédia » du RGAA 3 se concentrent sur les alternatives mises à disposition des utilisateurs (sous-titres, transcription textuelle, audiodescription…), qui doivent être prévues lors de la phase de conception du site.

D’autres critères concernent les composants interactifs permettant de contrôler les contenus multimédias (les boutons de lecture, pause, volume, etc.). Ces problématiques seront traitées dans un futur guide à destination des développeurs.

IDENTIFIER LE MÉDIA

Lorsque vous insérez du contenu multimédia dans une page web, vous devez l’identifier, le mieux étant de le faire précéder d’un titre.

Ce titre peut reprendre celui de l’élément lui-même s’il en possède un. Il doit permettre de comprendre quelle est l’information présentée dans ce contenu. Tout élément multimédia doit être considéré comme un contenu à part entière et donc être structuré par un titre. Nous vous renvoyons à la fiche « Les titres, ou le plan de la page » du guide Contribuer sur le web de manière accessible pour la mise en place de ce titre.

PERMETTRE LA COMPRÉHENSION D’UN MÉDIA SANS LE SON

SOUS-TITRES

Il ne faut pas confondre le sous-titrage pour la traduction (subtitles) et le sous-titrage pour sourds et malentendants (closed captions). Ces deux types de sous-titrage poursuivent des buts différents. Dans le cadre du RGAA 3.0, les sous-titres doivent être rédigés dans la langue du média concerné. Ainsi, si la vidéo est en anglais par exemple, les sous-titres doivent être en anglais.

Les sous-titres ne concernent que les vidéos. Ils doivent reprendre toutes les informations descriptives de la vidéo : les dialogues de personnages, la voix-off ou même un bruit qui donne un sens et qui permet de comprendre une action.

Les sous-titres doivent êtres correctement synchronisés. En outre, ils doivent être activables et désactivables depuis le lecteur. Si le lecteur ne propose pas cette fonctionnalité, alors il est possible de mettre deux vidéos à disposition : une vidéo sans les sous-titres et une vidéo avec les sous-titres. Chacune peut être placée sur une page différente, l’important est que l’utilisateur comprenne aisément qu’il existe une version avec les sous-titres. Le plus simple sera alors de créer un lien avant la vidéo sans les sous-titres qui mène vers la vidéo avec les sous-titres et au-dessus de la vidéo avec les sous-titres, créer un lien qui ramène vers la vidéo sans les sous-titres.


http://disic.github.io/guide-contribuer_accessible/titres.html



Ci-dessous, un exemple de vidéo avec des sous-titres. Retrouvez cet exemple sur le site de la Direction de l'Accessibilité SNCF.

Important : les incrustations de texte et les sous-titres sont soumis aux mêmes exigences que les textes en matière de contrastes. Référez-vous au chapitre « Contrastes » de la fiche 6 : Couleurs pour en savoir plus. De même, en France, des normes en matière de code couleur existent pour les sous-titres pour personnes sourdes et malentendantes.

PENSEZ À LA LANGUE DES SIGNES (LSF)Les sous-titres ne sont pas forcément une alternative suffisante pour les personnes malentendantes. En effet, certaines personnes sourdes ou malentendantes ne lisent et ne comprennent que la langue des signes. C’est pourquoi prévoir en amont une traduction du contenu audio en LSF constitue une alternative complémentaire de haute qualité.

Dans ce cas, la traduction en LSF doit être accolée à la vidéo, même pour les vidéos diffusées en direct. Vous pouvez voir un exemple de vidéo traduite en LSF : pour cela, il faut activer l’option « Afficher la version avec langue des signes » dans le lecteur vidéo.

TRANSCRIPTION TEXTUELLE

La transcription textuelle concerne les vidéos et les fichiers audios seuls.


http://www.fiphfp.fr/Temoignages/Temoignages-d-agents/Martine-Rahal

http://www.accessibilite.sncf.com/actualites/a-la-une/article/video-sncf-24-24-sur-acces-plus

http://www.accessibilite.sncf.com/actualites/a-la-une/article/video-sncf-24-24-sur-acces-plus



Une transcription textuelle est la retranscription en texte de tous les contenus audibles et informatifs de la vidéo. Elle reprend :

• la totalité de ce qui y est exprimé oralement ;

• toutes les informations descriptives nécessaires à une compréhension équivalente de

l’action.

Ces informations textuelles doivent être présentées dans l’ordre chronologique de leur apparition dans la vidéo.

Une transcription textuelle est un contenu texte structuré, comme tout autre contenu texte. Selon les besoins, n’hésitez pas à utiliser les listes, les titres, etc.

Mise à disposition de la transcription textuelleLa mise à disposition pour les utilisateurs de cette transcription textuelle peut se faire de plusieurs manières :

• elle peut être située juste en dessous de la vidéo elle-même, en précisant de quoi il

s’agit ; • elle peut également être située dans une autre page que celle de la vidéo. Il suffit alors

de placer un lien sous la vidéo qui mène vers cette page.

Ci-dessous, un exemple de transcription textuelle située directement sous la vidéo (Retrouvez cet exemple sur le site du FIPHFP).


http://www.fiphfp.fr/Temoignages/Temoignages-d-agents/Lionel-Scarlatti

http://www.fiphfp.fr/Temoignages/Temoignages-d-agents/Lionel-Scarlatti



Cas des vidéos diffusées en directPour les vidéos diffusées en direct, il convient de mettre à disposition de l’utilisateur soit des sous-titres synchronisés, soit une transcription textuelle. Celle-ci doit être accessible de la même façon que toute autre transcription textuelle de vidéo (cf. Mise à disposition de la transcription textuelle).

PERMETTRE LA COMPRÉHENSION D’UN MÉDIA SANS L’IMAGE

AUDIODESCRIPTION

L’audiodescription ne concerne que les vidéos.

Une audiodescription est une narration ajoutée à la piste sonore de la vidéo pour décrire les détails visuels importants qui ne peuvent être compris à partir de la piste sonore principale seulement.

L’audiodescription d’une vidéo fournit de l’information à propos des actions, des personnages, des changements de scènes, du texte apparaissant à l’écran et d’autres contenus visuels (par exemple, les mimiques signifiantes, comme quelqu’un qui approuverait de la tête en silence). Vous pouvez écouter un exemple de vidéo audiodécrite : pour cela, il faut activer l’option « Activer l’audio description » dans le lecteur vidéo.

Lorsque toute l’information de la vidéo est déjà donnée dans la piste audio, aucune audiodescription supplémentaire n’est requise. Par exemple, dans le cadre d’une interview, il est facile d’éviter le besoin d’audiodescription en annonçant le nom et la fonction des interlocuteurs, qui sont souvent repris en cartouche visuellement. Si ce besoin de description sonore est anticipé, l’audiodescription peut devenir superflue. Prendre en compte ce besoin en conception est moins coûteux, alors pensez-y !

L’audiodescription doit être synchronisée avec la vidéo, et comme les sous-titres, elle doit pouvoir être activée et désactivée.


http://www.fiphfp.fr/Temoignages/Temoignages-d-agents/Martine-Rahal



VOLUME DES DIALOGUES

Dans le cas de fichiers sons seuls, vous devez veiller à ce que les dialogues soient suffisamment audibles. Plusieurs solutions sont possibles si ce n’est pas le cas :

• votre lecteur permet de désactiver l’arrière-plan sonore ;

• il existe une version alternative de la vidéo sans l’arrière-plan sonore ou avec un volume

des dialogues plus élevés.

PAS DE LANCEMENT AUTOMATIQUE

Vous devez éviter au maximum de lancer les contenus multimédia qui comportent du son automatiquement au chargement de la page. Ces paramètres existent souvent pour les vidéos que l’on intègre : or, même si on donne à l’utilisateur la possibilité de désactiver le son, il est préférable de ne pas rendre la lecture automatique.

MÉDIAS NON TEMPORELS

Par « médias non temporels », le RGAA désigne des médias créés avec des technologies différentes de HTML, CSS et JavaScript. Il s’agit en général d’animations ou d’activités interactives réalisées à l’aide d’une technologie qui nécessite une extension comme Flash, Java ou Silverlight.

Les exigences en matière d’accessibilité web pour les médias non temporels dépendent de la technologie que vous allez utiliser pour les produire :

• médias non temporels produits avec Flash ou Java : une alternative est nécessaire. En

effet, même si de nombreux standards d’accessibilité permettent en théorie de rendre un média Flash accessible, des utilisateurs ayant recours à des modes d’interaction très spécifiques ne réussiront jamais à l’utiliser.

• médias non temporels produits avec Silverlight : une alternative peut être nécessaire.

Note : les médias produits avec svg ou canvas ne sont pas considérés comme des médias non

temporels. En effet, ce sont des médias avec lesquels on utilise généralement JavaScript, qui est une technologie parfaitement accessible.

Pour chaque média non temporel, il est demandé à ce qu’une alternative accessible soit fournie. Une alternative accessible permet par exemple de s’assurer qu’un utilisateur qui ne peut pas utiliser de souris et qui navigue uniquement à l’aide du clavier puisse réaliser les mêmes actions qu’un utilisateur valide. Nous vous renvoyons au guide impacts utilisateurs des médias non temporels pour en savoir plus.

L’utilisateur doit pouvoir atteindre l’alternative au média non temporel à l’aide d’un lien présent sur la même page. Ce lien devra être clairement identifiable et situé à proximité du contenu, et devra mener à l’alternative accessible. Cette alternative peut être contenue soit dans la page elle-même (le lien sera alors une ancre), soit dans une autre page.


• Impacts utilisateurs des défauts d’accessibilité en matière de multimédia

• « Fiche 4 : Du multimédia pour tous et toutes » du guide Contribuer accessible sur le

web de manière accessible.


http://disic.github.io/guide-contribuer_accessible/multimedia.html

https://disic.github.io/guide-impacts_utilisateurs/multimedia.html

https://disic.github.io/guide-impacts_utilisateurs/multimedia.html#non-temporels

https://disic.github.io/guide-impacts_utilisateurs/multimedia.html#non-temporels



VOIR AUSSI

• Des exemples de vidéos accessibles sur le site du FIPHFP

• Bonnes pratiques pour l’accessibilité des vidéos (Sur le site de l’Unité ingénierie des

contenus et savoirs) • Bonnes pratiques pour l’accessibilité des fichiers sons (Sur le site de l’Unité ingénierie

des contenus et savoirs) • Charte relative à la qualité du sous-titrage à destination des personnes sourdes ou

malentendantes - Décembre 2011


• 4.3 [AA]

• 4.5 [AA]

• 4.7 [AA]

• 4.9 [AAA]

• 4.15 [A]

• 4.16 [A]

• 4.18 [A]

• 4.19 [AAA]

NOTE CONCERNANT LES NIVEAUX DE CONFORMITÉ

Selon le niveau de conformité au RGAA 3.0, les recommandations en termes d’accessibilité ne sont pas les mêmes pour les éléments multimédias de type vidéo ou audio. Ci-dessous nous résumons brièvement les exigences concernant cette problématique. Ce résumé ne remplace pas les recommandations énoncées dans le référentiel, auquel nous vous renvoyons pour plus de détails : critères de la thématique multimédia du RGAA 3.0.

• Niveau A :

• une transcription textuelle ou une audiodescription ;

• des sous-titres synchronisés.

• Niveau AA :

• une transcription textuelle ;

• des sous-titres synchronisés ;

• une audiodescription synchronisée.

• Niveau AAA :

• une transcription textuelle ;

• des sous-titres synchronisés ;

• une audiodescription ;

• une audiodescription étendue synchronisée ;

• une interprétation en langue des signes.


https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#multimedia

http://www.csa.fr/Television/Le-suivi-des-programmes/L-accessibilite-des-programmes/Charte-relative-a-la-qualite-du-sous-titrage-a-destination-des-personnes-sourdes-ou-malentendantes-Decembre-2011

http://www.csa.fr/Television/Le-suivi-des-programmes/L-accessibilite-des-programmes/Charte-relative-a-la-qualite-du-sous-titrage-a-destination-des-personnes-sourdes-ou-malentendantes-Decembre-2011

http://ics.utc.fr/capa/DOCS/SP4/Tuto/02/co/02-CAPA_BonnesPratiques_11.html




http://www.fiphfp.fr/Temoignages/Temoignages-d-agents



GLOSSAIRE

ATTRIBUT TITLEL’attribut HTML title peut s’utiliser sur tout élément HTML, mais on le croise plus souvent sur

les liens et les abréviations. Il apporte une information complémentaire relative à l’élément concerné. Cet attribut se caractérise par l’apparition d’une infobulle native au survol de cet élément.

LECTEUR D’ÉCRAN

Un lecteur d’écran est un logiciel utilisé principalement par les personnes ayant des déficiences visuelles (personnes malvoyantes ou aveugles) ou des déficiences cognitives (dyslexie par exemple). Un lecteur d’écran parcourt le code d’un logiciel ou d’un site web et retranscrit vocalement (à l’aide d’une synthèse vocale) et/ou vers une plage braille le contenu et sa structure.

Un lecteur d’écran permet autant de naviguer sur le web, que d’utiliser un ordinateur ou tout autre logiciel.

JUSQU’À OU À PARTIR DE 150% (1.5EM) DE LA TAILLE DE POLICE PAR DÉFAUT SANS EFFET DE GRAISSE. JUSQU’À OU À PARTIR DE 120% (1.2EM) DE LA TAILLE DE POLICE PAR DÉFAUT EN GRAS.D’après le RGAA 3, ces deux mesures déterminent la taille relative des caractères correspondant à une taille de caractères équivalent à 14 points gras ou 18 points sans effet de graisse en considérant que la police de corps (body) est à 100%.

Note : « jusqu’à 150% et jusqu’à 120% » signifie que la taille des caractères est strictement inférieure à 150 ou 120%. « À partir de 150% et à partir de 120% » signifie que la taille des caractères est égale ou supérieure à 150 ou 120%.

La taille de police par défaut est la taille définie par l’auteur pour le document ou, en son absence, la taille par défaut utilisée par l’agent utilisateur (ie le navigateur).

MAQUETTE FONCTIONNELLE - WIREFRAME

Une maquette fonctionnelle (wireframe en anglais) est un schéma utilisé pendant la conception d’une interface pour définir les zones et composants qu'elle doit contenir. Cette maquette fonctionnelle servira de référence au travail de production graphique et technique. Une maquette fonctionnelle peut prendre la forme d’un croquis, d’un collage ou d’un schéma numérique.

TEXTE DE REMPLACEMENT

Le texte de remplacement d’une image est un texte non visible lors d’une consultation d’un site sans technologie d’assistance. Ce texte de remplacement est vocalisé par un lecteur d’écran et permet aux utilisateurs présentant une déficience visuelle d’accéder au contenu de l’image.



Guide du concepteur RGAA 3 - GitHub Pages...Guide du concepteur RGAA 3 – juillet 2017 • Voir...

Documents

Transcript of Guide du concepteur RGAA 3 - GitHub Pages...Guide du concepteur RGAA 3 – juillet 2017 • Voir...