Accessibilité site hôtel Belgique : checklist réservation

Si votre hôtel à Bruges, votre boutique-hôtel à Anvers ou votre B&B dans les Ardennes accepte des réservations directes via son site, vous êtes légalement tenu de rendre l'expérience de réservation accessible. L'European Accessibility Act (Directive 2019/882) a été transposé en droit belge par la loi du 5 novembre 2023, qui modifie le Code de droit économique pour y intégrer les exigences d'accessibilité des services numériques. Le délai d'application était le 28 juin 2025. Si vous n'avez pas encore audité votre parcours de réservation, vous êtes déjà hors délai.

Vous ne savez pas où en est votre site ? Vous pouvez lancer un scan gratuit sur TrustYourWebsite pour repérer les lacunes d'accessibilité et de conformité les plus fréquentes dans votre parcours de réservation avant qu'un client ou un régulateur ne le fasse.

La bonne nouvelle : vous n'avez pas à tout reconstruire. Vous devez corriger les éléments qui cassent l'expérience pour les visiteurs utilisant un clavier, un lecteur d'écran ou d'autres outils d'accessibilité. La plupart des problèmes se trouvent à trois endroits : le calendrier, la sélection de chambre et le formulaire de paiement. Voyons ce qu'il faut vérifier et comment le réparer.

Le problème du calendrier

Le widget calendrier de votre moteur de réservation est probablement magnifique à la souris. Il échoue catastrophiquement pour les utilisateurs de clavier et de lecteur d'écran.

Voici à quoi ressemble la panne : un visiteur n'utilisant que son clavier appuie sur Tab pour atteindre le champ de date d'arrivée. Le calendrier s'ouvre, mais Tab ne fait plus défiler les mois ni les dates. Il saute tout le calendrier pour atterrir ailleurs sur la page. L'utilisateur de lecteur d'écran entend "cliquable, calendrier" sans aucune idée des dates disponibles ni de comment avancer vers décembre.

À tester :

• Posez votre souris. N'utilisez que Tab, les flèches et Entrée pour naviguer dans le calendrier.
• Pouvez-vous aller à gauche/droite vers le mois précédent et suivant ?
• Pouvez-vous monter/descendre dans les semaines et jours ?
• Pouvez-vous sélectionner une date et fermer le calendrier avec Entrée ?
• Si les trois échouent, votre calendrier doit être reconstruit ou remplacé.

Comment corriger :

La plupart des moteurs de réservation commerciaux (SiteMinder, Cubilis, intégrations API Booking.com) ont des paramètres d'accessibilité dans leur configuration. Cherchez "WCAG" ou "keyboard navigation" dans le panneau d'administration. Si le moteur ne le supporte pas, vous avez trois options : changer de moteur, utiliser une bibliothèque tierce de calendrier accessible (Litepicker ou Flatpickr avec support clavier), ou limiter les clients à la saisie directe des dates (format JJ/MM/AAAA avec instructions claires).

Votre déclaration d'accessibilité (que la loi belge vous oblige à publier) doit lister les barrières connues. Si votre calendrier a un contournement (taper plutôt que cliquer), documentez-le là.

Sélection de chambre : photos et équipements

Les photos de chambre ont besoin de descriptions textuelles. Pas pour le SEO. Pour les clients utilisant un lecteur d'écran.

Quoi écrire :

Plutôt que de compter sur une vignette pour montrer un type de chambre, ajoutez un texte alternatif comme "Chambre double Supérieure avec vue sur jardin, 28 mètres carrés, parquet bois, salle de bain privée." Un utilisateur de lecteur d'écran l'entendra. Un client malvoyant qui a zoomé peut le lire.

Ne décrivez pas seulement le type de chambre. Incluez ce qui est effectivement visible : "Lit double avec linge blanc, fenêtre donnant sur la cour, bureau de travail, télévision à écran plat, climatisation." Des détails concrets aident les clients à décider.

Les icônes d'équipements sont un deuxième problème. Vous avez probablement de petites icônes : une icône de lit pour "lit double", une icône wifi pour "wifi gratuit", une icône parking pour le parking. Ces icônes sont invisibles aux lecteurs d'écran et sans signification sans contexte visuel.

