En bref : l’accessibilité web consiste à permettre au plus grand nombre de percevoir, comprendre et utiliser un service numérique. Elle concerne la structure du contenu, le clavier, le focus, les contrastes, les médias, les formulaires, les erreurs et la compatibilité avec les technologies d’assistance.
Un site inaccessible n’est pas seulement difficile pour une personne aveugle. Il peut bloquer une personne malvoyante, sourde, dyslexique, limitée dans ses mouvements, utilisant un écran agrandi, naviguant au clavier ou confrontée temporairement à une situation contraignante.
L’accessibilité ne se résume donc pas à ajouter des textes alternatifs après la livraison. Elle se construit dans le cadrage, les maquettes, les composants, le contenu et les tests.
Définir un niveau et une méthode
Les Web Content Accessibility Guidelines, ou WCAG, organisent les critères autour de contenus perceptibles, utilisables, compréhensibles et robustes. Selon le contexte du projet et ses obligations, une référence nationale ou sectorielle peut également s’appliquer.
La documentation WCAG du W3C distingue le standard normatif, les explications et les techniques. Ces ressources aident à choisir une méthode de contrôle plutôt qu’une simple extension de navigateur.
Pour les obligations juridiques précises, le périmètre et la déclaration attendue doivent être validés avec les interlocuteurs compétents. Une agence peut intégrer et auditer des exigences techniques ; elle ne doit pas inventer une conformité réglementaire.
Construire une structure HTML qui porte le sens
Utilisez les éléments selon leur fonction : en-tête, navigation, contenu principal, sections, titres, listes, boutons et liens. Un H1 décrit le sujet principal ; les niveaux suivants suivent une hiérarchie logique sans être choisis pour leur taille visuelle.
Les liens annoncent une destination. Les boutons déclenchent une action. Un tableau sert à des données tabulaires, pas à la mise en page. Cette sémantique offre une navigation plus fiable aux lecteurs d’écran et rend le document plus robuste pour les moteurs.
ARIA peut compléter un composant lorsque le HTML natif ne suffit pas. Il ne corrige pas un bouton construit comme un div non interactif et impose de gérer correctement les états annoncés.
Garantir un parcours complet au clavier
Toutes les actions doivent être atteignables et utilisables sans souris : navigation, menu mobile, accordéons, carrousels, formulaires, modales et fermeture des messages. L’ordre de tabulation suit l’ordre visuel et logique.
Le focus reste visible avec un contraste suffisant. Il n’est pas masqué par un en-tête fixe ou une bannière. Lorsqu’une modale s’ouvre, le focus y entre de manière prévisible, reste dans le contexte utile puis revient au déclencheur à la fermeture.
Testez aussi l’absence de piège : l’utilisateur doit toujours pouvoir poursuivre ou quitter un composant.
Choisir couleurs et contrastes dès la maquette
Un gris élégant sur fond sombre peut devenir illisible. Vérifiez les contrastes du texte, des icônes fonctionnelles, bordures importantes et états de focus dans toutes les variantes. Ne transmettez jamais une information uniquement par la couleur.
Un champ en erreur peut utiliser du rouge, mais il doit aussi afficher un message et une relation programmatique. Un graphique peut combiner couleurs, motifs et libellés. Les états survolés ne doivent pas être l’unique moyen de découvrir une action, surtout sur écran tactile.
Écrire des alternatives d’image utiles
Le texte alternatif dépend de la fonction. Une image décorative reçoit un alt vide afin d’être ignorée. Une photo informative décrit ce qui aide à comprendre le contexte. Un logo lié peut porter le nom de la destination. Une capture complexe peut nécessiter une explication dans le texte adjacent.
Évitez « image de » et les listes de mots-clés. Si une information apparaît déjà immédiatement dans la légende, ne la répétez pas mécaniquement. Le but est d’offrir une expérience équivalente, pas de décrire chaque détail visuel.
Concevoir des formulaires qui expliquent les erreurs
Chaque champ possède un libellé visible et correctement associé. Les instructions importantes apparaissent avant la saisie. Les formats attendus et champs obligatoires sont compréhensibles sans dépendre d’un placeholder qui disparaît.
Après envoi, les erreurs sont résumées et liées aux champs concernés. Le focus se déplace de manière utile, les valeurs valides sont conservées et le message explique comment corriger. Un message de succès est annoncé et ne laisse pas le formulaire dans un état ambigu.
Lorsque l’authentification est nécessaire, évitez les obstacles cognitifs inutiles et autorisez les gestionnaires de mots de passe. Les nouvelles exigences de WCAG 2.2 renforcent notamment le focus non masqué, la taille minimale de certaines cibles, la saisie redondante et l’authentification accessible.
Rendre les contenus compréhensibles
Utilisez un vocabulaire précis, développez les acronymes et placez la réponse principale tôt. Les paragraphes courts, listes et sous-titres descriptifs facilitent la lecture sans infantiliser le propos.
Les liens de navigation gardent le même nom et le même ordre lorsque leur fonction ne change pas. Les aides et coordonnées restent faciles à retrouver. Le mouvement automatique peut être arrêté, et la préférence système de réduction des animations est respectée.
Traiter audio, vidéo et documents
Une vidéo informative demande des sous-titres synchronisés ; selon le contenu, une transcription et une audiodescription peuvent être nécessaires. Les commandes du lecteur sont accessibles au clavier et correctement nommées.
Un PDF important fait partie du parcours et doit être vérifié. Lorsque le contenu peut être publié directement en HTML, cette option facilite souvent la lecture responsive, la navigation et la mise à jour.
Tester avec plusieurs méthodes
Les outils automatiques détectent une partie des erreurs : alt absent, contraste, libellé manquant ou attribut invalide. Ils ne déterminent pas si un texte alternatif est pertinent, si l’ordre de lecture a du sens ou si une erreur est compréhensible.
La recette combine donc :
- analyse automatique sur plusieurs gabarits ;
- parcours clavier complet ;
- zoom et agrandissement du texte ;
- vérification en thème et tailles d’écran représentatifs ;
- essai avec lecteur d’écran sur les parcours critiques ;
- tests utilisateurs lorsque le périmètre le permet.
Une création de site mobile first offre un bon cadre pour intégrer ces contrôles. La performance web complète le travail : une interface accessible doit aussi rester réactive et stable.
Maintenir l’accessibilité après le lancement
Un composant accessible peut être dégradé par un nouveau contenu, un widget tiers ou une modification de couleur. Ajoutez des règles automatiques aux tests, documentez les composants et incluez l’accessibilité dans la validation éditoriale.
Suivez les retours utilisateurs et corrigez les blocages avec une priorité proportionnée à leur impact. Une déclaration ne remplace jamais la capacité réelle à utiliser le service.
BlackStone Digital conçoit des sites web sur mesure en intégrant structure, clavier, contraste, responsive et messages de formulaire. Pour évaluer un parcours précis, indiquez-nous les pages et actions concernées.
