Bakh’ RGAA


Contexte

À lire

  • Prenez 5mn pour mieux comprendre la question de l’accessibilité numérique si ce n’est pas encore fait (site Bakhtech section Hello’ Accessibilité)
  • Prenez 5mn pour naviguer comme un aveugle avec un lecteur d’écran comme ChromeVox par exemple. Faites le au moins sur votre téléphone, les lecteurs d’écran sont souvent plus facile à prendre en main sur mobile que sur desktop VoiceOver (iOS) (Ouvre un nouvel onglet), Talkback (Android) (Ouvre un nouvel onglet)
  • Prenez 2mn pour naviguer au clavier. Profitez en pour constater certains problèmes listés par cet audit en rapport avec ce mode de navigation (le cas échéant).
  • Ces 3 premiers points sont essentiels pour comprendre l’accessibilité numérique et constatés par soi même les impacts sur un utilisateur en situation de handicap. Cette prise en main des outils d’assistance vous sera aussi utile pour tester et valider vos corrections.

Recommandations

Filtres pour afficher les critères pertinents pour SEO ou Facile à résoudre

  • Les images porteuses d’information doivent avoir une alternative textuelle pertinente
  • Privilégier les textes stylés à la place d’image porteuse d’information
  • Les images décoratives doivent être ignorées (alt = “”)
  • Privilégier d’autre alternative qu’une image pour les CAPTCHA, sinon une alternative textuelle ou un contenu alternatif pertinent doit être proposé
  • Si l’image a une légende bien la relier à celle-ci
En savoir plus

Html, CSS et JS concernés

  • Html (balises) : , ,
    ,
  • Html (propriétés) : alt, longdesc, title
  • ARIA : aria-describedby, aria-label, aria-labelledby

Code


			
			
			alternative_textuelle_pertinente
			
			..
			
			
			
			
			
			
			
			
			
			
			
legende

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Quand une image a une légende il faut ajouter une alternative textuelle
  • Pour les svg utiliser une de ces alternatives (aria-label, aria-labelledby, figcaption)
  • Logo, dénomination commerciale

  • Chaque cadre (<iframe>) utilisé doit avoir un titre pertinent
En savoir plus

Html, CSS et JS concernés

  • Html (balises) :
  • Html (propriétés) :title

Code


				
				
				

			

En savoir plus

Html, CSS et JS concernés

  • CSS : color, background, background-color

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Non concerné par les critères de contraste de couleur : Logo, dénomination commerciale
  • Pour corriger les contrastes de couleur une alternative serait d’ajouter un bouton permettant d’inverser les couleurs ou de renforcer les contrastes sur l’ensemble du site en un clique. Celui ci peut être ajouté dans la page accessibilité qui sera ajouté par la suite.

Au delà des normes :

  • Les médias doivent avoir :
    • Une transcription textuelle adjacente ou accessible via un lien ou bouton adjacent ou des sous-titres synchronisés pour être accessibles aux personnes ayant un handicap auditif (si nécessaire)
    • Une transcription textuelle ou une audiodescription adjacente accessible via un lien ou bouton adjacent pour être accessibles aux personnes ayant un handicap visuel (si nécessaire)
  • Chaque son de plus de 3 secondes déclenché automatiquement doit être contrôlable par l’utilisateur (bouton stop, mute ou volume spécifique)
  • Chaque média doit être consultable au clavier, par tout dispositif de pointage et technologies d’assistance.
En savoir plus

Html, CSS et JS concernés

  • Html (balises) : , , , , ,
  • Html (propriétés) : kind

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Le média est utilisé comme CAPTCHA ou test
  • Le média est décoratif

  • Savoir différencier ces 3 types de tableau
    • tableau de données (avec la mise en page et la sémantique associée à un tableau)
    • tableau de données complexes (avec des en-têtes pas uniquement réparties sur la première ligne et/ou la première colonne)
    • Tableau de mise en forme (avec la mise en page mais pas la sémantique associée à un tableau)
  • Chaque tableau de données complexe doit avoir un résumé pertinent
  • Chaque tableau de mise en forme offre un contenu linéarisé compréhensible. La balise <table> possède un attribut role=”presentation”
  • Chaque titre de tableau doit être pertinent et bien associé à ce dernier
  • Chaque tableau de données doit avoir ses en-têtes de lignes et de colonnes bien déclarées. Chaque cellule doit être bien associée à ses en-têtes.
  • Chaque tableau de mise en forme ne doit pas utiliser d’éléments propres aux tableaux de données
En savoir plus

Html, CSS et JS concernés

  • Html (balises) : <table>, <th>, <td>, <tbody>, <thead>
  • Html (propriétés) : title, scope, headers
  • ARIA : role="presentation"

