Une personne malvoyante consulte le site d’une collectivité pour connaître les horaires d’un service public. Le texte est gris clair, certains contenus disparaissent lorsqu’elle agrandit l’affichage et les boutons se confondent avec l’arrière-plan.
Sur le site d’une destination touristique, une personne aveugle souhaite réserver une visite guidée. Son lecteur d’écran lui annonce plusieurs liens intitulés « En savoir plus », un bouton sans nom et des champs de formulaire sans indication claire. Elle parvient à consulter la présentation de l’activité, mais ne peut pas finaliser sa réservation.
Dans les deux cas, le site peut sembler simple, moderne et parfaitement utilisable pour une personne voyante. Pourtant, il reste difficile, voire impossible à utiliser pour une partie du public.
Pour améliorer l’accès des personnes aveugles ou malvoyantes à un site web, dix priorités doivent être traitées : la structure des pages, la navigation au clavier, la visibilité du focus, les contrastes, l’usage de la couleur, les alternatives textuelles, les intitulés des liens, les formulaires, les contenus dynamiques et l’agrandissement de l’affichage.
Ces améliorations ne permettent pas, à elles seules, de déclarer un site conforme au Référentiel général d’amélioration de l’accessibilité, ou RGAA. Elles constituent néanmoins un point de départ concret pour supprimer les obstacles les plus fréquents et améliorer les parcours essentiels.
Que recouvre le handicap visuel dans les usages numériques ?
Le handicap visuel ne se limite pas à la cécité totale. Il recouvre des réalités très diverses, avec des conséquences différentes sur l’utilisation d’un site web.
Une personne peut disposer d’une vision partielle, avoir un champ visuel réduit, percevoir difficilement les contrastes, distinguer certaines couleurs avec difficulté ou être particulièrement sensible à la lumière. La vision peut également varier selon les conditions d’éclairage, la fatigue, la taille de l’écran ou la nature des contenus consultés.
Cette diversité interdit de concevoir une interface en imaginant un profil unique d’utilisateur malvoyant.
Certaines personnes agrandissent les textes ou l’ensemble de la page. D’autres modifient les couleurs, augmentent les contrastes ou utilisent un logiciel de grossissement. Les personnes aveugles naviguent généralement avec un lecteur d’écran, parfois associé à une plage braille. Le lecteur d’écran restitue vocalement les informations présentes dans le code : titres, paragraphes, liens, boutons, champs de formulaire ou messages d’état.
La navigation est alors très différente d’une exploration visuelle. Une personne voyante peut repérer immédiatement un menu, une colonne, un bouton coloré ou un encadré. Une personne utilisant un lecteur d’écran parcourt une représentation structurée de la page. Elle peut naviguer de titre en titre, afficher la liste des liens, atteindre directement les champs de formulaire ou parcourir les différentes régions du document.
Cette navigation n’est efficace que si le code reflète correctement la structure et le fonctionnement de l’interface. Le service public français définit d’ailleurs l’accessibilité numérique comme la capacité à rendre les contenus et services numériques compréhensibles et utilisables par les personnes handicapées. Le RGAA 4.1.2 demeure la version de référence en juillet 2026. Une version 5 est annoncée pour la fin de l’année 2026, sans que cette évolution ne justifie de reporter les travaux actuels.
Mise en situation : essayer d’accomplir une tâche sans utiliser la vue
Une mise en situation peut aider une équipe à prendre conscience des obstacles rencontrés par les personnes déficientes visuelles. Elle doit cependant être conduite avec méthode et avec certaines précautions.
L’objectif n’est pas de « vivre la cécité » pendant quelques minutes. Une personne voyante utilisant un bandeau ne possède ni l’expérience, ni les stratégies, ni la maîtrise des outils développées par une personne aveugle. L’exercice doit uniquement servir à repérer les informations et les fonctions qui dépendent excessivement de la perception visuelle.
Choisir un parcours réel et prioritaire
La mise en situation doit porter sur une tâche concrète. Pour une collectivité, il peut s’agir de trouver les horaires d’un service, de télécharger un document, de prendre rendez-vous ou de remplir une demande en ligne.
Pour une destination touristique, le scénario peut consister à rechercher une activité, à vérifier les conditions d’accessibilité d’un lieu, à consulter les tarifs puis à effectuer une réservation.
Le parcours choisi doit correspondre à un besoin important de l’usager. Tester uniquement la page d’accueil apporte peu d’informations sur l’accessibilité réelle du service.
Utiliser le clavier et un lecteur d’écran
L’exercice peut commencer par une navigation exclusivement réalisée au clavier. La touche de tabulation permet de passer d’un élément interactif à l’autre. Les touches Entrée, Espace et les flèches servent à activer les composants selon leur nature.
Dans un second temps, l’équipe peut activer un lecteur d’écran. NVDA peut notamment être utilisé sous Windows. VoiceOver est intégré aux appareils Apple. L’objectif n’est pas de maîtriser immédiatement toutes les commandes, mais d’écouter la manière dont les contenus et les composants sont annoncés.
Une démonstration publiée par la Direction interministérielle du numérique montre précisément comment une personne non voyante utilise une synthèse vocale et un afficheur braille pour parcourir une page web. Elle met également en évidence la différence entre une page correctement structurée et une page présentant des défauts d’accessibilité.
Pendant l’exercice, l’équipe doit noter chaque blocage, mais aussi chaque hésitation : un bouton dont la fonction n’est pas compréhensible, une information annoncée dans un ordre incohérent, une erreur qui n’est pas signalée ou un changement de page inattendu.
Ces observations peuvent ensuite être transformées en anomalies documentées et en critères d’acceptation vérifiables.
1. Structurer correctement les titres et les zones de la page
La structure visuelle d’une page ne suffit pas. Un texte affiché en grand et en gras n’est pas nécessairement identifié comme un titre par les technologies d’assistance.
Lorsqu’une page est correctement structurée, l’utilisateur d’un lecteur d’écran peut afficher la liste des titres et rejoindre directement la section recherchée. Sans cette hiérarchie, il doit parcourir une grande partie du contenu de manière linéaire.
Une page présentant une activité touristique devrait, par exemple, identifier clairement les sections « Présentation », « Informations pratiques », « Tarifs », « Accessibilité du lieu » et « Réservation ». La taille ou la couleur du texte ne doit pas être le seul moyen de matérialiser cette organisation.
La hiérarchie doit être logique. Le titre principal est suivi de titres de deuxième niveau, puis de sous-sections de troisième niveau lorsqu’elles sont nécessaires. Les niveaux ne doivent pas être choisis pour leur apparence graphique, mais pour représenter l’organisation du contenu.
Cette structure bénéficie également au référencement naturel et aux moteurs de réponse. Elle facilite l’identification des sujets, des sous-thèmes et des passages pouvant répondre à une question précise.
2. Rendre toutes les fonctionnalités utilisables au clavier
Une interface accessible doit pouvoir être utilisée sans souris lorsqu’aucune manipulation ne nécessite intrinsèquement un dispositif de pointage.
Cette exigence concerne les menus, boutons, accordéons, fenêtres modales, calendriers, filtres, carrousels et formulaires. Le W3C précise que les utilisateurs d’une interface clavier doivent pouvoir réaliser les mêmes actions, ou des actions comparables, que les utilisateurs d’une souris ou d’un écran tactile.
Les difficultés apparaissent fréquemment dans les composants développés sur mesure. Un menu peut s’ouvrir au passage de la souris, mais rester inaccessible avec la touche Entrée. Une fenêtre peut apparaître au-dessus de la page sans que le focus y soit déplacé. Un calendrier de réservation peut permettre de sélectionner une date uniquement en cliquant sur une case.
Pour vérifier un parcours, il suffit de ranger la souris et d’utiliser la touche de tabulation depuis le début de la page. Tous les éléments interactifs doivent être atteignables dans un ordre cohérent. Aucun composant ne doit emprisonner le focus, sauf lorsqu’un fonctionnement temporaire et contrôlé l’exige, comme dans certaines fenêtres modales.
Une destination touristique doit porter une attention particulière aux modules fournis par des prestataires : moteurs de réservation, cartes, agendas ou systèmes de billetterie. Leur intégration dans un site accessible ne garantit pas que ces services tiers soient eux-mêmes utilisables au clavier.
3. Conserver un indicateur de focus clairement visible
Le focus indique l’élément actuellement sélectionné lors d’une navigation au clavier. Il peut prendre la forme d’un contour, d’un changement de fond ou d’une bordure renforcée.
Sans indicateur visible, une personne malvoyante naviguant au clavier ne sait plus où elle se trouve dans la page. Elle peut continuer à déplacer le focus sans percevoir quel lien ou quel bouton sera activé.
La suppression de la propriété CSS outline est une erreur fréquente. Elle est parfois décidée pour des raisons esthétiques, sans solution de remplacement suffisamment perceptible.
Le W3C rappelle que l’objectif du critère relatif au focus visible est de permettre à l’utilisateur d’identifier l’élément qui détient le focus clavier. Les WCAG 2.2 renforcent également les exigences concernant la visibilité et la non-dissimulation de cet indicateur.
Le focus doit être testé sur différents arrière-plans. Un contour bleu peut être visible sur une zone blanche, mais disparaître sur un bouton ou une photographie contenant la même couleur. Une solution à deux couleurs peut offrir une meilleure robustesse sur des fonds variables.
4. Corriger les contrastes insuffisants
Un texte gris clair sur fond blanc peut donner une impression de légèreté graphique. Il peut également devenir illisible pour une personne malvoyante.
Les contrastes doivent être vérifiés pour les textes, mais aussi pour les composants d’interface, les bordures de champs, les icônes porteuses d’information et les différents états des boutons.
Pour les textes courants, les WCAG demandent généralement un rapport de contraste minimal de 4,5 pour 1. Un seuil de 3 pour 1 s’applique aux textes considérés comme grands selon les conditions définies par le référentiel. L’objectif est de garantir une différence suffisante entre le texte et son arrière-plan pour les personnes ayant une vision modérément réduite.
Les sites touristiques sont particulièrement exposés à ce problème. Les textes sont souvent placés sur des photographies de paysages, de monuments ou d’activités. La lisibilité varie alors selon la zone de l’image et la taille de l’écran.
Une solution consiste à placer le texte sur un fond uni ou suffisamment opaque. Une ombre légère autour des caractères ne permet pas toujours d’obtenir un contraste stable.
Les contrastes doivent aussi être vérifiés dans les situations réelles : au survol, au focus, après sélection, en cas d’erreur et lorsque le composant est désactivé.
5. Ne pas transmettre une information uniquement par la couleur
La couleur ne doit jamais être l’unique moyen de distinguer un état, une catégorie ou une information.
Dans un calendrier, les créneaux disponibles peuvent être affichés en vert et les créneaux complets en rouge. Sans texte ou symbole complémentaire, cette distinction devient difficile à percevoir pour certains utilisateurs.
La même difficulté apparaît dans les formulaires. Encadrer un champ en rouge ne suffit pas à expliquer qu’une erreur est présente. Un message textuel doit indiquer la nature du problème et la manière de le corriger.
Une carte touristique peut également employer plusieurs couleurs pour représenter des catégories de lieux. Une légende textuelle, des motifs, des formes ou une liste alternative doivent permettre de retrouver les mêmes informations sans dépendre de la perception des couleurs.
L’objectif n’est pas de supprimer la couleur. Elle reste utile pour renforcer la compréhension. Elle doit simplement être associée à un autre indicateur perceptible.
6. Rédiger des alternatives textuelles pertinentes
Une image informative doit disposer d’une alternative permettant d’en comprendre le sens ou la fonction.
Cette alternative ne doit pas décrire mécaniquement tout ce qui apparaît à l’écran. Elle doit transmettre l’information utile dans le contexte de la page.
Pour une photographie décorative d’un paysage, une alternative vide peut être appropriée afin d’éviter une annonce inutile. Pour le portrait d’un élu accompagnant une présentation institutionnelle, une alternative courte peut identifier la personne. Pour une infographie, un plan ou un graphique, une description plus complète peut être nécessaire.
Le nom du fichier, comme IMG_4587.jpg, ne constitue jamais une alternative pertinente. Les formulations telles que « image de » ou « photo représentant » sont généralement inutiles, puisque le lecteur d’écran annonce déjà la présence d’une image.
Les cartes d’accès sont un cas fréquent sur les sites publics et touristiques. Une image ou une carte interactive ne doit pas être le seul moyen d’obtenir un itinéraire. L’adresse, les transports, les possibilités de stationnement et les indications utiles doivent être disponibles sous forme textuelle.
Le même principe s’applique aux CAPTCHA visuels. La Direction interministérielle du numérique rappelle que ces dispositifs sont impossibles à résoudre pour une personne aveugle ou malvoyante lorsqu’ils reposent uniquement sur des éléments graphiques.
7. Donner des intitulés explicites aux liens et aux boutons
Un lien doit être compréhensible sans dépendre excessivement du texte qui l’entoure.
Lorsqu’un lecteur d’écran affiche la liste des liens d’une page, une succession d’intitulés comme « Voir », « Lire la suite » ou « En savoir plus » ne permet pas d’identifier leurs destinations.
Il est préférable d’utiliser des formulations précises : « Consulter les horaires de la médiathèque », « Télécharger le programme des visites » ou « Découvrir les conditions d’accès au musée ».
Les boutons doivent également posséder un nom accessible. Une icône représentant une loupe peut être visuellement interprétée comme une fonction de recherche, mais être annoncée uniquement comme « bouton » par le lecteur d’écran. Le code doit transmettre une appellation compréhensible.
Cette exigence concerne aussi les boutons de fermeture, les commandes de carrousel, les déclencheurs de menu et les actions de réservation.
Des intitulés explicites améliorent l’accessibilité, mais aussi la compréhension générale des parcours. Ils réduisent les ambiguïtés et facilitent l’exploration de la page.
8. Rendre les formulaires compréhensibles et corrigeables
Les formulaires constituent souvent le point de rupture d’un parcours. L’utilisateur a trouvé l’information recherchée, mais ne peut pas prendre rendez-vous, envoyer sa demande ou finaliser sa réservation.
Chaque champ doit posséder un libellé correctement associé dans le code. Un texte affiché à l’intérieur du champ ne remplace pas toujours ce libellé : il disparaît lors de la saisie et peut présenter un contraste insuffisant.
Les formats attendus doivent être indiqués avant la validation. Lorsqu’une date, un numéro ou un mot de passe répond à une règle précise, l’utilisateur doit pouvoir la connaître avant de commettre une erreur.
Après validation, un message comme « Une erreur est survenue » n’est pas suffisamment précis. Le site doit identifier le champ concerné et expliquer comment résoudre le problème : « Le numéro de téléphone doit contenir dix chiffres » ou « La date de visite doit être postérieure au 21 juillet 2026 ».
La couleur seule ne doit pas signaler l’erreur. Le lecteur d’écran doit pouvoir accéder au message et comprendre son association avec le champ correspondant.
Enfin, l’envoi réussi du formulaire doit être confirmé explicitement. Une personne ne doit pas être contrainte de deviner si sa démarche ou sa réservation a bien été enregistrée.
9. Annoncer les changements de contenu dynamique
De nombreux sites mettent à jour une partie de la page sans rechargement complet. Ce fonctionnement peut être confortable visuellement, mais rester invisible pour un utilisateur de lecteur d’écran.
Après l’utilisation d’un filtre, de nouveaux résultats peuvent apparaître sans être annoncés. Après l’ajout d’une prestation à une réservation, le total peut évoluer uniquement à l’écran. Une erreur peut s’afficher au-dessus du formulaire alors que le focus reste sur le bouton de validation.
Chaque changement important doit être perceptible. Le site peut notamment annoncer le nombre de résultats obtenus, confirmer l’ajout d’un élément ou signaler l’ouverture d’une fenêtre.
Les attributs ARIA permettent parfois de transmettre ces changements aux technologies d’assistance. Ils doivent toutefois être utilisés avec prudence. Un composant HTML natif correctement choisi est généralement préférable à une reconstruction complexe reposant entièrement sur ARIA.
L’objectif consiste à garantir que le nom, le rôle, l’état et les changements d’un composant soient compris par les technologies d’assistance. Les critères et tests du RGAA abordent précisément cette compatibilité avec les interfaces d’accessibilité.
10. Permettre l’agrandissement et la personnalisation de l’affichage
Une personne malvoyante peut agrandir le texte, zoomer l’ensemble de la page ou utiliser une fenêtre très étroite afin de grossir une partie du contenu.
Le site doit rester utilisable dans ces configurations. Les textes ne doivent pas se chevaucher, les boutons ne doivent pas être coupés et les informations ne doivent pas disparaître.
Le blocage du zoom sur mobile est à proscrire. Il empêche directement certains utilisateurs d’adapter l’affichage à leurs besoins.
Un test simple consiste à agrandir la page à 200 %, puis à 400 %. Il faut alors vérifier si le contenu se réorganise correctement. Un défilement vertical plus important est acceptable. En revanche, l’utilisateur ne devrait pas être contraint d’effectuer en permanence des déplacements horizontaux pour lire chaque ligne de texte.
Les menus, fenêtres et bandeaux fixes doivent également être contrôlés. En affichage agrandi, ils peuvent occuper une grande partie de l’écran et masquer l’élément qui détient le focus.
Les WCAG 2.1 ont notamment renforcé les critères destinés aux personnes malvoyantes et aux usages mobiles.
Comment prioriser ces améliorations avec des moyens limités ?
Une collectivité ou une destination touristique ne peut pas toujours corriger immédiatement l’ensemble de son écosystème numérique. La priorité doit alors être donnée aux parcours qui produisent le plus de valeur pour l’usager ou qui conditionnent l’accès à un droit, une information ou un service.
Les démarches administratives, formulaires de contact, moteurs de recherche, systèmes de réservation, pages d’urgence et informations pratiques doivent être examinés en premier.
Les anomalies peuvent être classées selon leur impact.
| Niveau | Conséquence | Exemple |
| Bloquant | La tâche ne peut pas être terminée | Bouton de validation inaccessible au clavier |
| Majeur | La tâche reste possible avec de fortes difficultés | Formulaire mal structuré ou liens ambigus |
| Gênant | L’expérience est dégradée sans empêcher totalement l’action | Contraste insuffisant sur une information secondaire |
Cette priorisation ne doit pas devenir un prétexte pour ignorer durablement les défauts jugés moins graves. Elle sert à organiser une trajectoire de correction.
Les améliorations doivent ensuite être intégrées dans les outils de production : design system, composants du CMS, modèles de pages, guide de contribution, cahiers des charges et critères de recette.
Une correction réalisée uniquement sur une page risque de disparaître lors de la prochaine mise à jour. Une règle intégrée à un composant partagé bénéficie à l’ensemble du site et limite les régressions.
Quels tests simples réaliser en interne ?
Quelques vérifications peuvent être menées sans disposer immédiatement d’une expertise complète.
Le premier test consiste à parcourir un scénario uniquement au clavier. Le deuxième consiste à agrandir l’affichage à 200 %, puis à 400 %. Le troisième peut être réalisé avec un lecteur d’écran sur quelques pages représentatives.
Il est également utile de désactiver temporairement les images pour vérifier si les informations essentielles restent disponibles, puis d’examiner la page avec un outil de contrôle des contrastes.
Ces tests ne produisent pas un taux de conformité. Le W3C présente d’ailleurs ses vérifications simplifiées comme une première revue permettant seulement d’estimer si les bases de l’accessibilité sont prises en compte.
Un audit RGAA reste nécessaire pour établir un état de conformité. La méthode française évalue les pages selon 106 critères répartis en 13 thématiques et permet de vérifier les critères de succès de niveaux A et AA retenus par le cadre de référence.
Deux parcours à auditer en priorité
Pour une collectivité territoriale
Le parcours prioritaire peut commencer par la recherche d’un service municipal. L’usager doit trouver les horaires, identifier les documents nécessaires, accéder à une démarche puis recevoir une confirmation.
Les points les plus sensibles sont généralement le moteur de recherche, les menus, les PDF, les formulaires et les services intégrés depuis des plateformes externes.
Une attention particulière doit être accordée aux informations indispensables : état civil, inscriptions scolaires, démarches sociales, stationnement, collecte des déchets, élections ou signalement d’un problème.
Pour une destination touristique
Le parcours peut partir d’une recherche d’activité ou d’hébergement. L’utilisateur doit pouvoir filtrer les résultats, consulter une fiche détaillée, connaître les conditions d’accessibilité physique du lieu et effectuer une réservation.
Les cartes interactives, calendriers, carrousels, photographies, moteurs de réservation et modules tiers constituent les principaux points de vigilance.
L’information sur l’accessibilité physique doit elle-même être accessible numériquement. Une fiche indiquant la présence d’un cheminement adapté ou d’une visite descriptive perd son utilité si elle ne peut pas être consultée avec un lecteur d’écran.
Ce que la mise en situation ne permet pas de prouver
Une mise en situation peut sensibiliser une équipe, révéler certains obstacles et faciliter la priorisation des corrections. Elle peut aussi enrichir un cahier des charges ou préparer des tests utilisateurs.
Elle ne permet pas d’établir un taux de conformité RGAA. Elle ne couvre pas l’ensemble des profils de déficience visuelle et ne remplace pas l’intervention de personnes concernées.
Les tests utilisateurs constituent un complément indispensable. Une personne habituée à utiliser un lecteur d’écran possède des stratégies de navigation qu’un testeur occasionnel ne maîtrise pas. Elle peut identifier des problèmes de compréhension, d’efficacité ou de cohérence qui ne correspondent pas toujours à une anomalie technique évidente.
L’approche la plus robuste combine donc plusieurs niveaux : vérifications automatiques, tests manuels, audit de conformité et tests avec des utilisateurs en situation de handicap.
Un plan d’action réalisable en 30 jours
La première semaine peut être consacrée à la sélection de trois à cinq parcours essentiels. Chaque étape est documentée, ainsi que les blocages observés au clavier, en affichage agrandi et avec un lecteur d’écran.
La deuxième semaine permet de corriger les anomalies les plus immédiates : boutons sans nom, champs sans libellé, liens ambigus, focus invisible, contrastes manifestement insuffisants ou messages d’erreur incompréhensibles.
Pendant la troisième semaine, les règles sont intégrées dans les composants, les modèles et les documents internes. Les prestataires reçoivent des critères d’acceptation précis.
La quatrième semaine est consacrée à la recette. Les parcours sont testés une nouvelle fois, les corrections sont documentées et les problèmes nécessitant un travail plus important rejoignent un plan d’action suivi dans le temps.
Cette démarche ne rendra pas nécessairement le site conforme en un mois. Elle permet toutefois de sortir d’une logique de sensibilisation générale pour entrer dans un processus mesurable d’amélioration continue.
Pour conclure : réduire les dépendances à la vue améliore le service pour tous
Un site accessible aux personnes aveugles ou malvoyantes ne repose pas sur une fonctionnalité spéciale. Il repose sur une conception suffisamment robuste pour que l’information et les services puissent être utilisés de différentes manières.
Une bonne structure de titres facilite la lecture rapide. Des liens explicites améliorent la compréhension. Des formulaires correctement conçus réduisent les erreurs. Un focus visible et une navigation au clavier renforcent la qualité des interfaces. Des contrastes suffisants améliorent la consultation sur mobile, en extérieur ou dans de mauvaises conditions d’affichage.
L’accessibilité ne consiste donc pas à ajouter une couche corrective à la fin du projet. Elle consiste à limiter les dépendances inutiles à la vue, à la souris, à une couleur ou à une présentation particulière.
Pour les collectivités et les destinations touristiques, cette démarche répond à un enjeu plus large que la conformité : permettre à chaque citoyen ou visiteur d’accéder réellement à l’information, aux démarches et aux services proposés.
FAQ
Comment une personne aveugle navigue-t-elle sur un site web ?
Une personne aveugle utilise généralement un lecteur d’écran associé au clavier. Le logiciel restitue vocalement ou sur une plage braille les titres, textes, liens, boutons, formulaires et états présents dans le code de la page.
Quelle est la différence entre cécité et malvoyance ?
La cécité correspond à une absence totale ou presque totale de vision. La malvoyance recouvre des situations variées : vision floue, champ visuel réduit, faible perception des contrastes, sensibilité à la lumière ou difficulté à distinguer certaines couleurs.
Un lecteur d’écran suffit-il pour tester l’accessibilité ?
Non. Un test avec un lecteur d’écran permet d’identifier certains obstacles, mais il ne remplace ni un audit RGAA complet ni des tests avec des utilisateurs expérimentés. Il doit être intégré à une démarche associant plusieurs méthodes d’évaluation.
Quelles corrections faut-il réaliser en premier ?
Les premières corrections doivent concerner les obstacles qui empêchent d’accomplir une tâche : navigation clavier impossible, boutons sans nom, formulaires inutilisables, contenus dynamiques non annoncés et informations essentielles disponibles uniquement sous forme visuelle.
Les contrastes bénéficient-ils uniquement aux personnes malvoyantes ?
Non. Des contrastes suffisants améliorent la lecture sur un écran de mauvaise qualité, dans un environnement lumineux, en situation de fatigue visuelle ou sur un téléphone portable. Ils bénéficient donc à une grande diversité d’utilisateurs.
Toutes les images doivent-elles être décrites ?
Toutes les images doivent être correctement traitées, mais elles n’exigent pas toutes une description. Une image informative nécessite une alternative pertinente. Une image purement décorative doit généralement être ignorée par les technologies d’assistance.
Une carte interactive peut-elle être accessible ?
Une carte interactive peut proposer certaines fonctions accessibles, mais elle doit être accompagnée d’une alternative présentant les mêmes informations sous forme textuelle : liste des lieux, adresses, horaires, itinéraires et coordonnées.
Le zoom du navigateur doit-il rester disponible ?
Oui. Le site ne doit pas bloquer le zoom. Les contenus et les fonctionnalités doivent également rester utilisables lorsque l’affichage est fortement agrandi ou réorganisé sur une largeur réduite.
Une mise en situation avec un bandeau est-elle pertinente ?
Elle peut sensibiliser une équipe à certaines dépendances visuelles, mais elle ne reproduit pas l’expérience d’une personne aveugle. Elle doit rester un exercice pédagogique et ne pas être présentée comme un test utilisateur ou une validation de conformité.
Comment vérifier les corrections réalisées par un prestataire ?
Chaque correction doit être associée à un critère vérifiable : utilisation complète au clavier, intitulés accessibles, ordre de focus logique, contrastes mesurés, erreurs compréhensibles et compatibilité avec les technologies d’assistance. Une simple déclaration du prestataire ne constitue pas une preuve suffisante.
Sur le même sujet
- Basse vision : mise en situation et 10 améliorations prioritaires
Résumer le contenu avec l’IA :La basse vision ne signifie pas nécessairement ne plus voir. De nombreuses personnes malvoyantes utilisent un site web en agrandissant fortement les contenus, en augmentant les contrastes ou en adaptant les couleurs à leurs besoins. Un site peut pourtant devenir très difficile, voire impossible à utiliser dès que l’affichage est… Lire la suite : Basse vision : mise en situation et 10 améliorations prioritaires - Check-list prête à l’emploi daltonisme : points de contrôle rapides pour contributeurs
Résumer le contenu avec l’IA :Publier un contenu lisible ne signifie pas forcément qu’il est accessible à une personne daltonienne. Une carte touristique reposant sur un code rouge/vert, un graphique composé de courbes différenciées uniquement par leur couleur ou un message d’erreur signalé par un encadrement rouge peuvent devenir difficiles à comprendre pour certains utilisateurs.… Lire la suite : Check-list prête à l’emploi daltonisme : points de contrôle rapides pour contributeurs - Daltonisme et accessibilité web : mise en situation et 10 améliorations prioritaires
Résumer le contenu avec l’IA :Imaginez un site de mairie où les créneaux disponibles pour prendre rendez-vous apparaissent en vert et les créneaux complets en rouge. Ou un site d’office de tourisme où les itinéraires faciles, intermédiaires et difficiles sont différenciés uniquement par leur couleur. Pour la majorité des utilisateurs, l’information semble immédiatement compréhensible. Pour… Lire la suite : Daltonisme et accessibilité web : mise en situation et 10 améliorations prioritaires - Sous-traitance web : comment sécuriser l’accessibilité quand il y a plusieurs prestataires ?
Résumer le contenu avec l’IA :La création ou la refonte d’un site web mobilise rarement un seul intervenant. Une collectivité peut confier la conception graphique à une agence, le développement à une société spécialisée, l’hébergement à un prestataire technique et la maintenance à un autre titulaire. Une destination touristique peut également utiliser un système d’information… Lire la suite : Sous-traitance web : comment sécuriser l’accessibilité quand il y a plusieurs prestataires ?