Cartes interactives accessibles : WCAG 2.2

Les cartes interactives accessibles permettent à une personne d’accomplir la même tâche de localisation au clavier, avec une technologie d’assistance ou au toucher, sans dépendre du glisser, de la couleur ni d’une épingle qu’elle doit voir. La recherche, une liste de résultats, les détails et une réponse qui nomme le lieu portent la tâche. La carte reste la vue visuelle de cet état partagé.

Les sections ci-dessous séparent la tâche du canevas, puis abordent l’identité du lieu, l’ordre au clavier, le glisser, la couleur, les annonces et les réponses de l’IA. Une exception de redistribution pour la carte n’exonère pas le reste de la page. Kaleidr Studio, Viewer et Chat se placent à côté des contrôles de l’hôte qui rendent la tâche utilisable.

Principes essentiels des cartes interactives accessibles

• Nommer la tâche : rechercher, comparer, sélectionner et agir constituent le travail. Le canevas n’en est qu’une vue.
• Partager un identifiant de lieu unique : la liste, le marqueur, les détails et la réponse de l’IA renvoient au même enregistrement.
• Proposer un chemin sans glisser : boutons de déplacement, cible tactile, saisie d’adresse et commandes monter/descendre complètent le glisser.
• Ne pas coder le sens uniquement par la couleur : un état a besoin de texte, d’une forme ou d’une icône en plus de la teinte.
• Annoncer le résultat : un nombre de résultats, un itinéraire prêt ou une absence de correspondance appartiennent à un message d’état. Le chargement des tuiles, non.

Que sont les cartes interactives accessibles ?

Les cartes interactives accessibles sont des expériences de localisation dans lesquelles les utilisateurs du clavier, des technologies d’assistance et d’un dispositif de pointage peuvent accomplir la même tâche. Il peut s’agir de trouver un musée avec une entrée sans marche, de comparer trois bibliothèques ou de choisir une pharmacie qui reste ouverte. La carte montre les relations spatiales. La recherche, les filtres, une liste de résultats, les détails et une réponse écrite portent les faits dont une personne a besoin lorsque le canevas est difficile à voir, à faire glisser ou à toucher. Une interface qui ne fonctionne qu’au pointeur est une carte visuelle, pas une carte accessible.

WCAG 2.2 est une Recommandation du W3C datée du 12 décembre 2024. Cette recommandation est la norme web actuelle que ce guide applique aux tâches cartographiques, notamment le focus, le glisser, la taille de cible, la couleur, le contraste et la redistribution (W3C, 2024). La couverture associe une liste de résultats à une carte et à une réponse qui nomme City Museum, une distance d’exemple et des équipements d’exemple. Ces distances et libellés d’équipements sont illustratifs. Une carte en production doit exposer de vrais champs du dossier du lieu, et un filtre nommé « Accessible » ne prouve pas qu’un site a fait l’objet d’un audit.

Pourquoi commencer par la tâche plutôt que par le canevas ?

Un parcours uniquement cartographique demande à une personne d’explorer le canevas, de trouver une épingle, de lire une fenêtre contextuelle puis d’agir. Ce parcours exige une interprétation visuelle et une grande précision du pointeur. Un parcours accessible commence par une recherche ou une invite, puis une liste structurée de résultats, les détails du lieu et enfin une action comme obtenir un itinéraire, enregistrer ou partager. La carte se met à jour à côté de ces étapes et n’est pas le seul chemin possible. Le guide d’intégration de Kaleidr demande déjà des titres, des résumés et une liste de lieux hors du canevas afin que la page reste utile aux utilisateurs du clavier, aux technologies d’assistance et à la recherche (Kaleidr, 2026).

Le parcours de gauche traite la carte comme l’interface et fait de l’interprétation visuelle et de la précision du pointeur des exigences. Celui de droite passe par la recherche, une liste de résultats, les détails et une action, avec la carte comme vue de soutien. Les noms de bibliothèques, adresses et distances sont des exemples. Cette séparation est un choix d’architecture, pas un score Kaleidr.

Placez l’enregistrement essentiel dans le HTML. Un nom, une adresse, une catégorie, des horaires et l’action suivante doivent exister même lorsque les tuiles de carte échouent. La fenêtre contextuelle peut répéter ces faits. Elle ne peut pas en être l’unique copie. Les identifiants de lieu stables, abordés ensuite, maintiennent la ligne de la liste et le marqueur liés au même enregistrement.

Pourquoi un identifiant de lieu unique est-il important ?

