L'accessibilité des sites web des hôtels et la loi européenne sur l'accessibilité de 2026

La loi qui a fait de votre moteur de réservation un logiciel soumis à la réglementation

Le 28 juin 2025, un logiciel que vous n’avez probablement pas développé est devenu soumis à la réglementation européenne : votre moteur de réservation. La loi européenne sur l’accessibilité, officiellement la directive (UE) 2019/882, est entrée en vigueur ce jour-là, et l’une des catégories de services qu’elle couvre est le commerce électronique. Vendre une chambre à un consommateur via un site web ou une application relève du commerce électronique. Cela signifie que le widget dans lequel un client sélectionne ses dates, choisit une chambre, saisit les informations de sa carte bancaire et clique sur « Payer maintenant » doit fonctionner pour une personne qui navigue à l’aide d’un clavier, utilise un lecteur d’écran ou a besoin d’un texte plus grand et d’un contraste plus élevé pour lire le prix. La plupart des hôtels indépendants n’ont jamais effectué de tests à cet égard. Le processus de réservation qui génère vos revenus directs, la partie de votre infrastructure dont la plupart des exploitants sont les plus fiers, est également celle qui risque le plus de tomber en panne dès la première pression sur la touche Tab du clavier. Un moteur de réservation hôtelier moderne doit désormais franchir cet obstacle, non pas comme un simple atout, mais comme une obligation légale pour vendre en ligne aux résidents de l’UE.

La loi ne se limite pas au widget de réservation. Elle s’étend à l’ensemble du service numérique lié à la vente : les pages du site web menant à la réservation, l’e-mail de confirmation, l’espace client où le client gère sa réservation, l’application mobile si vous en proposez une, ainsi que les documents que vous envoyez après le séjour. Le parcours client orchestré par votre système de gestion hôtelière, depuis la confirmation de réservation jusqu’au message d’avant-arrivée, en passant par la facture que vous envoyez par e-mail au moment du départ, est désormais considéré comme faisant partie intégrante du service de commerce électronique. Cet article dresse un tableau réaliste de la situation en 2026 pour un opérateur indépendant : ce qu’exige l’EAA, qui est réellement concerné une fois que l’exemption pour les micro-entreprises est correctement appliquée, la norme technique sous-jacente à la loi, les onze manquements entraînant un échec à l’audit, le fonctionnement des mesures coercitives et des amendes sur cinq marchés majeurs, ainsi qu’un plan en 30 jours qu’un gestionnaire peut mettre en œuvre sans faire appel à une agence spécialisée.

J’écris pour Prostay, et notre équipe fournit le moteur de réservation, les modèles de sites web et le système de messagerie client sur lesquels s’appuient bon nombre de ces flux ; nous avons donc passé deux ans à faire en sorte que cette pile technique passe les audits d’accessibilité dans cinq langues et une douzaine de transpositions nationales. Les délais, seuils et cas de non-conformité présentés ci-dessous proviennent de la directive et des normes publiées, de notre propre travail de mise en conformité sur les sites clients en production, ainsi que de la première vague de plaintes et de recommandations émises par les organismes nationaux de contrôle jusqu’en 2025 et au début de 2026. Il n’y a plus de délai de grâce à attendre. La date d’application est dépassée. La seule question qui vaille la peine d’être posée est de savoir si votre site est aujourd’hui conforme, et pour la plupart des indépendants, la réponse honnête est « pas encore ».

Ce qu’exige réellement la loi européenne sur l’accessibilité

L’EAA est une directive relative au marché unique. Son objectif est d’empêcher vingt-sept pays d’élaborer vingt-sept règles d’accessibilité incompatibles entre elles, en établissant une norme de référence unique pour une liste définie de produits et de services commercialisés dans toute l’UE. La liste des produits comprend les ordinateurs, les smartphones, les terminaux de paiement, les distributeurs de billets et les liseuses électroniques. C’est la liste des services qui concerne les hôtels : elle couvre les services bancaires aux particuliers, les communications électroniques, l’accès aux médias audiovisuels, certains aspects du transport de passagers et le commerce électronique. La directive définit le commerce électronique comme la vente de produits ou de services à un consommateur via un site web ou une application mobile. Un hôtel vendant directement des chambres en ligne à un particulier entre pleinement dans cette définition.

En termes simples, la directive exige que le service soit perceptible, utilisable, compréhensible et robuste pour les personnes en situation de handicap. Elle ne fournit pas de liste de contrôle dans le texte juridique. Elle définit plutôt des résultats fonctionnels (les informations doivent être accessibles via plusieurs canaux sensoriels, le contenu doit être navigable sans souris, le texte doit être redimensionnable et lisible, les délais doivent être ajustables) et renvoie à une norme technique harmonisée pour les détails vérifiables. Pour le Web, ces détails sont définis par les WCAG, que j’aborde plus en détail dans une section ultérieure. Concrètement, pour un opérateur, cela signifie que la réservation et toutes les étapes associées doivent pouvoir être effectuées par un client qui ne voit pas l’écran, ne peut pas utiliser de souris, n’entend pas les messages audio ou ne peut pas lire de petits textes à faible contraste.

Trois obligations s’ajoutent à celle d’ordre technique et sont faciles à oublier. Premièrement, vous devez publier une déclaration d’accessibilité expliquant en quoi le service répond aux exigences et indiquant un moyen de vous contacter en cas de problème. Deuxièmement, vous devez conserver des preuves de conformité, car si un organisme de régulation ou un client vous conteste, c’est à vous qu’incombe la charge de prouver que le service est accessible (ou que vous remplissez les conditions pour bénéficier d’une dérogation). Troisièmement, si vous affirmez qu’une correction spécifique imposerait une charge disproportionnée, vous devez documenter cette évaluation à l’avance ; vous ne pouvez pas inventer cette excuse après le dépôt d’une réclamation. Aucune de ces trois obligations n’est techniquement difficile à respecter. Or, elles font toutes systématiquement défaut.

