Ce que WCAG 2.1 AA signifie réellement pour les visites Matterport

WCAG 2.1 AA est la norme de référence de l'Accessibility Act européen, de la norme EN 301 549, du RGAA en France et de la norme israélienne 5568. Mais qu'exige-t-elle concrètement une fois appliquée à une visite virtuelle Matterport ? Voici, critère par critère, ce que chacun implique très concrètement pour votre expérience 3D.

WCAG en 30 secondes

Les Règles pour l'accessibilité des contenus Web (WCAG) reposent sur quatre principes. Tout contenu web doit être :

1. Perceptible chacun doit pouvoir percevoir le contenu par au moins un de ses sens.
2. Utilisable chacun doit pouvoir interagir avec l'interface.
3. Compréhensible chacun doit pouvoir comprendre le contenu et le fonctionnement de l'interface.
4. Robuste le contenu doit fonctionner de façon fiable sur les différentes technologies et aides techniques.

Le niveau AA se situe au milieu : ni le strict minimum (niveau A), ni le plus exigeant (niveau AAA). C'est le niveau que les régulateurs du monde entier ont retenu comme seuil de conformité raisonnable. Chacun des critères qui suivent relève d'une exigence de niveau A ou AA.

Perceptible : vos utilisateurs peuvent-ils voir et entendre votre contenu ?

1.1.1, Contenu non textuel (niveau A)

Ce que le critère exige : chaque élément non textuel doit disposer d'une alternative textuelle qui remplit la même fonction.

Ce que cela signifie pour Matterport : l'environnement 3D est entièrement visuel. Une visite Matterport standard ne décrit nulle part, par du texte, ce que le visiteur a sous les yeux. Une surcouche d'accessibilité ajoute des sous-titres par panorama qui décrivent chaque espace — « Vous vous trouvez dans le grand hall des locomotives, face à la machine à vapeur des années 1920 » —, de sorte que les utilisateurs de lecteurs d'écran et les visiteurs qui dépendent des sous-titres savent où ils sont et ce qui les entoure.

1.3.1, Information et relations (niveau A)

Ce que le critère exige : l'information et les relations structurelles véhiculées visuellement doivent également être disponibles par programmation.

Ce que cela signifie pour Matterport : les boutons des points d'intérêt, le panneau de sous-titres, les sélecteurs de langue et les commandes d'accessibilité doivent tous s'appuyer sur un HTML sémantique et des rôles ARIA appropriés. Là où un utilisateur voyant aperçoit un bouton flottant dans l'espace 3D, un utilisateur de lecteur d'écran doit entendre « Bouton d'information : moteur de la locomotive », avec le bon rôle et la bonne étiquette. On obtient ce résultat avec role="button", aria-label et un HTML structuré qui reproduit la hiérarchie visuelle.

1.4.3, Contraste (minimum) (niveau AA)

Ce que le critère exige : le texte doit présenter un rapport de contraste d'au moins 4,5:1 par rapport à son arrière-plan. Le texte de grande taille (18 pt, ou 14 pt en gras) requiert au moins 3:1.

Ce que cela signifie pour Matterport : les éléments de la surcouche — sous-titres, étiquettes de points d'intérêt, boutons, commandes — se superposent à un arrière-plan 3D mouvant, qui change sans cesse au fil des déplacements du visiteur. Or vous n'avez aucune prise sur la couleur de cet arrière-plan. La solution : un fond sombre semi-transparent derrière chaque élément textuel, qui garantit le rapport de contraste quoi qu'il y ait derrière. Un mode contraste élevé permet en outre de passer à un contraste maximal pour une lisibilité encore meilleure.

1.4.11, Contraste des éléments non textuels (niveau AA)

Ce que le critère exige : les composants d'interface et les objets graphiques doivent présenter un contraste d'au moins 3:1 par rapport aux couleurs adjacentes.

Ce que cela signifie pour Matterport : boutons des points d'intérêt, sélecteur de langue, bascules du panneau d'accessibilité… chaque élément interactif doit se détacher visuellement de la scène 3D qui se trouve derrière lui. Cela passe par des fonds de boutons en aplat de couleur, des bordures visibles et des états de focus francs, dont le contraste ne dépend jamais de la scène 3D.

1.4.4, Redimensionnement du texte (niveau AA)

Ce que le critère exige : le texte doit pouvoir être agrandi jusqu'à 200 % sans perte de contenu ni de fonctionnalité.