Code


				
				 ... 
résumé pertinent
Les handicaps concernés par l'accessibilité numérique
Type de handicap Pourcentage de la population
Visuels 4,3%
Moteurs 5,8%
Auditifs 13,2%
Mentaux 1,6%

  • Les composants d’interface (importants) fonctionnant grâce à un script doivent être totalement contrôlables (utilisables) par les technologies d’assistance, le clavier et tout dispositif de pointage. Les informations suivantes en particulier : nom, role, valeur, paramétrage et changements d’état du composant. À défaut une alternative pertinente et fonctionnelle avec ces outils doit être proposée.
  • Les messages de statut doivent être correctement restitués aux technologies d’assistance
En savoir plus

Html, CSS et JS concernés

  • Html (balises) :
  • Html (propriétés) : tabindex
  • ARIA : role, aria-*

Code


			
			...
			
			...  ...
			
			...  ...
			...
			...  ...
			...

			
			

Contenu de l’onglet 1

Contenu de l’onglet 2

...
  • Utilisateur 1
  • Utilisateur 2
  • Utilisateur 3

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Il existe une gestion de cas particulier lorsque la fonctionnalité dépend de l’utilisation d’un gestionnaire d’événement sans équivalent universel ; par exemple, une application de dessin à main levée ne pourra pas être rendue contrôlable au clavier. Dans ces situations, le critère est non applicable.

Au delà des normes :

  • Dans certains cas, il peut être intéressant de vouloir faire parler le lecteur d’écran sans pour autant afficher du texte à l’écran, par exemple pour annoncer le nombre de résultats trouvé après l’appui sur le bouton rechercher. (Voir code ci dessus)

  • Le type de document (doctype) doit être précisé, celui ci doit être valide et le code source généré conforme. À placer avant la balise <html> dans le code source
  • Dans chaque page web préciser la langue par défaut avec un code de langue valide
  • Préciser les changements de langue présents dans la page et ainsi que les changements de sens de lecture.
  • Dans chaque page web, ajouter un titre pertinent
  • Dans chaque page web, les balises ne doivent pas être utilisées uniquement à des fins de présentation (à l’exception de <div>, <span> et <table>)
En savoir plus

Html, CSS et JS concernés

  • Html (balises) : DOCTYPE
  • Html (propriétés) : lang, dir

Code


				<!-- Préciser le doctype et cela avant la balise html -->
				<!DOCTYPE html>
				<html>...</html>
				<!-- Préciser la langue par défaut -->
				<html lang="fr"...></html>
				<!-- Préciser le titre de la page -->
				<title> titre_pertinent_de_la_page </title>
				<!-- Changement de langue -->
				<div lang="en"> part of the text in english </div>
				<!-- Changement de sens de lecture, si un passage du texte est en arabe ou en hébreux par exemple -->
				<div> Texte en français</div>
				<div dir="rtl">النص باللغة العربية </div>
			

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Pour accompagner la prise en charge progressive de HTML par les navigateurs, les APIs d’accessibilité et les technologies d’assistance, certains critères peuvent exiger la présence d’attributs ou de balises déclarés « obsolètes » en HTML
  • Nom propre
  • Nom commun

  • Utiliser impérativement des balises <hx> pour les titres, avec des valeurs pertinentes
  • Commencer par un <h1> et éviter les trous (passer de <h1> à <h4> par exemple)
  • Refléter la hiérarchie du contenu par une utilisation pertinente des balises <hx>
  • Utiliser <header> pour la zone d’en-tête de la page, <nav> pour les zones de navigation principales et secondaires, une balise <main> unique et visible pour la zone de contenu principal et <footer> pour la zone de pied de page (non applicable quand le doctype n’est pas HTML5)
  • Pour les listes utiliser impérativement une liste (<ul> et <li> ; role=”list” et “listitem”)
  • Utiliser impérativement <q> et <blockquote> respectivement pour chaque citation courte ou chaque bloc de citation
En savoir plus

Html, CSS et JS concernés

  • Html (balises) : <h1> à <h6>, <nav>, <main>, <footer></footer>, <ul>, <li>, <q>, <blockquote>
  • ARIA : role="heading" aria-level="x" ; role="list" et role="listitem"

Code


				

Les grandes métropoles françaises

..

Ile De France

Paris

Seine Saint Denis

PACA

....
...