Qui est concerné et l’exemption pour les micro-entreprises que tout le monde interprète mal

La phrase la plus souvent répétée dans la couverture médiatique de l’EAA par le secteur hôtelier est « les petits hôtels sont exemptés ». C’est à moitié vrai, et c’est justement cette moitié erronée qui met les établissements en difficulté. La directive prévoit une exemption pour les micro-entreprises qui fournissent des services, une micro-entreprise étant définie comme une entreprise comptant moins de 10 personnes et dont le chiffre d’affaires annuel ou le total du bilan ne dépasse pas 2 millions d’euros. Si votre hôtel est une entité juridique autonome respectant ces deux critères, vos obligations en tant que prestataire de services sont levées. Il s’agit là d’un allègement réel et utile pour un établissement véritablement de petite taille.

C’est là que les exploitants se trompent. Le seuil est calculé au niveau de l’entité juridique qui fournit le service, et la structure des hôtels les fait souvent franchir discrètement cette limite. Un établissement comptant huit employés en contact avec la clientèle, mais disposant d’une société de gestion, d’une société propriétaire et d’une équipe centrale de réservation partagée, peut facilement dépasser les dix salariés une fois que l’effectif est correctement comptabilisé. Un hôtel-boutique dont le chiffre d’affaires lié aux chambres est modeste peut tout de même franchir la barre des 2 millions d’euros une fois que la restauration, les événements et le spa sont ajoutés au chiffre d’affaires. Un hôtel isolé au sein d’un petit groupe est rarement une micro-entreprise, même si chaque établissement pris individuellement semble de petite taille. L’exonération s’applique au niveau de l’entité, et non au niveau de l’impression générale, et c’est à vous qu’il incombe de prouver que vous remplissez les conditions requises. Si vous comptez vous en prévaloir, notez l’effectif et le chiffre d’affaires ou le montant du bilan de l’entité concernée pour l’exercice comptable en question, et conservez cette note avec vos autres documents de conformité.

Deux autres mises en garde. L’allègement fiscal pour les micro-entreprises s’applique aux obligations en matière de services ; il n’exempte pas les produits que vous vendez ni les fournisseurs auprès desquels vous vous approvisionnez. Votre fournisseur de moteur de réservation, votre gestionnaire de canaux de distribution et les agences de voyages en ligne (OTA) qui revendent vos chambres dépassent presque tous largement le seuil et sont tenus de fournir des logiciels accessibles, quelle que soit la taille de votre entreprise ; cela signifie que les outils s’améliorent pour vous, que vous soyez personnellement concerné ou non. De plus, cette exemption est une cible mouvante : le jour où vous embaucherez votre onzième employé ou franchirez la barre des 2 millions d’euros, le compte à rebours commencera, et vous ne pourrez plus compter sur une période de transition pluriannuelle, car les délais de transition prévus par la directive sont déjà expirés. Considérer l’accessibilité comme une caractéristique permanente de la conception de votre site revient moins cher que de la traiter comme un seuil que vous contournez jusqu’à ce que cela devienne impossible.

Il existe un autre groupe qui relève clairement du champ d’application de la directive et qui est souvent oublié : toute entreprise qui n’est pas une micro-entreprise. Un hôtel de 60 chambres avec un restaurant, un établissement urbain de 120 chambres, un groupe possédant quatre établissements, un opérateur d’appartements avec services ayant une présence régionale. Il s’agit là d’acteurs indépendants courants selon les normes du secteur de l’hôtellerie, et ils sont clairement soumis à la réglementation. Si cela vous correspond, la question de l’exemption ne se pose pas et la seule question utile est de savoir dans quel délai vous pouvez rendre votre site conforme.

La norme sous-jacente à la loi : EN 301 549 et WCAG 2.1 AA

La directive définit les résultats attendus ; la norme définit les critères de vérification. La norme EN 301 549 est la norme européenne harmonisée relative à l’accessibilité des produits et services TIC, et c’est le document auquel se réfère un régulateur ou un auditeur lorsqu’il souhaite vérifier si votre site est effectivement conforme. Le respect des parties pertinentes de la norme EN 301 549 vous confère une présomption de conformité à la loi sur l’accessibilité numérique (EAA), ce qui signifie en clair : si vous respectez la norme, vous êtes présumé conforme à la loi, sauf preuve du contraire.

En ce qui concerne les contenus web, la norme EN 301 549 n’invente pas ses propres règles. Elle adopte les WCAG (Web Content Accessibility Guidelines), les directives d’accessibilité des contenus web publiées par le W3C, au niveau de conformité AA. Les WCAG 2.1 AA constituent l’objectif opérationnel pour 2025 et 2026 ; les WCAG 2.2 ajoutent quelques critères supplémentaires et représentent l’orientation future de la norme. Se conformer à la version 2.2 est donc un choix tourné vers l’avenir, mais la version 2.1 AA constitue le seuil minimal actuellement requis par la loi. Il s’agit du même objectif que les sites web du secteur public de l’UE doivent respecter depuis la directive sur l’accessibilité du web de 2016 ; la norme est donc aboutie, les outils sont performants, et votre développeur n’a aucune excuse pour la considérer comme quelque chose d’exotique.

