Quelques conseils pour rendre les site web accessibles

Ecrit par : Romain

Publié le : mercredi 15 novembre 2023

Quelques conseils pour rendre le web accessible

(faites ce que je dis, pas ce que fais)

Prises de note de ma formation accessibilité chez Access42

-> Leur blog : “actualités et articles de fond sur l’accessibilité”. a42.fr/blog

-> Leur lettre d’information : “tous les deux mois, un condensé d’accessibilité par e-mail”. a42.fr/newsletter

Table des matières

Pourquoi ?

le web c’est pour tout le monde ! (et puis pour nous c’est la loi aussi)

Technologies d’assistance

Lecteurs d’écrans

Différents lecteurs d’écrans :

zoom (pas le logiciel de visio, pour voir plus gros)

navigation au clavier

moult autres techno d’assistances, avec la langue, le souffle, les yeux, la pensée…

Outils utiles

Blogs / ressources

Adrian Roselli Gaël Poupard / ffoodd, github - voir sr-only par exemple glossaire rgaa Doc ARIA a11ynot.com | A ne pas faire access | moult ressources

Outils pour développeurs

vérifier les liens avec W3C link checker

Extensions :

dans les navigateurs

Pleeeeein d’outils

bookmarkets (js qu’on met en favoris: clique droit copier le lien puis ajouter dans la barre personnelle / marque page -> fait qqch)

Photosensibilité ? Outil PEAT (analyse les vidéos / animation si trop de flash ou de changements de pixels)

color contrast analyszer (bah… pour les contrastes quoi)

gérer les cookies: tarteaucitron (accessible)

fake data

attributs autocomplete possibles

classe (screen-reader only) sr-only by ffoodd

.sr-only {
  border: 0 !important;
  clip: rect(1px, 1px, 1px, 1px) !important;
  -webkit-clip-path: inset(50%) !important;
  clip-path: inset(50%) !important;
  height: 1px !important;
  margin: -1px !important;
  overflow: hidden !important;
  padding: 0 !important;
  position: absolute !important;
  width: 1px !important;
  white-space: nowrap !important;
}

il existe une règle eslint

PDF :

les pdfs ont leur propre référentiel !

on peut proposer une alternative en ligne pour éviter le besoin de les rendre accessibles

PAC outil pour vérifier l’accessibilité des pdf (sous windows)

pour les créer

vérificateur d’accessibilité

/!\ indesign, plus de boulot pour le rendre accessible

/!\ lib de conversion

Lecteurs vidéos

lecteur accessibles :

/!\ Ne pas utiliser balise <vidéo> html (mal supportée)

Lecteurs accessibles

youtube a un niveau d’accessibilité suffisant

Normes et référentiels

éditées par W3C

UAAG

-> normes pour les agents utilisateurs ex attribut title doit être visible

ATAG

-> bonnes pratiques pour les outils d’éditions de contenu (wordpress…)

WCAG

-> web content accessibility guidelines : contenus web

version 2.1 (juin 2018)

version 2.2 actuellement

Niveaux d’accessibilité

RGAA 4

Référentiel Général Amélioration de l’Accessibilité -> implem française de wcag 2

il existe beaucoup d’exceptions aux règles, toujours penser à aller les vérifier

Environnement de tests et bases de référence

cf le site, il existe différents référentiel pour tester accessibilité (ex firefox + telle techno d’assitance)

tester sur au moins deux environnements de bureau & au moins un environnement de mobile (android / iphone)

Les règles HTML / CSS

Structures / règles html

Avoir doctype valide

respect des standards

respect sémantique & balisage

titre de page : balise title

structure du document

lien d’accès rapide - accès rapide au contenu principal : premier élément de la page - sauf si: bandeau de cookie doit être le premier élément - tabIndex -1 sur l’élément cible - on peut mettre d’autres liens que le menu principal (ex plan du site) - attention en ne pas les casser en rajoutant du js dessus par exemple

landmark à respecter

avoir 2 systèmes de navigation (menu / recherche / plan du site)

Contenus

titres (cohérence, uniquement les nécessaires) - si pas possible d’utilese balise h role="heading", aria-level="[level]" (écrase rôle sémantique sur l’élément existant) - dans une modale on peut recommencer la numérotation à partir de h1

listes

citations

frame & iframe

changements de langues (ex: “inscrivez nous à notre newsletter”)

Tableaux

tableaux de mise en forme

tableaux “simples” (colonne / titre + donnée simple dedans) - un titre <caption> - déclaration des entêtes <th scope="col/row"> -> thead / tfoot sont du contenu supplémentaire - équivalent aria role=“table” + aria-label=“nom du tableau” / aria-labelledby=“@id_titre” + role=“rowheader”/“columnheader” + role=“table”

tableaux complexes (présence de cellule fusionnées / plusieurs entête)

Images

images de décoration = une image purement illustrative, n’apporte aucune information ou contient une info mais présente juste à côté de l’image

images porteuses d’information : donner alternative textuelle

image map (avoir une image et par dessus des zones interactives / vieille technique)

images avec description détaillée (exemple dataviz / infographie)

captcha

textes en image

image légendée

Liens

/!\ lien que quand c’est pertinent (changement de page ou équivalent) -> lien vs bouton

liens explicites

Liens identiques (ex: exemple dans une liste, des liens “éditer”, “créer”… qui se répètent dans la page)

liens vides - PAS de liens vides - tout lien doit avoir un intitulé - /!\ alt="" sur image lien - /!\ css -> after ou img background

    :after {

        content= "bla";
    }

liens composites

Consultation

redirection automatique

Limite de temps de session (quand on déconnecte l’utilisateur au bout d’un moment)