La recherche, la carte de résultat, le panneau de détails, le marqueur cartographique, la réponse de l’IA et un événement d’analytics doivent partager un identifiant de lieu unique. Si cet identifiant change de sens entre les surfaces, un utilisateur du clavier peut sélectionner FreshMart dans la liste alors que la carte met en évidence un autre magasin et que la réponse en décrit un troisième. La figure place cet identifiant au centre et le diffuse vers chaque surface. Les adresses, la note en étoiles, le nombre d’avis, le numéro de téléphone, les coordonnées et l’horodatage figurant dans l’illustration sont des exemples, pas un enregistrement Kaleidr en direct.

Un identifiant de lieu partagé alimente la carte de résultat, le panneau de détails, le marqueur, la réponse et l’événement d’analytics. Chaque surface affiche le même nom et la même adresse. La note, le numéro de téléphone, les coordonnées et l’heure de l’événement dans la figure sont des exemples. Les analytics de production doivent conserver l’identifiant et éviter de copier des champs dont l’événement n’a pas besoin.

La sélection suit l’identifiant, pas une coordonnée d’écran. Activer une ligne de la liste définit le lieu sélectionné, déplace la carte et met à jour les détails sans obliger la personne à chercher l’épingle. Un clic sur un marqueur fait l’inverse et met en évidence la même ligne. Ne déplacez pas le focus clavier vers la carte à chaque sélection, sinon un utilisateur de lecteur d’écran perd sa place dans la liste. Le focus et la sélection sont des états différents, et la section suivante les garde distincts.

Quel ordre au clavier permet d’accomplir la tâche ?

Concevez l’ordre du focus autour de la tâche. Une séquence praticable est : recherche, filtres, résumé des résultats, liste de résultats, commandes de carte, détails et action principale. La personne peut comprendre le nombre de résultats, choisir un lieu dans la liste, déplacer ou zoomer la carte si elle le souhaite, lire les détails puis demander un itinéraire. Les marqueurs cartographiques n’ont pas chacun besoin d’un arrêt de tabulation lorsque la liste expose déjà les mêmes lieux. Les flèches peuvent se déplacer dans la liste. Tab passe entre les grandes régions.

Le parcours va de la recherche aux filtres, à un résumé des résultats, à la liste, aux commandes de carte, aux détails et à l’action principale. Un parc sélectionné reste lié à sa ligne de liste et à sa carte de détail. Le nombre de résultats et les distances d’exemple sont illustratifs. L’ordre du focus suit la tâche, et la carte constitue une étape plutôt qu’un champ d’épingles.

Un contenu créé par l’auteur qui masque entièrement un contrôle focalisé, comme une barre de recherche fixe ou un panneau de chat, ne satisfait pas le critère de succès 2.4.11 (AA) de WCAG 2.2. La note 2 de ce critère autorise le contenu ouvert par la personne, tel qu’un tiroir de détails, à masquer le contrôle si elle peut le révéler sans avancer le focus clavier. Un masquage partiel, lorsqu’une partie du contrôle reste visible, relève du critère de succès 2.4.12 (AAA). Le focus visible et la sélection visible ont besoin de styles distincts, car une ligne bleue et un anneau de focus répondent à des questions différentes. Les recommandations clavier de WAI-ARIA demandent aux auteurs de distinguer le focus de la sélection, en particulier lorsque des éléments sélectionnés se trouvent dans un composant qui ne détient pas le focus (W3C, 2026). Conservez un anneau de focus sur le contrôle qui recevra la prochaine touche et un traitement de sélection séparé pour le lieu.

Pourquoi le glisser ne peut-il pas être le seul chemin ?

Les cartes invitent au glisser, mais celui-ci ne peut pas être l’unique moyen de déplacer la carte, de définir un arrêt ou de réordonner un itinéraire. Le critère de succès 2.5.7 de WCAG 2.2 indique qu’une fonctionnalité utilisant un mouvement de glisser doit pouvoir être réalisée avec un pointeur unique sans glisser, sauf si le glisser est essentiel ou si l’agent utilisateur détermine ce comportement et que l’auteur ne l’a pas modifié. Une alternative clavier ne suffit pas, à elle seule, à répondre à cette exigence de pointeur. Proposez des boutons directionnels de déplacement, un toucher pour définir la destination, un champ d’adresse et des commandes monter/descendre pour les arrêts ordonnés. Le critère de succès 2.5.8 de la même recommandation fixe une taille minimale de cible de 24 par 24 pixels CSS, avec des exceptions comprenant l’espacement et un contrôle équivalent ailleurs sur la page.