Les WCAG organisent leurs critères de succès selon quatre principes qu’il est utile de connaître par leur nom, car ils correspondent parfaitement aux lacunes des hôtels. Perceptible : le client peut-il assimiler les informations ? Il s’agit des alternatives textuelles pour les images, des légendes et du contraste des couleurs. Utilisable : le client peut-il interagir avec l’interface ? Il s’agit de l’accessibilité au clavier, d’un délai suffisant pour remplir un formulaire et de l’absence de contenu clignotant susceptible de déclencher des crises d’épilepsie. Compréhensible : le contenu et le comportement sont-ils prévisibles ? Il s’agit de libellés clairs, d’un langage lisible et de messages d’erreur utiles. Robuste : le site fonctionnera-t-il avec les technologies d’assistance, aujourd’hui et à l’avenir ? Il s’agit d’un balisage propre, conforme aux normes, qu’un lecteur d’écran peut analyser. Presque toutes les défaillances des sites d’hôtels que je décris ci-dessous constituent une violation spécifique et vérifiable de l’un de ces quatre principes, et les solutions sont donc tout aussi concrètes.

Les consignes pratiques pour un exploitant qui ne écrit pas de code sont succinctes. Indiquez à la personne chargée de la création et de la maintenance de votre site que l’objectif visé est le niveau AA des WCAG 2.1, demandez-lui de confirmer par écrit que le site et le processus de réservation y sont conformes, et sollicitez le rapport d’audit ou de test qui étaye cette affirmation. S’ils ne sont pas en mesure d’en fournir un, vous avez identifié votre première lacune. S’ils le peuvent, conservez-le avec votre déclaration d’accessibilité et votre note relative aux micro-entreprises, car ensemble, ces documents constitueront votre défense le jour où une réclamation vous parviendra.

Onze manquements en matière d’accessibilité qui font échouer un audit

Parmi les sites d’hôtels que notre équipe a mis en conformité et les types de réclamations publiés par les organismes nationaux au cours de la première année, ces onze lacunes représentent la majeure partie du risque. Elles sont classées approximativement par ordre de fréquence d’apparition et par gravité des obstacles qu’elles posent à un client réel, chacune accompagnée de la solution et du critère WCAG auquel elle correspond.

1. Impossibilité de finaliser la réservation au clavier. La pire défaillance qui soit. Un sélecteur de date qui ne réagit qu’à un clic de souris, une fiche de chambre que l’on ne peut pas sélectionner avec la touche Entrée, un calendrier que l’on peut ouvrir mais dont on ne peut pas sortir (un « piège du clavier »). Si un client ne peut pas sélectionner de dates, choisir une chambre et accéder au bouton de paiement en utilisant uniquement les touches Tab, flèches et Entrée, la réservation est impossible pour les utilisateurs de clavier et de lecteur d’écran. Il s’agit d’un non-respect des WCAG de niveau A (2.1.1 Clavier, 2.1.2 Absence de piège clavier) et un seul cas suffit à faire échouer l’ensemble de l’évaluation. Solution : utilisez des contrôles HTML natifs dans la mesure du possible, et testez les gestionnaires de clavier sur tout widget personnalisé.
2. Contraste des couleurs inférieur au seuil requis. Ce gris pâle sur fond blanc que les designers adorent. Le texte normal doit présenter un rapport de contraste d’au moins 4,5 pour 1 par rapport à son arrière-plan ; le texte en gros caractères et les composants interactifs tels que les boutons et les bordures de formulaire doivent présenter un rapport d’au moins 3 pour 1 (WCAG 1.4.3 et 1.4.11). L’exemple le plus courant est le bouton principal « Réserver maintenant », dont la couleur correspond à la teinte douce de la marque et qui affiche un rapport de 2,8 pour 1. Solution : assombrissez le bouton ou le texte jusqu’à ce qu’un outil de vérification du contraste le valide, puis intégrez les valeurs conformes à la palette de couleurs de la marque afin d’éviter toute régression.
3. Champs de formulaire sans étiquette programmatique. Un champ affichant « Invités » comme texte de remplacement gris mais ne comportant pas d’étiquette réelle est considéré comme vide par un lecteur d’écran ; l’utilisateur entend « modifier le texte, vide ». Les textes de remplacement ne sont pas des étiquettes (WCAG 1.3.1, 4.1.2). Solution : un élément « label » approprié associé à chaque champ de saisie, visible, et non pas simplement un texte de remplacement qui disparaît lorsque le champ est sélectionné.
4. Images porteuses de sens sans texte alternatif. Une photo de chambre, une carte, un plan d’étage ou une bannière promotionnelle avec un prix intégré à l’image et sans texte alternatif. L’utilisateur d’un lecteur d’écran n’obtient aucune information (WCAG 1.1.1). Solution : un texte alternatif descriptif pour les images significatives, un texte alternatif vide pour celles qui sont purement décoratives, et ne jamais placer un prix ou une date limite uniquement à l’intérieur d’une image.
5. Des messages d’erreur qui n’indiquent pas ce qui ne va pas ni où. Une bordure rouge et « Erreur, veuillez réessayer » sans aucune indication sur le champ qui a posé problème ni la raison de l’erreur. Un visiteur qui ne voit pas la bordure rouge ne sait pas comment procéder (WCAG 3.3.1, 3.3.3). Solution : un texte d’erreur qui nomme le champ et le problème (« La date de départ doit être postérieure à la date d’arrivée »), lié au champ afin que les technologies d’assistance puissent l’annoncer.
6. Des titres utilisés pour l’esthétique, et non pour la structure. Les utilisateurs de lecteurs d’écran naviguent à l’aide des titres, de la même manière que les utilisateurs voyants parcourent rapidement un texte. Une page dont le texte est stylisé pour ressembler à un titre sans utiliser de véritable élément de titre, ou qui passe directement de H1 à H4, est difficile à parcourir (WCAG 1.3.1). Solution : une hiérarchie logique des titres, un seul H1 par page, sans saut de niveaux à des fins d’effet visuel.
7. Un focus invisible. Lorsque vous parcourez la page à l’aide de la touche Tab, l’élément actif doit afficher un contour visible. De nombreux thèmes suppriment l’anneau de focus pour des raisons esthétiques, ce qui désoriente les utilisateurs du clavier (WCAG 2.4.7). Solution : un indicateur de focus clair et à fort contraste sur chaque élément interactif, et ne plus supprimer le contour par défaut sans le remplacer.
8. Contenu qui ne fonctionne que dans un seul sens d’orientation ou d’interaction. Une étape de réservation qui ne fonctionne qu’en mode paysage, ou des instructions qui reposent sur la forme ou la position (« cliquez sur l’icône verte ronde à droite »). Cela pose des difficultés aux utilisateurs sur différents appareils et avec différentes configurations d’assistance (WCAG 1.3.4, 1.3.3). Solution : prendre en charge les deux orientations et décrire les commandes par leur nom, et non uniquement par leur couleur ou leur position.
9. Des délais d’expiration sans possibilité de prolongation. Une session de réservation qui expire et vide le panier après quelques minutes, sans avertissement ni option de prolongation, pénalise toute personne qui met plus de temps à taper, à lire ou à utiliser un dispositif de sélection par commutateur (WCAG 2.2.1). Solution : avertir l’utilisateur avant l’expiration du délai et proposer une prolongation en un clic, ou supprimer cette limite stricte.
10. Éléments intégrés tiers inaccessibles. Le widget de chat, le carrousel d’avis, la carte, la bannière relative aux cookies. Une bannière relative aux cookies qui retient le focus et bloque la page jusqu’à ce qu’elle soit fermée à l’aide de la souris constitue un obstacle total étonnamment courant (WCAG 2.1.1, 2.4.3). Solution : choisissez des composants tiers accessibles et testez-les en situation réelle, car leurs défaillances deviennent les vôtres.
11. Absence de déclaration d’accessibilité et de moyen de contact. Il ne s’agit pas d’un défaut de code, mais d’une non-conformité juridique. L’EAA exige la publication d’une déclaration et la mise à disposition d’un moyen permettant à un utilisateur de signaler un problème d’accessibilité. Son absence est la chose la plus facile à repérer pour un organisme de contrôle et la plus simple à corriger pour vous. Solution : publiez la déclaration (abordée ci-dessous) et assurez le suivi du canal de contact.