Ce que cela signifie pour Matterport : la surcouche doit offrir des commandes de taille de police. Quand un visiteur agrandit le texte, les sous-titres, les descriptions des points d'intérêt et toutes les étiquettes d'interface doivent se réagencer proprement, sans déborder de leur conteneur ni chevaucher d'autres éléments. On y parvient grâce à un réglage de taille de police mémorisé, qui s'applique à toute la surcouche.

Utilisable : vos utilisateurs peuvent-ils naviguer et interagir ?

2.1.1, Clavier (niveau A)

Ce que le critère exige : toutes les fonctionnalités doivent être utilisables au moyen d'une interface clavier.

Ce que cela signifie pour Matterport : c'est la lacune la plus criante d'une visite Matterport standard. La visionneuse par défaut se pilote uniquement à la souris ou au doigt. Une surcouche d'accessibilité ajoute une navigation au clavier complète : Tabulation pour parcourir les points d'intérêt, Entrée pour les ouvrir, Échap pour fermer les panneaux, flèches ou raccourcis pour passer d'un panorama à l'autre. Et chaque élément interactif de la surcouche — sélecteur de langue, commandes de police, bascule de contraste élevé, lecteur audio — doit s'utiliser au clavier.

2.1.2, Pas de piège au clavier (niveau A)

Ce que le critère exige : si un utilisateur peut accéder à un composant au clavier, il doit pouvoir en ressortir.

Ce que cela signifie pour Matterport : lorsqu'un visiteur ouvre un panneau de point d'intérêt ou les réglages d'accessibilité, une pression sur Échap ou Tabulation doit ramener le focus vers l'interface principale, à coup sûr. Aucun composant ne doit enfermer le focus clavier dans une boucle. D'où une gestion rigoureuse du focus : retenir où il se trouvait avant l'ouverture d'un panneau, puis l'y replacer à la fermeture.

2.4.2, Titre de page (niveau A)

Ce que le critère exige : les pages doivent avoir des titres descriptifs.

Ce que cela signifie pour Matterport : la balise <title> de la page doit décrire la visite : « Parc Wolfson, visite virtuelle accessible », et non « Matterport Showcase » ou un titre passe-partout. Et quand le visiteur passe à un nouveau panorama, ce titre devrait se mettre à jour automatiquement pour indiquer l'endroit où il se trouve.

2.4.3, Ordre de focus (niveau A)

Ce que le critère exige : les composants focusables doivent recevoir le focus dans un ordre qui préserve le sens et l'utilisabilité.

Ce que cela signifie pour Matterport : l'ordre de tabulation doit épouser une logique spatiale : d'abord les commandes d'accessibilité, puis le sélecteur de langue, puis les boutons de points d'intérêt dans un enchaînement cohérent, puis les commandes de navigation. Quand un panneau de point d'intérêt s'ouvre, le focus y entre ; quand il se referme, le focus retourne sur le bouton qui l'avait ouvert.

2.4.7, Visibilité du focus (niveau AA)

Ce que le critère exige : le focus clavier doit être visible.

Ce que cela signifie pour Matterport : chaque élément focusable a besoin d'un indicateur de focus clair et bien visible. Pour les boutons de points d'intérêt qui flottent dans l'espace 3D, il faut un contour à fort contraste, visible sur n'importe quel arrière-plan. Le contour par défaut du navigateur ne suffit généralement pas dans un contexte 3D : il faut des styles de focus sur mesure, au contraste et à la taille suffisants.

Compréhensible : vos utilisateurs peuvent-ils suivre ce qui se passe ?

3.1.1, Langue de la page (niveau A)

Ce que le critère exige : la langue par défaut de la page doit être identifiée par programmation.

Ce que cela signifie pour Matterport : l'attribut HTML lang doit être renseigné correctement : lang="fr" pour le français, lang="he" pour l'hébreu, etc. Quand un visiteur change de langue dans la surcouche, l'attribut lang doit suivre, et pour les langues qui s'écrivent de droite à gauche, comme l'hébreu et l'arabe, l'attribut dir doit basculer sur rtl.

3.1.2, Langue d'un passage (niveau AA)

Ce que le critère exige : lorsqu'un contenu comporte un texte dans une langue différente de la langue par défaut de la page, ce texte doit être identifié par programmation.

Ce que cela signifie pour Matterport : si une visite en hébreu affiche le titre d'une exposition en anglais, ce titre doit porter un attribut lang="en". Dans une visite multilingue, chaque bloc de sous-titres et chaque zone de contenu de point d'intérêt doit indiquer la bonne langue, pour que les lecteurs d'écran adoptent le bon moteur de prononciation.