Le panneau de gauche montre le glisser comme seul moyen de déplacer la carte. Celui de droite ajoute des boutons de déplacement, une cible tactile, un champ d’adresse, des boutons de réorganisation et des touches clavier pour déplacer la carte. L’adresse d’exemple est illustrative. Un chemin clavier reste nécessaire et ne remplace pas l’alternative à pointeur unique au glisser.

Permettez de quitter la carte sans piéger le clavier. Si les flèches déplacent la carte lorsque le focus s’y trouve, Échap ou une touche documentée doit rendre le focus à la liste ou au contrôle suivant. Zoom, localisation et fermeture ont besoin de noms accessibles, pas de boutons uniquement iconographiques qu’un lecteur d’écran ne peut pas nommer. La taille de cible compte pour ces contrôles et pour les lignes de liste, où une zone de frappe minuscule pénalise les personnes qui touchent l’écran ou utilisent un pointeur moins précis.

Pourquoi la couleur ne suffit-elle pas sur une carte ?

Le critère de succès 1.4.1 dit que la couleur ne peut pas être le seul moyen visuel de transmettre une information, d’indiquer une action, de susciter une réponse ou de distinguer un élément. Un point vert pour « ouvert » et un point rouge pour « fermé » échouent lorsque la teinte est la seule différence. Associez la couleur à un libellé, une coche, une croix ou une autre forme. La même règle s’applique aux marqueurs de catégorie, aux itinéraires sélectionnés et à « vous êtes ici ». Le critère de succès 1.4.11 de la même recommandation demande aussi un rapport de contraste d’au moins 3:1 pour les informations visuelles nécessaires à l’identification des composants et états de l’interface utilisateur, à l’exception des composants inactifs ou dont l’apparence est déterminée par l’agent utilisateur. Un bouton de zoom blanc sur un fond de carte pâle peut manquer ce ratio même si les couleurs de marque paraissent correctes sur une page blanche.

L’exemple faible utilise un cercle vert pour Ouvert et un cercle rouge pour Fermé. L’exemple plus robuste ajoute une coche, une croix, une forme d’avertissement et les mots Ouvert, Fermé et Retardé. La couleur reste utile. Le texte et la forme portent le sens lorsque la couleur ne peut pas être perçue.

Les légendes doivent exister en texte, pas uniquement dans une clé colorée peinte sur la carte. Un filtre de catégorie doit indiquer son état sélectionné dans le nom du contrôle ou dans un libellé adjacent. Ne dites pas à la personne de « suivre l’épingle rouge » dans le texte de l’interface. Nommez le lieu. La section sur l’IA ci-dessous applique cette règle aux réponses générées.

Que doivent entendre les technologies d’assistance ?

Annoncez le résultat d’une action, pas le moteur de rendu. Un état utile dit que quatre magasins correspondent aux filtres, qu’un itinéraire est prêt et combien de temps il prend, ou qu’aucune entrée accessible ne correspond. « Tuile chargée », « marqueur déplacé » et « centre de carte modifié » sont du bruit. Une région live entourant toute la carte lirait ces événements techniques et noierait la phrase dont la personne a besoin. WAI documente une technique, ARIA22, pour utiliser role=status afin de présenter des messages d’état. Cette technique est un exemple de moyen de satisfaire WCAG, pas une obligation pour chaque carte d’utiliser exactement ce rôle (W3C, 2026).

Le canal utile signale un nombre de résultats, un itinéraire prêt et l’absence de correspondance d’entrée accessible. Le canal ignoré liste les chargements de tuiles, les déplacements de marqueurs et les changements de centre de carte. Les noms de magasins, distances et l’itinéraire de 18 minutes sont illustratifs. Annoncez l’état sur lequel la personne peut agir.

La recherche et les filtres demandent la même discipline. Après une requête, annoncez une fois le nombre ou l’état vide, pas un flux de mises à jour de marqueurs. Gardez l’annonce assez courte pour interrompre poliment. Ne déplacez pas le focus dans la carte lorsque le nombre change. La liste reste l’endroit où la personne lit les correspondances, et la carte reflète le même ensemble.

Pourquoi la réponse de l’IA doit-elle nommer le lieu ?