Le moteur de réservation : là où la plupart des hôtels échouent en premier

Si vous ne devez renforcer qu’un seul élément, renforcez le moteur de réservation, car il concentre à la fois le risque juridique et les revenus au même endroit. Il gère la transaction à laquelle la loi accorde le plus d’importance, c’est la partie la plus interactive du site, et il s’agit généralement d’un widget tiers sur lequel l’hôtel a le moins de contrôle. C’est cette combinaison qui explique pourquoi c’est là que les défaillances apparaissent en premier et sont les plus graves.

Les problèmes récurrents dans les widgets de réservation sont prévisibles. Des sélecteurs de dates personnalisés en JavaScript qui ignorent le clavier. Des cartes de sélection de chambres qui sont des divs cliquables plutôt que de véritables boutons, invisibles pour les technologies d’assistance. Des flux en plusieurs étapes qui font passer l’utilisateur à une nouvelle étape sans signaler au lecteur d’écran que la page a changé, de sorte que l’utilisateur ne se rend pas compte qu’il s’est passé quelque chose. Des champs de paiement situés dans un iframe qui n’a pas été étiqueté. Un bouton « Continuer » qui ne s’active qu’après un survol de la souris, action que l’utilisateur d’un clavier ne peut pas déclencher. Chacun de ces problèmes est corrigible, et aucun d’entre eux ne relève de votre code si vous utilisez un moteur hébergé, ce qui explique précisément pourquoi la relation avec le fournisseur est cruciale.

Considérez vos fournisseurs de moteur de réservation et de gestionnaire de canaux comme des opérateurs économiques soumis à leurs propres obligations en matière d’accessibilité (EAA), et demandez-leur d’en apporter la preuve. Demandez-leur, par écrit, la documentation attestant de leur conformité aux normes WCAG 2.1 AA ou EN 301 549. Demandez-leur selon quelle version de la norme ils ont effectué leurs tests et à quelle date. Demandez-leur si le test a porté sur le widget intégré tel qu’il s’affiche sur le domaine d’un client, et pas seulement sur leur site de démonstration, car un widget peut réussir le test de manière isolée et échouer une fois que le CSS de votre thème supprime le contour de sélection. Conservez les réponses dans vos dossiers. Si un fournisseur ne peut pas ou ne veut pas fournir de preuve de conformité en 2026, c’est un signal d’alerte en matière d’approvisionnement qui mérite d’être pris en compte, et c’est de plus en plus souvent la raison invoquée par les hôtels pour changer de moteur.

Testez-le ensuite vous-même, car si le contrat vous protège juridiquement, c’est le client qui utilise le site en conditions réelles. Rangez votre souris et réservez une chambre sur votre propre domaine en utilisant uniquement le clavier. Activez le lecteur d’écran intégré à votre ordinateur portable (VoiceOver sur Mac, Narrator sous Windows) et essayez la même opération les yeux fermés pour la dernière étape. Vous en apprendrez davantage en quinze minutes ainsi qu’en une semaine passée à lire les PDF des fournisseurs, et vous identifierez les points précis où un véritable client abandonne et réserve plutôt sur une OTA.

Le site web et le parcours client au-delà de la réservation

Le moteur de réservation est le point crucial, mais l’EAA englobe le service, et le service correspond à l’ensemble du parcours qu’effectue un consommateur pour acheter et utiliser la chambre. Cela fait entrer le reste du site dans le champ d’application d’une manière que les hôtels sous-estiment.