3.2.1, Au focus (niveau A)

Ce que le critère exige : déplacer le focus vers un composant ne doit pas déclencher automatiquement de changement de contexte.

Ce que cela signifie pour Matterport : atteindre un bouton de point d'intérêt par tabulation ne doit pas ouvrir tout seul le panneau correspondant. De même, donner le focus au sélecteur de langue ne doit pas changer la langue. C'est à l'utilisateur d'activer explicitement (Entrée ou Espace) pour déclencher quoi que ce soit. Cela semble évident, et pourtant c'est un piège classique des interfaces 3D interactives.

Robuste : cela fonctionne-t-il avec les aides techniques ?

4.1.2, Nom, rôle et valeur (niveau A)

Ce que le critère exige : pour tous les composants d'interface, le nom, le rôle et l'état doivent pouvoir être déterminés par programmation.

Ce que cela signifie pour Matterport : chaque composant sur mesure de la surcouche — boutons de points d'intérêt, lecteur audio, curseur de taille de police, bascule de contraste — réclame les attributs ARIA qui conviennent. Un bouton de point d'intérêt appelle role="button" et aria-label="Info : moteur de la locomotive". Le lecteur audio appelle role="region" et aria-label="Narration audio". La bascule de contraste, elle, appelle aria-pressed="true/false". Faute de quoi, les aides techniques sont incapables de dire ce que sont les commandes ni dans quel état elles se trouvent.

4.1.3, Messages d'état (niveau AA)

Ce que le critère exige : les messages d'état doivent pouvoir être déterminés par programmation, via un rôle ou des propriétés, afin d'être restitués par les aides techniques sans recevoir le focus.

Ce que cela signifie pour Matterport : quand le visiteur passe à un nouveau panorama et que le sous-titre se met à jour, ce changement doit être annoncé aux lecteurs d'écran sans leur dérober le focus. On y arrive avec une région aria-live="polite" qui enveloppe le contenu des sous-titres : dès que le texte change, le lecteur d'écran énonce automatiquement la description du nouveau panorama. Même chose pour les messages d'état du type « Langue passée à l'arabe » ou « Contraste élevé activé ».

Ce qu'une visite Matterport standard ne respecte pas

Pour y voir clair, voici où se situe une visite Matterport par défaut face aux critères ci-dessus :

Une visite Matterport par défaut échoue, totalement ou partiellement, à 14 des 14 critères WCAG 2.1 AA applicables. Ce n'est pas un écart de conformité, c'est une absence pure et simple de conformité.

Les normes qui renvoient à WCAG

WCAG 2.1 AA n'est pas une simple recommandation : c'est la norme technique sur laquelle s'appuient les grandes réglementations :

• Accessibility Act européen (Union européenne) La directive (UE) 2019/882 s'impose aux États membres depuis le 28 juin 2025, et la norme harmonisée EN 301 549 en traduit les exigences au regard de WCAG.
• EN 301 549 (Europe) La norme européenne harmonisée d'accessibilité des TIC reprend telles quelles les exigences de WCAG 2.1 AA.
• RGAA (France) Le Référentiel général d'amélioration de l'accessibilité, calé sur WCAG, fait office de cadre de référence pour l'accessibilité numérique en France.
• Norme israélienne 5568 Calée sur WCAG 2.0 AA, assortie de dispositions supplémentaires pour la prise en charge de l'hébreu et de l'arabe.

Respecter WCAG 2.1 AA, c'est se mettre en conformité, ou tout près de l'être, avec l'ensemble de ces cadres réglementaires d'un seul coup.

Vous n'avez pas à construire cela vous-même

Implémenter toutes ces exigences par-dessus une visite Matterport demande une maîtrise pointue du SDK Matterport, de la conformité WCAG, des modèles ARIA, de la mise en page multilingue (y compris de droite à gauche) et de la conception d'interactions 3D. C'est un croisement de compétences très particulier, que la plupart des équipes de développement n'ont pas en interne.

C'est exactement le métier de Geemaps Accessibility. Nous avons déjà traité chacune de ces exigences en production — 4 langues, conformité WCAG 2.1 AA complète — pour le déploiement « White Square » de la municipalité de Tel-Aviv-Jaffa, dans le parc Wolfson. À votre visite, nous appliquons cette même surcouche, déjà éprouvée.