Une réponse d’IA cartographique doit pouvoir se suffire à elle-même en texte. « Downtown Pharmacy est ouverte jusqu’à minuit et se trouve à 1,2 mile de votre origine sélectionnée » nomme le lieu, les horaires et la distance. « J’ai mis en évidence l’épingle rouge » renvoie au canevas et échoue pour toute personne qui ne peut pas voir cette épingle. La carte peut sélectionner le même lieu et tracer un itinéraire. La phrase doit malgré tout porter la décision. Diffusez la réponse terminée, ou un bref résumé, dans le canal d’état. N’envoyez pas chaque token aux technologies d’assistance et ne déplacez pas le focus vers le chat à chaque fragment.

La réponse utile nomme Downtown Pharmacy, l’heure de fermeture et la distance depuis une origine sélectionnée. La carte montre ce lieu et un itinéraire. La réponse rejetée dit seulement qu’une épingle rouge a été mise en évidence. Le nom de la pharmacie, les horaires et la distance sur la figure sont illustratifs.

Tenez le modèle à l’écart de la décision d’accès. L’hôte autorise les enregistrements, et la réponse ne peut décrire que les lieux déjà présents dans l’ensemble de résultats. Ne laissez pas le texte généré inventer une entrée sans marche, des toilettes accessibles ou une certification absente des données sources. Si l’enregistrement ne comporte pas de champ d’accessibilité, la réponse doit indiquer que cette information est inconnue. Une mise en évidence sur la carte est une confirmation facultative, pas le contenu de la réponse.

Qu’est-ce qui fonctionne encore lorsque la carte ne peut pas se redistribuer ?

Le critère de succès 1.4.10 de WCAG 2.2 considère certains contenus comme nécessitant une mise en page bidimensionnelle pour leur usage ou leur sens. La Note 2 cite les images nécessaires à la compréhension, telles que les cartes et diagrammes, et accepte le défilement bidimensionnel pour ces parties. L’exception couvre la carte. Elle ne couvre pas le titre de page, la recherche, les filtres, le texte des résultats, les boutons, la réponse de l’IA ni la carte de détail. Avec une largeur étroite ou un fort zoom, empilez la liste au-dessus ou au-dessous de la carte, gardez la carte dans sa propre région défilable et laissez le texte hors de cette région. La personne doit encore pouvoir accomplir la tâche lorsque le canevas n’est qu’un petit volet.

Les échecs nécessitent la même séparation. Si les tuiles ne se chargent pas, la liste de résultats, les détails et l’action principale restent disponibles. Indiquez que la carte n’a pas chargé et conservez les enregistrements accessibles. Un canevas vide sans texte est une tâche cassée, pas un problème de style. La réduction des mouvements compte également ici. Ne dépendez pas d’une longue animation de déplacement pour communiquer quel lieu a été sélectionné. Déplacez la sélection et mettez la liste à jour même lorsque le mouvement de caméra est raccourci ou ignoré.

Où placer les cartes interactives accessibles à côté de Kaleidr ?

Conservez la recherche, les filtres, la liste de résultats, les détails, les actions principales et les messages d’état sur la page hôte. Partagez avec la carte les identifiants de lieu, d’itinéraire, de sélection, de filtre et d’ensemble de résultats. Kaleidr Studio permet aux équipes de transformer des idées en cartes interactives avec des lieux, du contenu et des comportements (Kaleidr, 2026). Viewer intègre une carte publiée via son share id et ne nécessite pas de publishable key pour cette intégration (Kaleidr, 2026). La documentation développeur décrit Chat comme Spatial AI dans la carte de l’hôte, Viewer comme la publication d’une carte, Tile comme des fonds de carte conçus et Editor comme le dessin et l’édition (Kaleidr, 2026). L’hôte reste responsable du parcours accessible autour de ces surfaces.

La page hôte possède la recherche, les filtres, la liste de résultats, les détails, les actions et les messages d’état. Des identifiants partagés relient cette page à Studio, Viewer, Chat et à la carte. Le pied de la figure indique que Kaleidr ne garantit pas automatiquement la conformité WCAG. Tester l’expérience livrée reste la responsabilité de l’éditeur.

Un modèle ou un composant cartographique peut fournir une base. Le guide de lancement sans code indique qu’un modèle ne peut pas garantir la conformité une fois qu’un éditeur ajoute des couleurs, du contenu et des comportements cartographiques, car la conformité s’applique à ce qui est réellement livré (Kaleidr, 2026). Testez la tâche complète avec un clavier, un lecteur d’écran, le zoom et une fenêtre étroite. Incluez un cas de panne où la carte ne se charge pas. Cet article est un guide d’implémentation, pas un audit de conformité ni un avis juridique.