raffraichissemnt

Nouvelle fenêtre

document en téléchargement

clignotement / et contenus en mouvement (ex gif / carousel automatique)

effet de flash (ex clip promotionnel JO Londres 2012)

sons déclenchés automatiquement

indépendance de l’orientation (portrait ou payasge)

gestes complexes (contôle tactiles multipoint / tacé swipe)

annulation du pointeur

activation par le mouvement (secouer / basculer)

Présentation de contenu / css

utilisation exclusive de css dans :

contenus visibles sans css (contenu visible reste présent même quand css est désactivé)

contenus “compréhensibles” sans css

couleur par défaut

zone de texte

linéarisation des contenus

Adaptation des textes (doivent rester visibles dans certaines conditions)

contrôle des contenus additionnels au survol / prise de focus

contrôle des contenus additionnels au clavier (exemple texte apparait sur un vignette au survol)

visibilité de la prise de focus

visibilité des liens (en environnement de texte)

texte caché

informations par la forme, la taille ou la position

contraste texte

constraste éléments graphiques

Multimédia

Média temporel (ex: vidéo)

médias non temporel (<canvas> / svg)

Formulaires

étiquettes de champ

intitulé de boutons

aide à la saisie: champs obligatoires (ou formats attendus)

modification / mise à jour / récupération des données

Nature des champs de formulaire (attribut: autocomplete)

Les règles navigation / JS

Ordre de tabulation, pièges au clavier

Avoir des parcours de tabulation logiques, si possible efficace pour la navigation au clavier, doit être visible -> pour le clavier & les lecteurs d’écrans

Ordre de tabulation cohérent exemple: un menu où parfois on tabule et on passe par les sous-menus, parfois pas

Pas de “pièges au clavier exemple:

-> parfois cassé dans un sens mais pas l’autre

Repise de focus exemple: un bouton charger plus de contenu, qui fait apparaître du contenu, le focus est perdu on se retrouve sur le body (il faudrait rester sur le premier nouvel élément affiché)

Au chargement le focus doit être tout en haut de la page (la page vient de charger, pas de raison d’aller chercher plus de contenu)

Eléments invisibles Ne pas tabuler sur les éléments invisibles aussi quand zoomé

Utilisation de tabindex

Deux valeurs autorisées

Ancres (lien vers des #ids)

A ne jamais faire Mettre des valeurs positives à tabindex="1" tabindex="2" tabindex="3" Défini l’ordre des tabulations de manière absolue, si pas tous définis, le navigateur reprend au début (c’est donc très compliqué à maintenir et les erreurs peuvent coûter cher)

Accès au contenu additionnel affiché

Raccourcis claviers

Possible de désactiver/configurer le raccourci On peut activer le raccourci que quand l’objet qu’il concerne a le focus Eviter des les activer par défaut

Composants custom (pas natifs html)

ARIA pattern Nom, rôle et valeurs Vérifier la compatibilité avec les technologies d’assistances Navigation clavier / souris

OU proposer une alternative (peut être la solution la plus efficace si le composant est complexe)

Rôle pertinent liens vs boutons ex une image cliquable à un role=“button” objectif comprendre l’élément sur lequel on est

Nom accessible pertinent title / aria-label / aria-labelledby / alt / contenu du texte Le nom accessible doit toujours reprendre le nom visible

Etat et changements d’état pertinents exemple boutton appuyé ou non aria-pressed="false/true" bouton pause/lecture qui changerait de nom

Utilisation au clavier et à la souris Tous les composants sont utilisables au clavier Si c’est nécessaire doivent être focusable

Alternative Exemple pour un datepicker laisser la possibilité d’écrire au clavier (dans les pattern aria voir dans modale si on veut le rendre accessible)

/!\ alternative n’est pas toujours possible ex datepicker airbnb où toutes les dates ne sont pas disponibles / inclus le prix / le nombre de nuits minimum

Changement de contexte quand on implémente un comportement non anticipable ex: un bouton radio qui fait changer de page / une soumission de formulaire au blur du dernier champ

si on veut vraiment garder le comportement on peut parfois prévenir l’utilisateur en amont (si ça suffit)

Messages de statut popup de confirmation / d’erreur -> on peut vouloir déclencher la vocalisation sans déplacer le focus

alternatives aria-live

/!\ pas ces role/aria pour les indication de progression / chargement en cours -> on peut regarder le modèle de conception progressbar

API ARIA

No ARIA is better than Bad ARIA.

Spécification technique du W3C, commencé vers 2006, api utlisé par les navigateurs (donc pas toujours implémenté pareil), support plutôt bon

-> pallier à problèmes composants complexes / problèmes techniques

roles, aria-* -> tout ça c’est aria

-> tous les éléments ne peuvent pas recevoir n’importe quel rôle (ex: on peut pas mettre role=“alert” sur un <a>)

Doc ARIA

Deux types de composants : composants normés (on respecte la doc) et non-normés (il va falloir réfléchir)

5 règles de bases

fonctionnement navigateur affiche la page -> envoit un arbre d’accessibilité à api-aria -> le complète -> l’envoie à la techno d’assistance

algorithme de calcul du nom accessible

Composant complexes autocomplétion / combobox -> à tester impérativement -> correctement naviguer / sélectionner / restituer aux techno d’assistances

/!\ aller voir le motif de conception -> ARIA pattern

/!\ slider

Tooltip:

… allez voir les pattern

Conseils divers

cookies premier élément à apparaître sur la page -> soit tout au début du code -> soit générer manuellement le bandeau de cookie

implémenter un “système de remplacement” ?

html

css

Conseils boulot

Voir le blog !