Commencez par les pages qui mènent à la réservation, car un client qui ne peut pas lire les descriptions de vos chambres ou comparer vos tarifs n’atteindra jamais le widget. Les pages de chambres comportant des galeries de photos sans texte alternatif, les tableaux tarifaires qui s’appuient uniquement sur la couleur pour indiquer l’option la moins chère, et les prix « à partir de 149 EUR » affichés à l’intérieur d’une image sont courants, et chacun de ces éléments bloque un type d’utilisateur différent. La navigation a également son importance : un méga-menu qui ne s’ouvre qu’au survol, un menu mobile qui bloque le focus, ou un sélecteur de langue inaccessible au clavier constituent autant d’obstacles sur le chemin critique menant à la vente. Aucun de ces aspects n’est particulièrement prestigieux, mais un site bien conçu les traite avec le même sérieux que celui qui permet de créer un site hôtelier rapide et à fort taux de conversion, car l’accessibilité et la conversion vont de pair.

Ne vous arrêtez pas à la vente. L’espace de gestion de compte ou de réservation, où un client modifie ses dates ou annule sa réservation, fait partie intégrante du service de commerce électronique. Il en va de même pour tout portail destiné aux clients que vous utilisez pour les ventes incitatives, les formulaires à remplir avant l’arrivée ou l’enregistrement en ligne. Si un client peut effectuer une réservation de manière accessible mais ne peut ensuite pas modifier ou annuler celle-ci sans recourir à la vue ou à une souris, vous avez simplement déplacé le problème au lieu de le résoudre. Cartographiez l’ensemble du parcours une seule fois (recherche, page de la chambre, réservation, confirmation, gestion de la réservation, préparatifs d’arrivée, enregistrement, départ) et vérifiez chaque étape, pas seulement le flux principal.

Deux problèmes moins évidents méritent d’être mentionnés. Une vidéo sans sous-titres sur la bannière d’accueil ou dans la visite virtuelle d’un établissement est inaccessible pour les clients sourds ou malentendants (WCAG 1.2.2), et la « lecture automatique avec son » aggrave encore la situation. De même, tout contenu en mouvement, les carrousels qui défilent selon une minuterie ou les animations qui ne peuvent pas être mises en pause détournent l’attention et, pour certains utilisateurs, constituent une réelle difficulté (WCAG 2.2.2). La solution dans les deux cas est la modération : sous-titrez la vidéo et permettez à l’utilisateur de mettre en pause ou d’arrêter tout ce qui bouge.

Les PDF, les e-mails de confirmation et les documents que personne ne teste

Les documents envoyés par un hôtel constituent l’aspect le plus souvent négligé, car personne ne considère un e-mail ou un PDF comme faisant partie d’un service numérique réglementé. Or, c’est bien le cas lorsqu’ils s’inscrivent dans le cadre d’une transaction de commerce électronique.

L’e-mail de confirmation de réservation en est l’exemple le plus évident. S’il est conçu sous la forme d’une seule image aplatie (ce qui est encore étonnamment courant avec les anciens outils de messagerie), un lecteur d’écran ne lit rien d’utile et le client ne dispose d’aucun enregistrement accessible de ce qu’il a réservé. La solution consiste à envoyer un véritable e-mail HTML doté d’une structure logique, d’un contraste lisible, de textes de lien descriptifs et d’une alternative en texte brut. Il en va de même pour le message d’avant-arrivée, le reçu de paiement et le relevé que vous envoyez par e-mail au moment du départ. Ces documents proviennent du PMS et de la couche de messagerie ; la solution consiste donc généralement à modifier un modèle plutôt qu’à intervenir au cas par cas pour chaque client.

Les PDF sont encore pires, car leur contenu est masqué. Un PDF contenant les conditions générales, une facture, une proposition d’événement, un contrat de groupe ou un menu téléchargeable généré par l’exportation d’un document mis en page est généralement un PDF non balisé, ce qui, pour un lecteur d’écran, revient à peu près à une photo d’une page : visible, mais illisible. Les PDF balisés, dotés d’un ordre de lecture correct, contenant du texte réel plutôt que des images numérisées et comportant un texte alternatif pour les images, constituent le format accessible. L’approche pragmatique pour un hôtel consiste à privilégier autant que possible les pages HTML accessibles (une page présentant les conditions générales vaut mieux qu’un PDF des conditions générales) et à baliser les PDF que vous devez absolument envoyer. Si vous produisez des contrats ou des propositions en grand nombre, intégrez l’accessibilité dans le modèle une seule fois plutôt que de corriger chaque document à la main.

Une remarque pratique sur la portée et la proportionnalité : la directive reconnaît que la mise en conformité de l’ensemble des archives historiques de chaque document peut constituer une charge disproportionnée, et il existe des nuances concernant les contenus créés avant la date d’application. Cela ne vous autorise toutefois pas à ignorer les documents de votre flux de transactions en cours. La confirmation qu’un client reçoit cette semaine est d’actualité, entre dans le champ d’application de la directive et est facile à corriger au niveau du modèle. Concentrez d’abord vos efforts sur ce point.

La déclaration d’accessibilité que vous êtes tenu de publier

Il s’agit de la mesure de mise en conformité la moins coûteuse et celle qui fait le plus souvent défaut. L’EAA attend d’un prestataire de services qu’il publie, dans ses conditions générales ou sur son site, des informations sur la manière dont le service répond aux exigences d’accessibilité. En pratique, cela signifie une déclaration d’accessibilité claire et facile à trouver, et sa rédaction ne représente qu’un après-midi de travail, pas un projet.