Cas particuliers – Notes techniques – Exceptions à la règle :

  • La balise <main> peut être utilisée plusieurs fois dans le même document HTML. Néanmoins, il ne peut y avoir en permanence qu’une seule balise visible et lisible par les technologies d’assistances, les autres devant disposer d’un attribut hidden ou d’un style permettant de les masquer aux technologies d’assistances. À noter cependant que l’utilisation d’un style seul restera insuffisant pour assurer l’unicité d’une balise <main> visible en cas de désactivation des feuilles de styles.
  • Les attributs WAI-ARIA role=”list” et “listitem” peuvent nécessiter l’utilisation des attributs WAI-ARIA aria-setsize et aria-posinset dans le cas où l’ensemble de la liste n’est pas disponible via le DOM généré au moment de la consultation.
  • Les attributs WAI-ARIA role=”tree”, “tablist”, “menu”, “combobox” et “listbox” ne sont pas équivalents à une liste HTML <ul> ou <ol>.
  • Dans les sections fixes de la page, par exemple le footer, les niveaux de titre ne doivent pas changer en fonction des niveaux de titre dans la zone de contenu. Dans ces cas, la cohérence entre les pages est plus importante.

Au delà des normes :

  • Outil pour checker la conformité avec le doctype : W3C Markup Validation Service
  • S’il y a plusieurs nav ou role=”navigation” sur la page avec des liens différents pour chaque, chacun devrait avoir un label unique (via aria-label ou aria-labelledby) Ex :

  • Les feuilles de style ne doivent être utilisées qu’à des fins de présentation, les balises utilisées ne doivent pas être présentes dans le code source généré
  • Le contenu visible doit le rester, il doit aussi être compréhensible même si on désactive totalement les feuilles de style
  • Le contenu doit rester lisible après un zoom à 200% des caractères
  • Les déclarations des couleurs foreground et background doivent être égal ou supérieur au seuil de contraste exigé (Contrast checker)
  • Chaque lien dont la nature n’est pas évidente doit être visible par rapport à son environnement
  • La prise de focus par un élément doit être visible
  • Les contenus cachés doivent aussi être ignorés par les technologies d’assistance
  • Ne donner aucune information uniquement avec la forme, la taille ou la position
  • Pour une fenêtre de 320px de largeur ou 256px de hauteur les contenus sont présentés sans avoir besoin d’un scrolling vertical si le sens de lecteure est horizontal d’un scrolling horizontal si le sens de lecture est vertical
  • L’utilisateur peut redéfinir les propriétés d’espacement du texte sans perte de contenu ou de fonctionnalité (Outil de vérification)
  • les contenus additionnels apparaissant à la prise de focus ou au survol d’un composant d’interface doivent être contrôlables par l’utilisateur
  • les contenus additionnels apparaissant via les styles CSS uniquement doivent être rendus visibles au clavier et par tout dispositif de pointage
En savoir plus

Html, CSS et JS concernés

  • Html (balises) : a, button
  • Html (propriétés) : onmouseover, onfocus
  • CSS : color, background, background-color, hover, focus
  • JS : onmouseover, onfocus
  • ARIA : role="button", role="tab"

Code


					
					
				

				/*rendre le focus visible sur les éléments pouvant le recevoir*/
				*:focus{
					outline: 3px solid black !important;
				}

				/* Vérifier que l’utilisateur peut redéfinir les propriétés d’espacement - (Il ne doit pas y avoir de perte de contenu ou de fonctionnalité après application de ces propriétés css)->
				*/
				{
					line-height: 1.5 !important;
					letter-spacing: 0.12em !important;
					word-spacing: 0.16em !important;
				}

			

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Dans le cas des textes en image et des sous-titres de vidéo le critère sur la lisibilité du contenu après zoom à 200% n’est pas applicable
  • Le critère sur l’absence scrolling lorsque la taille de la fenêtre est réduite n’est pas applicables sur les images, graphiques, vidéos, jeux, présentations, tableaux de données, interface où il est nécessaire d’avoir un ascenseur horizontal lors de la manipulation de l’interface et navigateurs mobiles
  • Le critère sur les propriétés d’espacement du texte n’est pas applicable sur les sous-titres directement intégrés à une vidéo, les images texte, le texte au sein d’une balise canvas
  • Le critère sur les contenu additionnel n’est pas applicable dans le cas d’un contenu généré par l’attribut “title”, une fenêtre ayant un role=”dialog”, ou si le le contenu additionnel ne masque ou ne remplace aucun contenu porteur d’information (il doit néanmoins rester accessible au clavier)