Corrigez-le :

• Ajoutez un libellé texte à côté de chaque icône.
• Si la place manque, utilisez une infobulle ou faites de l'icône elle-même un bouton avec un libellé. Les utilisateurs de lecteur d'écran l'entendront. Les voyants verront le libellé au survol ou au clic.
• Ne comptez jamais sur la couleur seule pour distinguer des types de chambres. Si vous utilisez un carré vert pour "disponible" et un rouge pour "réservé", ajoutez du texte : "Disponible" et "Réservé".

Sélecteurs de nombre de chambres et de personnes

Vos boutons + et − ont besoin de noms accessibles.

La version cassée : un utilisateur de lecteur d'écran arrive sur un bouton + sans libellé. Il appuie, le compteur de chambres augmente, mais le lecteur d'écran ne dit rien. Le client ne sait pas ce qui s'est passé.

La version corrigée : le bouton + s'appelle "+ Plus de chambres" et annonce "2 chambres sélectionnées" après le clic. Le champ d'entrée affiche le nombre. Le lecteur d'écran annonce les mises à jour quand la valeur change.

Voici comment :

• Donnez aux boutons + et − un vrai libellé via aria-label ou un texte visible dans le bouton (ex. "+ Ajouter une chambre").
• Le champ d'entrée lui-même a besoin d'un libellé visible : "Nombre de chambres ?" pas un placeholder qui disparaît au clic.
• Mettez à jour la valeur annoncée quand le nombre change avec aria-live="polite" pour que les utilisateurs de lecteur d'écran l'entendent.

La même logique vaut pour le nombre d'adultes et d'enfants. Chaque sélecteur a besoin d'un libellé clair, de boutons + et − fonctionnels et de mises à jour annoncées.

Étape paiement : libellés et messages d'erreur

Les champs de carte ont besoin de libellés visibles, pas de placeholders qui disparaissent.

La mauvaise approche :

[Jean Dupont________] ← placeholder dit "Nom du titulaire"

Dès que le client commence à taper, le placeholder disparaît et il oublie à quoi sert le champ.

La bonne approche :

Nom du titulaire
[Jean Dupont________]

Le libellé reste visible. Le champ reste clairement marqué.

Appliquez ceci à chaque champ de paiement : nom du titulaire, numéro de carte, date d'expiration, code de sécurité, adresse de facturation.

Les messages d'erreur doivent être spécifiques et liés. Si un client saisit un numéro de carte invalide, n'affichez pas un "Paiement échoué" générique en haut de page. Dites-lui exactement quel champ pose problème : "Le numéro de carte n'est pas valide. Le numéro doit comporter 16 chiffres pour Visa ou Mastercard." Liez le message d'erreur au champ numéro de carte via aria-describedby pour que les utilisateurs de lecteur d'écran sachent quel champ corriger.

Déclaration d'accessibilité : une obligation légale

La loi belge (via la transposition de la Directive 2019/882) vous oblige à publier une déclaration d'accessibilité sur votre site. Elle doit contenir :

• Votre engagement envers l'accessibilité et WCAG 2.1 niveau AA comme norme cible.
• Les barrières ou limitations connues (ex. "Notre widget calendrier requiert l'usage de la souris. Les clients peuvent taper les dates à la place.").
• Comment signaler des barrières manquées : une adresse e-mail ou un formulaire de contact.
• Une voie d'escalade pour les clients souhaitant porter des barrières non résolues devant un régulateur ou un organisme d'égalité.

Beaucoup d'hôtels craignent que cette déclaration soit un aveu. Ce n'en est pas un. C'est de la transparence. Elle montre que vous prenez l'accessibilité au sérieux, avez audité votre site et corrigez les problèmes au fur et à mesure. Notre guide sur les mentions légales d'un site belge parcourt les pages obligatoires que vous devez de toute façon avoir.

Versions linguistiques : néerlandais, français et allemand