Une déclaration utile couvre une courte liste de points. Un engagement clair en faveur de l’accessibilité et la norme que vous visez (WCAG 2.1 niveau AA via la norme EN 301 549). Le champ d’application (le site web, le moteur de réservation, les e-mails destinés aux clients). Les limites connues que vous reconnaissez en toute honnêteté, y compris tout composant tiers que vous ne contrôlez pas entièrement et les mesures que vous prenez à cet égard. Un moyen de contact, par e-mail ou via un formulaire, permettant à un client de signaler un problème d’accessibilité et de demander des informations dans un format accessible. Et la date de la dernière révision de la déclaration, car une déclaration datant de trois ans donne l’impression d’avoir été abandonnée. Si vous invoquez l’exemption applicable aux micro-entreprises, indiquez-le clairement et conservez les chiffres qui l’étayent dans vos dossiers plutôt que dans la déclaration publique.

Deux mises en garde. Ne copiez pas intégralement un modèle de déclaration d’accessibilité du secteur public ; ceux-ci sont rédigés pour un régime juridique différent (la directive sur l’accessibilité du Web) et font référence à des mécanismes de signalement qui ne s’appliquent pas à un hôtel privé. Et ne publiez pas de déclaration affirmant une conformité totale que vous ne pouvez pas prouver, car une déclaration exagérée est pire qu’une déclaration modeste mais exacte : elle transforme une lacune de bonne foi en fausse déclaration dès qu’un client constate un manquement que vous aviez déclaré inexistant. Écrivez la vérité, engagez-vous sur une date de révision et surveillez régulièrement le canal de contact.

Fonctionnement de l’application de la réglementation et des amendes, pays par pays

L’EAA est une directive ; elle n’inflige donc pas directement d’amende. Chaque État membre l’a transposée dans son droit national et a défini son propre organisme de contrôle, sa procédure de plainte et son plafond de sanction. Cela signifie que le risque concret dépend fortement de la localisation de vos clients et de votre lieu d’activité, et que les montants varient d’un ordre de grandeur. La tendance observée au cours de la première année a été constante sur tous les marchés : les autorités publient des lignes directrices, donnent suite aux plaintes et aux contrôles ponctuels de surveillance du marché, et ordonnent des mesures correctives dans un délai imparti avant de recourir à la sanction maximale. Dans la réalité, ce qui déclenche une procédure pour un hôtel, c’est généralement une plainte émanant d’un client ou d’une association de défense des personnes en situation de handicap, et non un organisme de régulation parcourant le web au hasard.

Irlande

L’Irlande a transposé l’EAA par le biais d’une réglementation nationale qui désigne les autorités chargées de la surveillance du marché et de l’application de la loi, et prévoit des sanctions tant administratives que pénales en cas de non-conformité persistante. L’application de la loi est répartie entre différents organismes en fonction du produit ou du service concerné. Pour un hôtel anglophone vendant ses services sur le marché irlandais et, plus largement, sur le marché de l’UE, l’Irlande constitue une juridiction pertinente car la langue et la portée géographique font des consommateurs irlandais une clientèle naturelle. La procédure est la même qu’ailleurs : une plainte ou un contrôle ponctuel donne lieu à une intervention et à une injonction de mise en conformité, les sanctions s’alourdissant pour les opérateurs qui ignorent cette injonction. Tenez à disposition votre déclaration, vos preuves de conformité et votre registre des mesures correctives.

Allemagne : la BFSG

La transposition allemande est la Barrierefreiheitsstärkungsgesetz (BFSG), entrée en vigueur le 28 juin 2025. Il s’agit de l’un des régimes les plus clairement définis et l’un des plus cités en raison de sa rigueur. La BFSG prévoit des amendes administratives pouvant atteindre 100 000 euros et confère à l’autorité de surveillance du marché le pouvoir d’interdire la fourniture d’un service non conforme, ce qui, pour un hôtel en ligne, se traduit par une injonction qui touche directement le canal de vente des chambres. L’Allemagne dispose également d’une structure de surveillance spécifique mise en place à l’échelle des Länder. Pour tout hôtel bénéficiant d’une demande allemande significative – ce qui concerne une grande partie des établissements situés dans les villes européennes et les stations alpines –, la BFSG est le régime à prendre en compte dans la planification, car elle combine un plafond d’amende réel avec le pouvoir d’interrompre le service.

France : le RGAA et l’amende pour les grandes entreprises

La France a superposé la directive EAA à un régime d’accessibilité existant. Le RGAA (Référentiel général d’amélioration de l’accessibilité) est le cadre de référence français qui met en œuvre les WCAG, et la France inflige déjà des amendes aux grandes entreprises qui ne publient pas les informations relatives à l’accessibilité et ne respectent pas les exigences, avec des sanctions administratives pouvant atteindre 50 000 euros par service non conforme et une astreinte si le manquement n’est pas corrigé dans le délai imparti. La transposition de l’EAA étend la portée des obligations et du dispositif de contrôle. La France dispose également d’une culture active de plaintes émanant des consommateurs et des associations de défense des droits, de sorte que la probabilité concrète d’une contestation est plus élevée que ne le laisse supposer la simple lettre de la loi. Si vous commercialisez vos produits en France, attendez-vous à ce que le RGAA soit le critère de référence utilisé par un auditeur.

Espagne

L’Espagne a transposé l’EAA dans son droit national en prévoyant des sanctions administratives échelonnées en fonction de la gravité, selon la structure espagnole bien connue des infractions « leves », « graves » et « muy graves », chacune correspondant à une fourchette d’amendes distincte. La surveillance de l’accessibilité pour les personnes en situation de handicap relève d’organismes établis, notamment l’OADIS (Oficina de Atención a la Discapacidad), tandis que les autorités sectorielles se chargent de la surveillance du marché. Pour un bien immobilier espagnol ou tout hôtel bénéficiant d’une forte demande sur le marché espagnol, la structure de sanctions échelonnées signifie que le coût d’un manquement est proportionnel à sa gravité et à sa persistance, ce qui récompense les mesures correctives volontaires prises rapidement et sanctionne les exploitants qui, après avoir reçu un avertissement, ne prennent aucune mesure.

