Expérience inclusive
Accessibilité numérique tourisme : rendre le voyage réservable par davantage de personnes
L’accessibilité d’un site de tourisme concerne tout le parcours : recherche, choix des dates, lecture des conditions, saisie des voyageurs, paiement et confirmation. Vérifiez la navigation au clavier, les libellés et la compréhension des erreurs. Associez l’évaluation technique à des essais de réservation et aux composants fournis par vos partenaires.
Priorité opérationnelle
Commencez par les tâches que le voyageur doit terminer
Un audit page par page peut produire une longue liste sans dire ce qui bloque réellement. Parcourez plutôt les tâches : trouver une offre, vérifier ses conditions, choisir une date, renseigner les voyageurs, payer, recevoir une confirmation et demander une modification. Notez à chaque étape si l’information est perceptible, le contrôle utilisable et le résultat compréhensible.
Débranchez la souris. Le focus doit rester visible et logique, chaque action doit être atteignable, et aucun calendrier, filtre ou dialogue ne doit piéger l’utilisateur.
Surveillez les composants propres au voyage
Suggestions annoncées, saisie libre possible et libellés non ambigus.
Navigation clavier, dates indisponibles explicites et format compréhensible.
Compteurs nommés, âges expliqués et erreurs proches du champ.
État sélectionné perceptible et résultats mis à jour sans perdre le contexte.
Liste équivalente, lieux nommés et informations accessibles sans geste complexe.
Total, devise, taxes, échéances et conditions lisibles avant engagement.
Rendre une erreur corrigeable sans recommencer la réservation
Un message visible ne suffit pas si le voyageur ne retrouve pas le champ en cause ou perd sa saisie. Le W3C recommande un retour clair sur le résultat de l’envoi, des indications de correction et des messages reliés aux contrôles concernés. La couleur seule ne doit pas porter l’erreur.
| Situation | Comportement à vérifier | Preuve de réussite |
|---|---|---|
| Date de naissance absente | Résumé d’erreurs avec lien vers le champ, libellé conservé et format expliqué. | Atteindre le champ, comprendre puis corriger sans chercher dans toute la page. |
| Tarif modifié | Ancien montant, nouveau total, devise et choix de poursuivre ou revenir. | Aucune validation automatique de l’écart ; décision et total final perceptibles. |
| Authentification du paiement | Transition annoncée et retour explicite après succès, refus ou abandon. | Retrouver l’état du dossier sans payer une seconde fois par incertitude. |
| Interruption ou expiration | Avertissement et reprise selon les contraintes de sécurité. | Distinguer les informations préservées de celles à renseigner de nouveau. |
Conservez le navigateur, les aides techniques, les étapes et l’obstacle observé. Ce scénario contrôle la possibilité de terminer une tâche ; il ne constitue pas à lui seul une évaluation complète de conformité.
W3C WAI — notifications et erreurs de formulaire, consulté le 17/10/2026.
Combinez trois niveaux de test
- Contrôles automatiques. Repérez rapidement attributs absents, contrastes et erreurs de structure courantes.
- Tests experts. Parcourez au clavier, avec zoom, lecteur d’écran et plusieurs appareils.
- Tests utilisateurs. Observez des personnes concernées accomplir des tâches représentatives sans les guider.
- Recette des tiers. Incluez moteur, paiement, chat, carte et documents dans le même protocole.
- Suivi des régressions. Rejouez les scénarios à chaque évolution importante.
Inscrivez l’accessibilité dans les achats et la production
- Exigences et niveau attendu écrits dans le cahier des charges.
- Démonstration sur des composants réels, pas seulement une déclaration.
- Responsable identifié côté produit, contenu, développement et fournisseur.
- Modèles de contenus avec titres, liens et alternatives correctement guidés.
- Délai de correction défini selon la gravité et le parcours touché.
- Canal de contact accessible pour signaler un obstacle.
- Formation courte et régulière des équipes qui publient ou achètent des composants.
Passer des critères à une réservation corrigeable
Inventoriez les champs du produit, leur rôle et les instructions visibles. Rejouez ensuite une erreur de saisie et un retour à l’étape précédente sur un dossier anonymisé. Le compte rendu doit retrouver le champ, le message et l’information conservée. Vérifiez aussi la connexion et les composants externes : leur présence dans une interface de marque ne démontre pas leur accessibilité. Associez chaque défaut à une étape reproductible et à une correction à vérifier.
Relier un critère à une tâche complète de réservation
Les WCAG 2.2 offrent une référence technique pour examiner les contenus et interactions web. Appliquez les critères pertinents à une tâche réelle : entrer les dates, corriger une erreur, comprendre le prix et retrouver la confirmation. Notez environnement, aide technique employée et résultat observé. Une vérification automatique ou une amélioration du focus ne permet pas de déclarer seul tout le parcours conforme. Les exigences applicables à l’organisation restent à examiner séparément.
W3C : WCAG 2.2 — référence consultée le 10/10/2026 ; portée précisée dans les sources du guide.
Approfondir le parcours : Contrastes des pages voyage : texte, fond et états à relire
La lisibilité doit garder une preuve par élément et contexte. Pour le contraste, couleur de fond, taille et état peuvent changer le repère applicable. Une revue limitée de ratios complète la recette sans certifier tout le parcours accessible.
Contrastes des pages voyage : texte, fond et états à relire · Rapprocher les preuves du parcours
WCAG 2.2 : lire précisément la taille minimale des cibles
Le critère 2.5.8 de niveau AA porte sur une cible d’au moins 24 × 24 pixels CSS, avec des exceptions définies. Il faut examiner la taille et l’espacement dans le contexte réel.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Mesure | L’unité est le pixel CSS, pas le pixel physique du téléphone. | Vérifier les liens d’aide, flèches du calendrier et commandes de fermeture au zoom. |
| Exceptions | Le texte prévoit notamment espacement suffisant, équivalent, lien dans une phrase, contrôle de l’agent utilisateur ou présentation essentielle. | Documenter la raison applicable ; ne pas considérer tous les petits boutons comme automatiquement conformes. |
| Niveau | 24 × 24 est le minimum AA de ce critère, à distinguer des exigences renforcées. | Évaluer aussi clavier, focus, erreurs et parcours complet avant toute déclaration de conformité. |
Un seul critère réussi ne démontre pas la conformité WCAG de l’ensemble du service.
W3C — WCAG 2.2, critère 2.5.8 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
WCAG 2.2 : garder le contrôle actif visible au clavier
Un menu fixe ou un bandeau peut masquer le champ que le visiteur vient d’atteindre au clavier.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Minimum AA | Le critère 2.4.11 demande que le composant recevant le focus ne soit pas entièrement caché par un contenu créé par le site. | Parcourir les champs avec Tab en présence du bandeau cookies et de l’en-tête fixe. |
| Renforcé AAA | Le critère 2.4.12 demande qu’aucune partie du composant ne soit cachée par ce contenu. | Distinguer visibilité partielle minimale et visibilité complète. |
| Contenu ouvert | Si un contenu ouvert par l’utilisateur masque le composant, il doit pouvoir le révéler sans déplacer le focus. | Vérifier par exemple une fermeture avec Échap, puis la visibilité du même contrôle. |
Lecture ciblée de deux critères. Leur réussite seule ne démontre pas la conformité de tout le parcours.
W3C WAI — WCAG 2.2, critères 2.4.11 et 2.4.12 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Mise en situation
Cas concret : réserver sans souris ni lecture visuelle de la page
Un parcours peut sembler simple à l’écran et devenir impraticable lorsque le calendrier, le choix des voyageurs ou les erreurs de formulaire ne sont pas annoncés correctement. L’accessibilité concerne aussi les contenus ajoutés par les fournisseurs et les widgets externes. Exemple fictif : une personne choisit un séjour au clavier, saisit les voyageurs puis reçoit une erreur sur la date de naissance. Le test doit vérifier qu’elle retrouve le champ concerné, comprend la correction attendue et conserve les informations déjà saisies. Préparez aussi un cas de tarif expiré : le nouveau prix et l’action à effectuer doivent être accessibles avant de poursuivre la réservation.
Le test à organiser
Réaliser une recherche, choisir une offre et envoyer une demande au clavier seul, puis avec un lecteur d’écran. Tester les états d’erreur, les changements de prix et les confirmations, sur mobile comme sur ordinateur. Constituez un parcours court avec recherche, calendrier, sélection, formulaire et confirmation. Notez l’ordre de navigation, la visibilité du focus et les éléments qui bloquent une action. Faites examiner les messages d’erreur près des champs et le récapitulatif général. Pour un composant tiers, conservez la version testée et transmettez au partenaire les étapes permettant de reproduire le problème avec des données fictives.
La décision à documenter
Intégrer ces vérifications à la recette de chaque évolution. Demander aux prestataires comment leurs composants sont testés et comment les corrections sont livrées, au lieu de se limiter à une déclaration générale. Priorisez les blocages qui empêchent de rechercher, comprendre le prix ou finaliser une demande. Affectez à chaque correction un responsable et un cas de vérification. Après une mise à jour du moteur ou du paiement, rejouez le parcours de référence. Les textes alternatifs doivent décrire l’information utile de l’image ; une scène illustrative ne remplace pas les informations d’accès ou d’équipement d’un établissement identifié.
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- W3C : WCAG 2.2 : Référence technique d’accessibilité web ; pas une certification du parcours ni une détermination des obligations du pays. (consultée le )
- W3C WAI — notifications et erreurs de formulaire : Retours sur soumission, résumé des erreurs et association aux champs ; la recette de réservation est un exemple éditorial. (consultée le )
- W3C — WCAG 2.2, critère 2.5.8 : Un seul critère réussi ne démontre pas la conformité WCAG de l’ensemble du service. (consultée le )
- W3C WAI — WCAG 2.2, critères 2.4.11 et 2.4.12 : Lecture ciblée de deux critères. Leur réussite seule ne démontre pas la conformité de tout le parcours. (consultée le )
Questions fréquentes
Questions utiles avant de décider
L’accessibilité se limite-t-elle aux textes alternatifs ?
L’accessibilité couvre la compréhension et l’utilisation des contenus et des interactions. Un parcours touristique comprend notamment des dates, des choix d’occupation, des conditions tarifaires et des formulaires. Les images utiles demandent une alternative adaptée à leur fonction. Testez aussi la navigation au clavier, l’identification des champs et la possibilité de comprendre puis corriger une erreur sans perdre les autres informations saisies.
Comment tester un moteur de réservation tiers ?
Définissez un scénario représentatif et parcourez les étapes réellement proposées par le partenaire : recherche, date, offre, voyageurs et paiement de démonstration. Documentez le navigateur, la version du composant et les actions nécessaires pour reproduire un blocage. Faites préciser le responsable de la correction et les modalités de mise à jour. Une nouvelle version du composant doit être revue sur les étapes sensibles.
Peut-on automatiser l’audit d’accessibilité ?
Les outils automatiques détectent une partie des erreurs. Ils ne remplacent ni les tests au clavier et au lecteur d’écran, ni l’évaluation de la compréhension, ni les essais avec des personnes concernées.
Par où commencer sur un site existant ?
Corrigez d’abord les blocages des parcours à forte valeur : navigation, recherche, formulaire de contact, réservation, paiement et accès aux documents. Installez ensuite des règles de conception et de recette pour éviter les régressions.