Si votre site dessert les néerlandophones et francophones (ce que font la plupart des hôtels belges), les exigences d'accessibilité s'appliquent à chaque version linguistique. Les hôtels de la Communauté germanophone à l'est du pays doivent aussi vérifier leurs pages allemandes.

Vérifiez votre page de réservation néerlandaise et votre page française séparément. Navigation du calendrier, sélection de chambre, champs de paiement doivent fonctionner dans les deux. Cela double votre travail de test mais protège l'ensemble de votre clientèle. La répartition linguistique est aussi une considération pratique pour votre déclaration d'accessibilité : publiez-la dans chaque langue desservie par votre site, pas dans une seule.

Checklist pratique pour votre hôtel

• Testez votre calendrier uniquement au clavier (Tab, flèches, Entrée). S'il échoue, contactez votre fournisseur de moteur de réservation ou passez à une alternative accessible.
• Ajoutez un texte alternatif descriptif à chaque photo de chambre. Mentionnez le type, la taille, l'aménagement et la vue.
• Libellez chaque icône d'équipement avec du texte, pas seulement l'icône visuelle.
• Testez les sélecteurs de nombre de chambres et de personnes avec un lecteur d'écran. Vérifiez que les mises à jour sont annoncées.
• Remplacez les libellés placeholder-only par des libellés visibles sur les champs de paiement.
• Rendez les messages d'erreur spécifiques et liez-les aux champs qu'ils décrivent.
• Publiez une déclaration d'accessibilité avec les barrières connues et votre contact pour les signalements.
• Auditez à la fois votre page de réservation néerlandaise et votre page française.
• Testez avec un lecteur d'écran gratuit (NVDA pour Windows, VoiceOver intégré sur Mac).

Qui applique cela en Belgique

Deux instances comptent ici.

Le SPF Économie (Service public fédéral Économie, FOD Economie en néerlandais) est l'autorité d'application principale sous la transposition belge de l'EAA. Il peut ouvrir des enquêtes sur les plaintes, vous ordonner de corriger les barrières et sanctionner les entreprises qui ne se conforment pas. L'application est déclenchée par plainte, pas par audit proactif. Cela compte : si un client en situation de handicap ne peut pas finaliser une réservation sur votre site, il a des fondements pour déposer une plainte formelle.

UNIA est l'organisme indépendant belge en matière d'égalité. Il traite les plaintes de discrimination fondée sur le handicap, y compris les situations où une barrière numérique empêche quelqu'un d'accéder à un service. UNIA ne fixe pas les normes d'accessibilité mais peut intervenir quand des sites inaccessibles excluent effectivement des clients. Les hôtels relèvent explicitement de sa compétence aux côtés des restaurants et autres entreprises horeca.

Si vous voulez aller au-delà de la conformité de base, AnySurfer est le label belge d'accessibilité pour sites web. Il est attribué après un audit indépendant face aux critères WCAG. Il ne remplace pas votre obligation légale mais signale aux clients et partenaires que votre site a été vérifié indépendamment.

Plus probable qu'une enquête formelle, vous verrez l'impact en réservations perdues. Un client utilisant un lecteur d'écran ou uniquement le clavier abandonnera votre parcours s'il ne fonctionne pas. Il réservera ailleurs. L'accessibilité n'est pas une case à cocher de conformité. C'est une mesure de protection du chiffre d'affaires.

Pour un regard plus large sur la façon dont l'EAA touche les entreprises belges au-delà des hôtels, notre guide EAA pour PME couvre l'éventail complet des services concernés et à quoi ressemble la conformité en pratique. Notre analyse détaillée de la loi d'accessibilité e-commerce 2025 parcourt les cas d'application.

Commencez par votre calendrier et votre formulaire de paiement. Ce sont les points de friction. Testez-les vous-même au clavier et au lecteur d'écran. S'ils échouent, vous avez trouvé votre première priorité. Corrigez le calendrier et vous résolvez le plus gros problème que la plupart des hôtels rencontrent.

Vos clients en situation de handicap ne demandent rien de particulier. Ils demandent la même expérience de réservation que vos clients voyants qui utilisent une souris. Faire que cela fonctionne est votre obligation légale et votre intérêt commercial.