Italie : l’héritage de la « Legge Stanca »

L’Italie possède la plus longue tradition législative en matière d’accessibilité au sein de ce groupe. La « Legge Stanca » remonte à 2004, et la transposition italienne de la directive EAA (s’appuyant sur le cadre défini par le D.Lgs. 82/2022 et des décrets connexes) étend les obligations du secteur privé et les pouvoirs de contrôle, l’AgID (l’Agenzia per l’Italia Digitale) occupant une place centrale dans l’architecture de surveillance. La législation italienne dans ce cadre prévoit des sanctions pouvant atteindre, pour les cas les plus graves, jusqu’à 5 % du chiffre d’affaires, ce qui représente l’exposition proportionnelle la plus élevée parmi les cinq marchés considérés ici. Pour un hôtel italien, la combinaison d’une tradition juridique bien établie et d’un plafond lié au chiffre d’affaires rend particulièrement intéressante l’adoption d’une posture documentée et défendable.

La leçon à retenir, valable pour tous les marchés, n’est pas de mémoriser cinq barèmes d’amendes. Elle réside dans le fait que la même norme EN 301 549 et le même objectif WCAG 2.1 AA satisfont à tous ces barèmes à la fois ; la stratégie la plus efficace consiste donc à se conformer une seule fois à la norme, à publier une déclaration en toute transparence, à conserver ses preuves et à répondre rapidement à toute réclamation. Un établissement qui respecte ces quatre principes est en mesure de se défendre dans chacune de ces juridictions, quel que soit le client qui se plaint en premier.

Comment auditer votre propre site en un après-midi

Vous n’avez pas besoin d’une agence pour identifier vos principaux problèmes. Un gestionnaire de site sans aucune connaissance en programmation peut mettre au jour la plupart des défaillances à haut risque en un seul après-midi à l’aide d’outils gratuits et du matériel déjà disponible sur son bureau. Un audit réalisé par un spécialiste vaut la peine d’être commandé une fois que vous avez effectué cette première étape et que vous souhaitez obtenir une évaluation complète et certifiée, mais l’auto-audit vous permet de déterminer la gravité de la situation et de savoir par où commencer pour y remédier.

Effectuez ces cinq étapes dans l’ordre. L’étape « clavier » : débranchez ou ignorez la souris et effectuez une réservation complète à l’aide des touches Tab, Maj-Tab, des flèches et Entrée. Notez chaque point où vous vous retrouvez bloqué, où vous ne voyez pas l’élément sélectionné ou où vous ne pouvez pas quitter un champ de saisie. Cette étape à elle seule permet de détecter les défaillances de niveau A, qui sont les plus importantes. La phase « lecteur d’écran » : activez VoiceOver (Mac, Cmd-F5) ou Narrator (Windows, Ctrl-Win-Entrée), fermez les yeux lors des étapes clés, puis essayez de comprendre chaque page et de finaliser la réservation. Soyez attentif aux champs lus comme « vide », aux images lues comme des noms de fichiers et aux étapes qui changent sans avertissement. Le contrôle du contraste : passez votre texte principal, vos boutons et les bordures de vos formulaires dans un outil gratuit de vérification du contraste (celui de WebAIM est la référence) et signalez tout élément présentant un rapport inférieur à 4,5 pour 1 pour le texte, ou inférieur à 3 pour 1 pour les gros caractères et les composants. Le contrôle automatisé : lancez un scanner gratuit, tel que l’extension de navigateur WAVE ou axe DevTools, sur votre page d’accueil, une page de chambre et chaque étape de réservation ; ces outils détectent rapidement les étiquettes manquantes, les textes alternatifs et les problèmes de titres, bien qu’ils ne repèrent qu’environ un tiers des problèmes, ce qui explique pourquoi les contrôles manuels sont prioritaires. La vérification par zoom : réglez le zoom du navigateur à 200 % et réorganisez la page dans une fenêtre étroite ; le contenu qui disparaît, se chevauche ou oblige à un défilement horizontal ne répond pas aux critères de réorganisation et de redimensionnement.

Notez les résultats de chaque vérification dans une liste partagée, en les classant par emplacement (moteur de réservation, pages de chambres, navigation, e-mails, documents) et par gravité (empêche une réservation, nuit à une réservation, problème esthétique). Cette liste servira de base au plan de correction. La plupart des établissements indépendants terminent l’après-midi avec entre quinze et quarante problèmes identifiés et la certitude que trois ou quatre d’entre eux sont ceux qui coûtent réellement des réservations.

Le guide de mise en conformité en matière d’accessibilité en 30 jours

Un plan de 30 jours pour faire passer un site indépendant type de « nous n’avons jamais effectué de tests » à « défendable et en progression ». Une seule personne axée sur les opérations peut le mener à bien, en faisant appel au développeur web ou au fournisseur du moteur de réservation pour les travaux de développement. Prévoyez quelques heures par semaine de la part du responsable et un bloc de temps concentré de la part de la personne chargée de la maintenance du site.

Jours 1 à 4 : audit et triage. Effectuez l’auto-audit en cinq étapes décrit ci-dessus sur le site en production, aussi bien sur ordinateur que sur mobile. Rassemblez tous les résultats dans une liste unique, classez-les par type d’interface et par gravité, puis identifiez les trois ou quatre problèmes qui bloquent ou compromettent sérieusement une réservation. Ce sont là les priorités ; résistez à la tentation de commencer par les détails esthétiques mineurs.