Au delà des normes :

  • Conseils pour le support de l’agrandissement du texte : Utilisez un design responsive pour optimiser la mise en page de votre page pour des écrans de différentes tailles. Dans la mesure du possible, utilisez des unités de tailles relatives (ex: pourcentages, em..) plutôt que fixes (ex: px, pt…). Évitez tout particulièrement de limiter la hauteur d’un conteneur contenant du texte. Laissez le conteneur s’agrandir au besoin pour s’adapter à la taille du texte qui change

  • Chaque champ du formulaire doit être associé à une étiquette pertinente, les 2 doivent être accolés (étiquette au dessus ou à gauche du champ)
  • Si le champ est répété sur une page ou dans un ensemble de pages, cela doit être fait de manière cohérente
  • Les champs de même nature doivent être regroupés avec une légende pertinente
  • L’intitulé de chaque bouton doit être pertinent
  • Le contrôle de saisie doit être pertinent et accompagné de suggestions qui facilitent la correction des erreurs
  • Dans les cas suivants proposer à l’utilisateur de confirmer son action : modification ou suppression de données, réponse à un test ou à un examen, validation aux conséquences financières ou juridiques
  • Déduire ou suggérer des valeurs pour certains champs (autocomplete) si possible
En savoir plus

Html, CSS et JS concernés

  • Html (balises) : , ,
  • Html (propriétés) : for, type, autocomplete, required
  • ARIA : aria-label, aria-labelledby, aria-describedby, aria-required, aria-invalid

Code


				
				
				ou 
				
				
Adresse ...
Ce champ est obligatoire
...

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Mélange de langues dans le formulaire (ex : arabe et français)
  • Choix UX pertinent
  • Utiliser impérativement <select> plutôt qu’un attribut WAI-ARIA role=”listbox”
  • Personnaliser les messages via l’API Constraint Validation de HTML5
  • Autocomplete (HTML5.2 et la liste des valeurs de type “field name”)

  • 2 de ces 3 modes de navigation doivent être présents sur chaque ensemble de pages : menu de navigation, moteur de recherche ou plan de site
  • Le menu et les barres de navigation doivent être à la même place
  • Le plan du site doit être atteignable de manière identique
  • le moteur de recherche doit être atteignable de manière identique
  • Ajouter un lien d’évitement ou d’accès rapide
  • L’ordre de tabulation doit être cohérent
  • Éviter tout piège au clavier
  • Pas de raccourci avec juste une touche
  • Rendre les contenus additionnels (survol, focus, composant d’interface actif) atteignables au clavier
En savoir plus

Html, CSS et JS concernés

  • Html (propriétés) : tabindex

Code


				
				
					
					...
				
			

				
				#skip-link {
				left:-999px;
				position:absolute;
				top:auto;
				width:1px;
				height:1px;
				overflow:hidden;
				z-index:-999;
			}

			#skip-link:focus{
			color: #fff;
			background-color:#000;
			left: auto;
			top: auto;
			width: 30%;
			height: auto;
			overflow:auto;
			margin: 10px 35%;
			padding:5px;
			border-radius: 15px;
			border:4px solid yellow;
			text-align:center;
			font-size:1.2em;
			z-index:999;
		}
	

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Site sur une page

  • L’utilisateur doit avoir le contrôle de chaque limite de temps qui modifie le contenu
  • L’ouverture d’une nouvelle fenêtre ne doit pas être déclenché sans action de l’utilisateur
  • Les documents bureautiques en téléchargement doivent aussi être accessibles tout en apportant la même information
  • Prévoir une alternative pertinente pour les contenus cryptiques (art ASCII, émoticon, syntaxe cryptique)
  • Utiliser correctement les changements brusques de luminosité ou les effets flash
  • Chaque contenu en mouvement ou clignotant doit être contrôlable par l’utilisateur
  • Le contenu doit être consultable quelque soit l’orientation de l’écran
  • Les fonctionnalités utilisables ou disponibles au moyen d’un geste complexe doivent aussi être disponibles à l’aide d’un geste simple
  • les actions déclenchées au moyen d’un dispositif de pointage sur un point unique de l’écran peuvent-elles faire l’objet d’une annulation
  • les fonctionnalités qui impliquent un mouvement de l’appareil ou vers l’appareil peuvent-elles être satisfaites de manière alternative
En savoir plus

Code


			
			(╬ ಠ益ಠ)
		

Cas particuliers – Notes techniques – Exceptions à la règle :

  • Le critère sur la limite de temps n’est pas applicable lorsque celle ci est essentielle, notamment lorsqu’elle ne pourrait pas être supprimée sans changer fondamentalement le contenu ou les fonctionnalités liées au contenu
  • Le critère sur l’orientation de l’écran n’est pas applicable si celle ci est essentielle à l’utilisation de l’interface. (ex : jeu)
  • Idem pour le critère sur les mouvements de l’appareil. (ex : podomètre)
  • Le critère sur les gestes complexes ne s’appliquent pas aux gestes requis par l’agent utilisateur ou le système d’exploitation
  • Idem pour le critère sur les actions déclenchées au moyen d’un dispositif de pointage. De plus les fonctionnalités qui imitent un clavier ne sont pas concernés