Explorer Kaleidr Studio pour concevoir et publier la carte. Lire la documentation développeur pour les surfaces Chat, Viewer, Tile et Editor documentées. Gardez la liste de résultats et la réponse qui nomme le lieu sur la page hôte, liées au même identifiant de lieu que la carte.

Remarque : Kaleidr utilise des outils assistés par IA pour la création d’images, l’amélioration de contenu et la recherche dans ses flux de travail créatifs et de développement.

FAQ

Une alternative clavier remplace-t-elle un chemin au pointeur sans glisser ?

Non. WCAG 2.2 demande un moyen avec un pointeur unique d’effectuer une action de glisser, sauf si le glisser est essentiel ou si l’agent utilisateur détermine ce comportement. L’accès au clavier est une exigence distincte pour la même tâche.

L’exception de redistribution de la carte couvre-t-elle la recherche et la liste de résultats ?

Non. Les cartes et diagrammes peuvent conserver un défilement bidimensionnel. Les titres, la recherche, les filtres, les résultats, les boutons et la réponse de l’IA doivent rester utilisables lorsque la page est étroite ou zoomée.

Kaleidr garantit-il la conformité WCAG d’une carte publiée ?

Non. Studio, Viewer et Chat sont des surfaces produit. La conformité dépend de la page livrée, notamment des libellés, du contraste, de la liste de résultats, des messages d’état et des tests.

Une réponse de carte par IA doit-elle dire « l’épingle rouge » ?

Non. Nommez le lieu, l’état pertinent et la distance ou l’itinéraire en texte. La carte peut sélectionner ce même lieu. La phrase doit se suffire à elle-même sans le canevas.

References

1. World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, December 12, 2024. Includes 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 1.4.1 Use of Color, 1.4.11 Non-text Contrast, and the 1.4.10 Reflow note that lists maps and diagrams. Accessed October 7, 2026. https://www.w3.org/TR/WCAG22/
2. Kaleidr. Embed Interactive Map on a Website. Asks for headings, summaries, and a location list outside the canvas. https://kaleidr.com/blog/how-to-embed-interactive-map-on-a-website
3. W3C Web Accessibility Initiative. Developing a Keyboard Interface. Distinguishes keyboard focus from selection. Accessed October 7, 2026. https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/
4. W3C Web Accessibility Initiative. ARIA22: Using role=status to present status messages. An example technique, not a required implementation. Accessed October 7, 2026. https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22
5. Kaleidr. AI Map Maker for Branded Interactive Maps. Studio turns ideas into interactive maps with locations, content, and behavior. Accessed October 7, 2026. https://kaleidr.com/studio
6. Kaleidr Developer Docs. Viewer. Embeds a published map by its share id, and that embed does not require a publishable key. Accessed October 7, 2026. https://docs.kaleidr.com/viewer
7. Kaleidr Developer Docs. Introduction. Chat is Spatial AI in the host map, Editor is draw and edit, Tile is designed basemaps, and Viewer publishes a map. Accessed October 7, 2026. https://docs.kaleidr.com/
8. Kaleidr. Launch a No-Code Map Website. A template does not guarantee conformance of the experience a publisher ships. https://kaleidr.com/blog/launch-a-map-website-no-code

@misc{w3c_wcag22_2024,
  title  = {Web Content Accessibility Guidelines (WCAG) 2.2},
  author = {{World Wide Web Consortium}},
  year   = {2024},
  url    = {https://www.w3.org/TR/WCAG22/}
}

@misc{kaleidr_embed_map_2026,
  title  = {Embed Interactive Map on a Website},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/how-to-embed-interactive-map-on-a-website}
}

@misc{w3c_keyboard_interface_2026,
  title  = {Developing a Keyboard Interface},
  author = {{World Wide Web Consortium}},
  year   = {2026},
  url    = {https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/}
}

@misc{w3c_aria22_2026,
  title  = {ARIA22: Using role=status to present status messages},
  author = {{World Wide Web Consortium}},
  year   = {2026},
  url    = {https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22}
}

@misc{kaleidr_studio_a11y_2026,
  title  = {AI Map Maker for Branded Interactive Maps},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/studio}
}

@misc{kaleidr_docs_viewer_a11y_2026,
  title  = {Viewer},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/viewer}
}

@misc{kaleidr_docs_home_a11y_2026,
  title  = {Introduction},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/}
}

@misc{kaleidr_launch_map_2026,
  title  = {Launch a No-Code Map Website},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/launch-a-map-website-no-code}
}