Jours 5 à 7 : cerner les fournisseurs. Envoyez un e-mail aux fournisseurs du moteur de réservation et du gestionnaire de canaux de distribution et demandez-leur, par écrit, leur documentation de conformité aux normes WCAG 2.1 AA ou EN 301 549, ainsi que la version testée et la date. Demandez-leur comment ils gèrent le widget intégré sur le domaine d’un client. Archivez les réponses. Lorsqu’un fournisseur ne peut pas répondre, consignez cela comme un risque et une décision d’achat potentielle plutôt que comme une correction que vous pouvez effectuer vous-même.

Jours 8 à 16 : corrigez le processus de réservation. C’est la partie la plus ardue. Rendez l’ensemble du processus de réservation utilisable au clavier, rétablissez un indicateur de focus visible, attribuez à chaque champ de formulaire une étiquette pertinente, modifiez les messages d’erreur afin qu’ils mentionnent le champ et le problème, et assurez-vous que le bouton principal et le corps du texte respectent les exigences de contraste. Réexécutez les tests au clavier et avec un lecteur d’écran après chaque modification jusqu’à ce qu’une réservation complète puisse être effectuée sans souris et avec le lecteur d’écran activé.

Jours 17 à 22 : corrigez les pages environnantes. Ajoutez un texte alternatif aux images significatives et laissez le champ « alt » vide pour les images décoratives ; corrigez la structure des titres ; adaptez la navigation et le sélecteur de langue à l’utilisation du clavier ; ajoutez une légende à la vidéo de présentation ou de visite guidée ; et veillez à ce que tout contenu animé puisse être mis en pause. Vérifiez que le site s’adapte correctement à un zoom de 200 %.

Jours 23 à 26 : corrigez les documents et les e-mails. Convertissez les e-mails de confirmation, de pré-arrivée, de reçu et de décompte en HTML structuré avec un contraste lisible et une alternative en texte brut. Transférez les documents que vous pouvez vers des pages HTML accessibles, et balisez les PDF que vous devez conserver. Testez un exemplaire de chaque type avec le lecteur d’écran.

Jours 27 à 28 : publiez la déclaration. Rédigez et publiez une déclaration d’accessibilité honnête couvrant la norme visée, le champ d’application, les limitations connues, un moyen de contact en cas de problèmes et une date de révision. Configurez le canal de contact de manière à ce qu’il aboutisse à une boîte de réception réelle surveillée par une personne.

Jours 29 à 30 : documentation et planification. Rassemblez le dossier de preuve : les conclusions de l’audit et les corrections apportées, les documents de conformité des fournisseurs, la déclaration publiée et, si vous invoquez l’exemption pour micro-entreprise, les chiffres d’effectifs et de chiffre d’affaires qui la justifient. Prévoyez un nouveau test trimestriel récurrent dans votre calendrier, car les sites subissent une régression à chaque mise à jour du thème ou du moteur de réservation. Informez la personne chargée de la mise à jour du site que les nouvelles images doivent être accompagnées d’un texte alternatif et que les nouveaux composants doivent faire l’objet d’un test au clavier, afin que cette rigueur soit maintenue après la fin du projet.

Charge de travail totale sur les 30 jours : environ 25 à 40 heures pour le responsable et un bloc de temps dédié de la part du développeur ou du fournisseur, principalement concentré sur la semaine consacrée au flux de réservation. Les établissements qui mettent en œuvre cette démarche rigoureuse éliminent les dysfonctionnements qui bloquent les véritables clients, adoptent une position défendable et constatent généralement, en effet secondaire, une légère augmentation du taux de finalisation des réservations directes, car les mêmes corrections qui aident un utilisateur de lecteur d’écran aident également un client fatigué utilisant son téléphone dans un environnement mal éclairé.

Le rôle de Prostay, en bref et en toute honnêteté

J’écris pour Prostay, cette section est donc inévitable ; je vais être franc à ce sujet. Prostay fournit le moteur de réservation, les modèles de site web et le système de messagerie client avec une accessibilité intégrée aux composants plutôt qu’ajoutée a posteriori, ce qui signifie que le processus de réservation est conçu pour fonctionner au clavier, que les champs de formulaire comportent de véritables libellés, que l’indicateur de focus est préservé et que la palette de couleurs par défaut de la marque est optimisée pour respecter les normes de contraste. Les e-mails de confirmation, d’avant-arrivée et de décompte envoyés par le système de gestion hôtelière utilisent des modèles structurés et adaptés aux lecteurs d’écran, plutôt que des images aplaties. Rien de tout cela n’est propre à Prostay ; Mews, Cloudbeds et plusieurs autres fournisseurs ont mené un travail sérieux en matière d’accessibilité sur leurs propres solutions, et chacun d’entre eux peut vous fournir une base conforme.

L’argument en faveur de Prostay en particulier est que le moteur de réservation, le site web, le PMS et la messagerie proviennent d’une seule et même équipe qui les teste ensemble selon les normes WCAG 2.1 AA dans les cinq langues du site ; vous n’avez donc pas à intégrer un widget accessible dans un thème inaccessible en espérant que les raccords tiennent le coup. Nous pouvons également vous fournir la documentation de conformité des fournisseurs dont votre dossier de preuves a besoin, ce qui élimine l’une des étapes les plus chronophages du plan en 30 jours. Si vous souhaitez plus de détails sur l’interface client, la présentation du moteur de réservation Prostay vous guide pas à pas ; si vous préférez que notre équipe effectue l’auto-audit et la mise en conformité de votre site en production, réservez une démonstration et nous passerons en revue votre flux de réservation réel plutôt que de vous vendre un forfait d’accessibilité séparé.

Foire aux questions

Les cinq questions les plus fréquemment posées par les hôteliers indépendants au sujet de la loi européenne sur l’accessibilité, auxquelles nous répondons en nous appuyant sur la directive et la norme harmonisée plutôt que sur les résumés de la presse spécialisée.