La ley que convirtió tu motor de reservas en un software regulado
El 28 de junio de 2025, un programa informático que probablemente no has programado tú pasó a estar regulado por la legislación de la UE: tu motor de reservas. La Ley Europea de Accesibilidad, conocida formalmente como Directiva (UE) 2019/882, entró en vigor ese día, y una de las categorías de servicios que abarca es el comercio electrónico. Vender una habitación a un consumidor a través de una página web o una aplicación es comercio electrónico. Eso significa que el widget en el que un huésped selecciona las fechas, elige una habitación, introduce los datos de su tarjeta y pulsa «pagar ahora» tiene que funcionar para alguien que navega con un teclado, utiliza un lector de pantalla o necesita un texto más grande y un mayor contraste para leer el precio. La mayoría de los hoteles independientes nunca han realizado pruebas para nada de eso. El proceso de reserva que genera tus ingresos directos —la parte del sistema de la que la mayoría de los operadores se sienten más orgullosos— es también la que tiene más probabilidades de fallar al pulsar la primera tecla del teclado. Un motor de reservas hotelero moderno tiene que superar ese obstáculo ahora mismo, no como algo «que estaría bien tener», sino como un requisito legal para vender en línea a residentes de la UE.
La ley no se limita al widget de reservas. Abarca todo el servicio digital relacionado con la venta: las páginas web que conducen a la reserva, el correo electrónico de confirmación, el área de cuenta donde el huésped gestiona su reserva, la aplicación móvil si dispones de ella y los documentos que envías tras la estancia. El recorrido del huésped que coordina su sistema de gestión hotelera, desde la confirmación de la reserva, pasando por el mensaje previo a la llegada, hasta la factura que envía por correo electrónico al finalizar la estancia, entra ahora en el ámbito de aplicación como parte del servicio de comercio electrónico. Este artículo ofrece una visión realista de la situación en 2026 para un operador independiente: qué exige la EAA, quiénes quedan realmente incluidos una vez que se aplica correctamente la exención para microempresas, la norma técnica en la que se basa la ley, los once motivos por los que se suspende una auditoría, cómo funcionan la aplicación de la normativa y las multas en cinco mercados principales, y un plan de 30 días que un gestor puede llevar a cabo sin contratar a una agencia especializada.
Escribo para Prostay, y nuestro equipo desarrolla el motor de reservas, las plantillas de la página web y el sistema de mensajería para huéspedes en el que se ejecutan gran parte de estos flujos; por ello, hemos dedicado dos años a garantizar que esta plataforma supere las auditorías de accesibilidad en cinco idiomas y una docena de transposiciones nacionales. Los plazos, umbrales y modos de incumplimiento que se indican a continuación proceden de la directiva y las normas publicadas, de nuestro propio trabajo de corrección en sitios web de clientes en funcionamiento, y de la primera oleada de reclamaciones y orientaciones que los organismos nacionales de control han emitido a lo largo de 2025 y hasta 2026. Ya no queda ningún periodo de gracia que esperar. La fecha de aplicación ya ha pasado. La única pregunta que vale la pena plantearse es si su sitio web es defendible hoy en día, y para la mayoría de los independientes la respuesta honesta es que aún no.
Lo que realmente exige la Ley Europea de Accesibilidad
La EAA es una directiva del mercado único. Su objetivo es evitar que veintisiete países elaboren veintisiete normas de accesibilidad incompatibles entre sí, estableciendo una base común para una lista definida de productos y servicios que se comercializan en toda la UE. La lista de productos incluye ordenadores, teléfonos inteligentes, terminales de pago, máquinas expendedoras de billetes y lectores electrónicos. La lista de servicios es la parte que afecta a los hoteles: abarca la banca minorista, las comunicaciones electrónicas, el acceso a los medios audiovisuales, determinados aspectos del transporte de pasajeros y el comercio electrónico. La directiva define el comercio electrónico como la venta de productos o servicios a un consumidor a través de un sitio web o una aplicación móvil. Un hotel que venda habitaciones directamente, por Internet, a un particular entra de lleno en esa definición.
Lo que exige la directiva, en términos sencillos, es que el servicio sea perceptible, manejable, comprensible y robusto para las personas con discapacidad. No incluye una lista de verificación en el texto legal. En su lugar, establece resultados funcionales (la información debe estar disponible a través de más de un canal sensorial, debe poder navegarse por el contenido sin ratón, el texto debe ser redimensionable y legible, y los límites de tiempo deben ser ajustables) y remite a una norma técnica armonizada para los detalles verificables. En el caso de la web, esos detalles son las WCAG, que analizo en una sección posterior. La interpretación práctica para un operador es la siguiente: un huésped que no pueda ver la pantalla, no pueda utilizar un ratón, no pueda oír una indicación de audio o no pueda leer texto pequeño con bajo contraste debe poder completar su reserva y todo el proceso relacionado con ella.
Hay tres obligaciones que se suman a la técnica y que es fácil pasar por alto. En primer lugar, debe publicar una declaración de accesibilidad que explique cómo el servicio cumple los requisitos y facilite una vía de contacto en caso de problemas. En segundo lugar, debe conservar pruebas de conformidad, ya que, si un organismo regulador o un cliente le reclama, la carga de demostrar que el servicio es accesible (o que cumple los requisitos para una exención) recae sobre usted. En tercer lugar, si alegas que una solución concreta supondría una carga desproporcionada, debes documentar esa evaluación con antelación; no puedes inventarte la excusa después de que se presente una reclamación. Ninguna de estas tres obligaciones es técnicamente difícil. Sin embargo, las tres suelen pasarse por alto.
Quiénes entran en el ámbito de aplicación y la exención para microempresas que todo el mundo malinterpreta
La frase más repetida en la cobertura mediática del sector hotelero sobre la EAA es «los hoteles pequeños están exentos». Es cierto a medias, y esa mitad errónea es la que mete a los establecimientos en problemas. La directiva excluye a las microempresas que prestan servicios, y se define como microempresa a una empresa con menos de 10 empleados y una cifra de negocios anual o un balance total que no supere los 2 millones de euros. Si tu hotel es una entidad jurídica independiente que cumple ambos requisitos, tus obligaciones como prestador de servicios quedan exentas. Se trata de un alivio real y útil para un establecimiento verdaderamente pequeño.
Aquí es donde los operadores lo malinterpretan. El umbral se mide a nivel de la entidad jurídica que presta el servicio, y los hoteles están estructurados de tal manera que, sin darse cuenta, superan el límite. Un establecimiento con ocho empleados de atención al público, pero que cuenta con una empresa gestora, una sociedad propietaria y un equipo central de reservas compartido, puede superar fácilmente los diez empleados una vez que se contabiliza el número total de efectivos. Un hotel boutique con unos ingresos modestos por habitaciones puede superar los 2 millones de euros si se suman a la facturación los ingresos por restauración, eventos y spa. Un único hotel perteneciente a un pequeño grupo rara vez es una microempresa, aunque cada establecimiento en sí parezca pequeño. La exención se aplica a nivel de entidad, no a nivel de percepción, y la carga de la prueba de que cumples los requisitos recae sobre ti. Si tiene intención de acogerse a ella, anote el número de empleados y la cifra de facturación o el balance de la entidad en cuestión y del ejercicio fiscal, y guarde esa nota junto con el resto de sus registros de cumplimiento.
Dos advertencias más. La exención para microempresas se aplica a las obligaciones en materia de servicios; no exime a los productos que vendes ni a los proveedores a los que compras. Tu proveedor de motor de reservas, tu gestor de canales y las OTA que revenden tus habitaciones superan casi todos con creces el umbral y tienen que ofrecer software accesible independientemente de tu tamaño, lo que significa que las herramientas están mejorando para ti, estés o no personalmente dentro del ámbito de aplicación. Además, la exención es un objetivo en constante evolución: el día que contrates a tu undécimo empleado o superes los 2 millones de euros, el reloj empieza a correr, y ya no hay un periodo de transición de varios años en el que apoyarte, porque los plazos de transición de la directiva ya han finalizado. Tratar la accesibilidad como una característica permanente del diseño de tu sitio web resulta más económico que considerarla un umbral que puedes eludir hasta que ya no puedas hacerlo.
Hay otro grupo que entra claramente en el ámbito de aplicación y que a menudo se olvida: cualquiera que no sea una microempresa. Un hotel de 60 habitaciones con restaurante, un establecimiento urbano de 120 habitaciones, un grupo de cuatro establecimientos, un operador de apartamentos con servicios con presencia regional. Se trata de empresas independientes normales según los estándares del sector hotelero y están claramente reguladas. Si este es tu caso, el debate sobre la exención carece de sentido y la única pregunta útil es cuánto tardarás en conseguir que la web cumpla con los requisitos.
La norma en la que se basa la ley: EN 301 549 y WCAG 2.1 AA
La directiva establece los resultados; la norma establece las pruebas. La EN 301 549 es la norma europea armonizada sobre accesibilidad de los productos y servicios de las TIC, y es el documento al que recurre un regulador o un auditor cuando quiere saber si tu sitio web cumple realmente con los requisitos. Cumplir con las partes pertinentes de la norma EN 301 549 te otorga una presunción de conformidad con la EAA, lo que en lenguaje sencillo significa: si superas la norma, se presume que has cumplido con la ley, a menos que alguien demuestre lo contrario.
En lo que respecta al contenido web, la norma EN 301 549 no establece sus propias reglas. Adopta las WCAG, las Pautas de Accesibilidad al Contenido Web publicadas por el W3C, en el nivel de conformidad AA. Las WCAG 2.1 AA son el objetivo vigente para 2025 y 2026; las WCAG 2.2 añaden algunos criterios adicionales y son hacia donde se dirige la norma, por lo que desarrollar según la versión 2.2 es la opción con visión de futuro, pero la versión 2.1 AA es el mínimo exigido por la ley en la actualidad. Este es el mismo objetivo que los sitios web del sector público de la UE han tenido que cumplir desde la Directiva sobre accesibilidad web de 2016, por lo que la norma está consolidada, las herramientas son buenas y tu desarrollador no tiene excusa para tratarla como algo exótico.
Las WCAG organizan sus criterios de éxito en torno a cuatro principios cuyos nombres conviene conocer, ya que se corresponden claramente con los errores que cometen los hoteles. Percibible: ¿puede el huésped asimilar la información? Se trata de alternativas de texto para las imágenes, leyendas y contraste de colores. Operable: ¿puede el huésped manejar la interfaz? Se trata del acceso mediante teclado, tiempo suficiente para completar un formulario y la ausencia de contenidos que parpadeen de forma que provoquen convulsiones. Comprensible: ¿son predecibles el contenido y el comportamiento? Se trata de etiquetas claras, un lenguaje legible y mensajes de error útiles. Robusto: ¿funcionará con tecnología de apoyo ahora y en el futuro? Se trata de un marcado limpio y basado en estándares que un lector de pantalla pueda analizar. Casi todos los fallos de los hoteles que describo a continuación son incumplimientos específicos y comprobables de uno de estos cuatro principios, y las soluciones son, en consecuencia, concretas.
Las instrucciones prácticas para un operador que no escribe código son breves. Indica a quien se encargue de crear y mantener tu sitio web que el objetivo es el nivel AA de las WCAG 2.1, pídeles que confirmen por escrito que el sitio y el proceso de reserva lo cumplen, y solicita el informe de auditoría o de pruebas que respalde dicha afirmación. Si no pueden presentarlo, ya has encontrado tu primera deficiencia. Si pueden, guárdalo junto con tu declaración de accesibilidad y tu nota de microempresa, porque, juntos, esos documentos serán tu defensa el día que llegue una reclamación.
Once fallos de accesibilidad que no superan una auditoría
Entre los sitios web de hoteles que nuestro equipo ha corregido y los patrones de quejas publicados por los organismos nacionales durante el primer año, los mismos once fallos representan la mayor parte del riesgo. Se enumeran, más o menos, por orden de frecuencia de aparición y de gravedad con la que obstaculizan a un huésped real, cada uno con su solución y el criterio de las WCAG al que se corresponde.
- No es posible completar la reserva con el teclado. El fallo más grave de todos. Un selector de fechas que solo responde al clic del ratón, una ficha de habitación que no se puede seleccionar con la tecla Intro, un calendario que se puede abrir pero del que no se puede salir (una «trampa de teclado»). Si un huésped no puede seleccionar fechas, elegir una habitación y llegar al botón de pago utilizando únicamente las teclas Tab, las flechas y Intro, la reserva resulta imposible para los usuarios de teclado y lectores de pantalla. Se trata de un fallo de nivel A de las WCAG (2.1.1 Teclado, 2.1.2 Ausencia de trampas de teclado) y un solo caso hace que toda la evaluación sea suspensa. Solución: controles HTML nativos siempre que sea posible y controladores de teclado probados en cualquier widget personalizado.
- Contraste de color por debajo del umbral. Ese gris pálido sobre fondo blanco que tanto gusta a los diseñadores. El texto normal necesita una relación de contraste de al menos 4,5 a 1 con respecto al fondo; el texto grande y los componentes interactivos, como botones y bordes de formularios, necesitan al menos 3 a 1 (WCAG 1.4.3 y 1.4.11). El error más habitual es el botón principal «Reservar ahora», en un color suave de la marca, que presenta una relación de 2,8 a 1. Solución: oscurecer el botón o el texto hasta que supere la comprobación de contraste, e integrar los valores que superen la prueba en la paleta de colores de la marca para evitar que se repita el error.
- Campos de formulario sin etiqueta programática. Un campo que muestra «Huéspedes» como texto de marcador de posición en gris, pero que no tiene una etiqueta real, aparece como vacío para un lector de pantalla; el usuario oye «editar texto, en blanco». Los marcadores de posición no son etiquetas (WCAG 1.3.1, 4.1.2). Solución: un elemento de etiqueta adecuado vinculado a cada campo de entrada, visible, no solo un marcador de posición que desaparece al recibir el foco.
- Imágenes que transmiten significado sin texto alternativo. Una foto de una habitación, un mapa, un plano de planta o un banner promocional con un precio integrado en la imagen y sin texto alternativo. El usuario del lector de pantalla no recibe ninguna información (WCAG 1.1.1). Solución: texto alternativo descriptivo para las imágenes significativas, texto alternativo vacío para las puramente decorativas, y nunca incluir un precio o una fecha límite únicamente dentro de una imagen.
- Mensajes de error que no indican qué ha fallado ni dónde. Un borde rojo y «Error, inténtalo de nuevo» sin indicar qué campo ha fallado ni por qué. Un visitante que no pueda ver el borde rojo no sabrá cómo continuar (WCAG 3.3.1, 3.3.3). Solución: un texto de error que especifique el campo y el problema («La fecha de salida debe ser posterior a la fecha de llegada»), vinculado al campo para que la tecnología de apoyo lo anuncie.
- Encabezados utilizados por motivos estéticos, no estructurales. Los usuarios de lectores de pantalla navegan por los encabezados del mismo modo que los usuarios videntes leen por encima el texto. Una página que aplica estilos al texto para que parezca un encabezado sin utilizar un elemento de encabezado real, o que salta de H1 a H4, resulta difícil de navegar (WCAG 1.3.1). Solución: una estructura lógica de encabezados, un H1 por página, sin saltos de nivel por motivos estéticos.
- Foco que no se ve. Al desplazarse por la página con la tecla Tab, el elemento en foco debe mostrar un contorno visible. Muchos temas eliminan el anillo de foco por motivos estéticos, lo que deja desorientados a los usuarios de teclado (WCAG 2.4.7). Solución: un indicador de foco claro y de alto contraste en cada elemento interactivo, y dejar de eliminar el contorno predeterminado sin sustituirlo.
- Contenido que solo funciona en una orientación o con un único modo de interacción. Un paso de reserva que solo funciona en orientación horizontal, o instrucciones que dependen de la forma o la posición («haz clic en el icono verde redondo de la derecha»). Esto supone un obstáculo para los usuarios con diferentes dispositivos y configuraciones de accesibilidad (WCAG 1.3.4, 1.3.3). Solución: admitir ambas orientaciones y describir los controles por su nombre, no solo por su color o posición.
- Límites de tiempo sin posibilidad de prórroga. Una sesión de reserva que caduca y vacía el carrito al cabo de unos minutos, sin previo aviso ni opción de prórroga, penaliza a cualquier persona que tarde más en escribir, leer o utilizar un dispositivo de selección (WCAG 2.2.1). Solución: advertir antes de que se agote el tiempo y ofrecer una prórroga con un solo clic, o eliminar el límite estricto.
- Elementos incrustados de terceros inaccesibles. El widget de chat, el carrusel de reseñas, el mapa, el banner de cookies. Un banner de cookies que atrapa el foco y bloquea la página hasta que se cierra con el ratón es un obstáculo total sorprendentemente común (WCAG 2.1.1, 2.4.3). Solución: elige componentes de terceros accesibles y pruébalos en su contexto, ya que sus fallos se convierten en los tuyos.
- Ausencia de declaración de accesibilidad y de vía de contacto. No se trata de un fallo de código, sino de carácter legal. La EAA exige que se publique una declaración y que exista una forma para que el usuario pueda informar de un problema de accesibilidad. Su ausencia es lo más fácil de detectar para un organismo regulador y lo más sencillo de solucionar para ti. Solución: publica la declaración (que se explica más adelante) y supervisa el canal de contacto.
El motor de reservas: donde la mayoría de los hoteles fallan en primer lugar
Si solo vas a reforzar un aspecto, refuerza el motor de reservas, ya que concentra el riesgo legal y los ingresos en un mismo punto. Es el encargado de la transacción que más le importa a la ley, es la parte más interactiva del sitio web y suele ser un widget de terceros sobre el que el hotel tiene menos control. Esa combinación es la razón por la que falla primero y de la peor manera.
Los problemas recurrentes en los widgets de reserva son predecibles. Seleccionadores de fechas personalizados creados en JavaScript que ignoran el teclado. Tarjetas de selección de habitaciones que son elementos `div` en los que se puede hacer clic en lugar de botones reales, invisibles para las tecnologías de apoyo. Flujos de varios pasos que llevan al usuario a un nuevo paso sin indicar al lector de pantalla que la página ha cambiado, por lo que el usuario no sabe que ha ocurrido nada. Campos de pago dentro de un iframe que no ha sido etiquetado. Un botón «Continuar» que solo se activa tras pasar el ratón por encima, algo que un usuario de teclado no puede hacer. Cada uno de estos problemas tiene solución, y ninguno de ellos forma parte de tu código si utilizas un motor alojado, que es precisamente por lo que la relación con el proveedor es importante.
Trata a los proveedores de tu motor de reservas y de tu gestor de canales como operadores económicos con sus propias obligaciones en materia de accesibilidad (EAA), y haz que lo demuestren. Solicita, por escrito, su documentación de conformidad con las WCAG 2.1 AA o la norma EN 301 549. Pregunta con qué versión de la norma realizaron las pruebas y cuándo. Pregunta si la prueba abarcó el widget integrado tal y como se muestra en el dominio de un cliente, y no solo en su sitio de demostración, ya que un widget puede superar la prueba de forma aislada y fallar una vez que el CSS de tu tema elimine el contorno de enfoque. Guarda las respuestas en tus archivos. Si un proveedor no puede o no quiere presentar pruebas de conformidad en 2026, eso constituye una señal de contratación que merece la pena tener en cuenta, y es cada vez más una razón que alegan los hoteles para cambiar de motor.
A continuación, pruébalo tú mismo, porque el contrato te protege legalmente, pero es el huésped quien experimenta el sitio web en vivo. Deja a un lado el ratón y reserva una habitación en tu propio dominio utilizando únicamente el teclado. Activa el lector de pantalla integrado en tu portátil (VoiceOver en un Mac, Narrador en Windows) e intenta hacer lo mismo con los ojos cerrados en el paso final. Aprenderás más en quince minutos haciendo eso que en una semana leyendo archivos PDF de los proveedores, y descubrirás los puntos exactos en los que un huésped real se rinde y acaba reservando a través de una OTA.
El sitio web y el recorrido del huésped más allá de la reserva
El motor de reservas es la parte más visible, pero la EAA abarca el servicio, y el servicio es todo el recorrido que realiza un consumidor para comprar y utilizar la habitación. Esto hace que el resto del sitio web entre en el ámbito de aplicación de formas que los hoteles subestiman.
Empieza por las páginas que conducen a la reserva, porque un huésped que no pueda leer las descripciones de las habitaciones o comparar tus tarifas nunca llegará al widget. Las páginas de habitaciones con galerías de fotos que carecen de texto alternativo, las tablas de tarifas que se basan únicamente en el color para señalar la opción más barata y los precios «desde 149 EUR» que aparecen dentro de una imagen son habituales, y cada uno de ellos supone un obstáculo para un tipo diferente de usuario. La navegación también es importante: un megamenú que solo se abre al pasar el cursor por encima, un menú móvil que atrapa el foco o un selector de idioma al que no se puede acceder con el teclado se sitúan en la ruta crítica hacia una venta. Nada de esto es un trabajo glamuroso, pero un sitio web bien construido trata estos aspectos con la misma rigurosidad que la que permite crear, en primer lugar, una página web de hotel rápida y con una alta tasa de conversión, ya que la accesibilidad y la conversión van de la mano.
A continuación, hay que mirar más allá de la venta. El área de cuenta o de gestión de reservas, donde un huésped cambia las fechas o cancela, forma parte del servicio de comercio electrónico. Lo mismo ocurre con cualquier portal dirigido a los huéspedes que se utilice para ventas adicionales, formularios previos a la llegada o el check-in digital. Si un huésped puede realizar la reserva de forma accesible, pero luego no puede modificarla o cancelarla sin visión o sin un ratón, lo que has hecho es trasladar el fallo en lugar de solucionarlo. Traza una vez el recorrido completo (búsqueda, página de habitaciones, reserva, confirmación, gestión de la reserva, antes de la llegada, registro de entrada, salida) y comprueba cada etapa, no solo el flujo principal.
Hay dos problemas menos evidentes que merecen una mención. Los vídeos sin subtítulos en el banner principal de la página de inicio o en el recorrido por el establecimiento suponen un obstáculo para los huéspedes sordos o con problemas de audición (WCAG 1.2.2), y la «reproducción automática con sonido» agrava aún más la situación. Además, cualquier contenido que se mueva, carruseles que giren según un temporizador o animaciones que no se puedan pausar distraen y, para algunos usuarios, suponen una verdadera dificultad (WCAG 2.2.2). La solución en ambos casos es la moderación: añadir subtítulos al vídeo y permitir que el usuario pause o detenga cualquier elemento que se mueva.
Archivos PDF, correos electrónicos de confirmación y los documentos que nadie comprueba
Los documentos que envía un hotel son el aspecto que más se pasa por alto, porque nadie considera que un correo electrónico o un PDF formen parte de un servicio digital regulado. Y sin embargo lo son, cuando forman parte de una transacción de comercio electrónico.
El correo electrónico de confirmación de la reserva es el ejemplo más evidente. Si está creado como una única imagen sin estructura (algo que, sorprendentemente, sigue siendo habitual en las herramientas de correo electrónico más antiguas), un lector de pantalla no lee nada útil y el huésped no dispone de un registro accesible de lo que ha reservado. La solución consiste en enviar un correo electrónico en HTML auténtico con una estructura lógica, contraste legible, texto descriptivo en los enlaces y una alternativa en texto sin formato. Lo mismo se aplica al mensaje previo a la llegada, al recibo de pago y al folio que se envía por correo electrónico al finalizar la estancia. Estos documentos proceden del PMS y de la capa de mensajería, por lo que la solución suele consistir en un cambio de plantilla, más que en un esfuerzo individual por huésped.
Los PDF son peores porque ocultan el contenido. Un PDF con los términos y condiciones, una factura, una propuesta de evento, un contrato de grupo o un menú descargable generado al exportar un documento diseñado suele ser un PDF sin etiquetas, lo que para un lector de pantalla equivale más o menos a lo que sería una foto de una página: visible, pero ilegible. Los PDF etiquetados con un orden de lectura adecuado, texto real en lugar de imágenes escaneadas y texto alternativo en las imágenes son el formato accesible. El enfoque pragmático para un hotel es pasar, en la medida de lo posible, a páginas HTML accesibles (una página con los términos y condiciones es mejor que un PDF con los mismos) y etiquetar los PDF que realmente sea imprescindible enviar. Si elaboras contratos o propuestas en grandes cantidades, incorpora la accesibilidad en la plantilla de una sola vez, en lugar de corregir cada documento a mano.
Una nota práctica sobre el alcance y la proporcionalidad: la directiva reconoce que corregir todo el archivo histórico de cada documento puede suponer una carga desproporcionada, y existen matices respecto al contenido creado antes de la fecha de aplicación. Eso no es una licencia para ignorar los documentos de tu flujo de transacciones actual. La confirmación que recibe un huésped esta semana es actual, entra dentro del ámbito de aplicación y es fácil de corregir a nivel de plantilla. Dedica tus esfuerzos a eso en primer lugar.
La declaración de accesibilidad que debe publicar
Este es el paso de cumplimiento más económico y el que con mayor frecuencia se omite. La EAA espera que un proveedor de servicios publique, en sus condiciones generales o en el sitio web, información sobre cómo el servicio cumple los requisitos de accesibilidad. En la práctica, eso significa una declaración de accesibilidad clara y fácil de encontrar, y elaborarla supone una tarde de trabajo, no un proyecto.
Una declaración útil debe incluir una breve lista de puntos: un compromiso claro con la accesibilidad y la norma a la que se ajusta (WCAG 2.1 nivel AA según la norma EN 301 549); el ámbito de aplicación (el sitio web, el motor de reservas, los correos electrónicos de los huéspedes); Las limitaciones conocidas sobre las que se es sincero, incluidos los componentes de terceros sobre los que no se tiene control total y las medidas que se están tomando al respecto. Una vía de contacto, ya sea un correo electrónico o un formulario, para que los huéspedes puedan informar de un problema de accesibilidad y solicitar información en un formato accesible. Y la fecha de la última revisión de la declaración, ya que una declaración con tres años de antigüedad da la impresión de estar abandonada. Si te acoges a la exención para microempresas, indícalo claramente y mantén las cifras que lo respaldan en tus archivos, en lugar de incluirlas en la declaración pública.
Dos advertencias. No copies íntegramente una plantilla de declaración de accesibilidad del sector público; estas están redactadas para un régimen jurídico diferente (la Directiva sobre accesibilidad web) y hacen referencia a mecanismos de notificación que no son aplicables a un hotel privado. Y no publiques una declaración en la que afirmes un cumplimiento total que no puedas demostrar, ya que una declaración exagerada es peor que una modesta y precisa: convierte una deficiencia de buena fe en una tergiversación en el momento en que un huésped detecte un fallo que tú afirmaste que no existía. Escribe lo que es cierto, comprométete a una fecha de revisión y mantén supervisado el canal de contacto.
Cómo funcionan la aplicación de la normativa y las multas, país por país
La EAA es una directiva, por lo que no impone multas directamente a nadie. Cada Estado miembro la ha transpuesto a su legislación nacional y ha establecido su propio organismo de control, procedimiento de reclamaciones y límite máximo de sanciones. Eso significa que el riesgo práctico depende en gran medida de dónde se encuentren tus huéspedes y dónde operes, y las cifras varían en un orden de magnitud. La tendencia durante el primer año ha sido similar en todos los mercados: las autoridades publican directrices, actúan ante las reclamaciones y realizan inspecciones aleatorias de vigilancia del mercado, y ordenan la subsanación de las irregularidades en un plazo determinado antes de recurrir a la sanción máxima. El desencadenante real para un hotel suele ser una reclamación de un huésped o de una organización de defensa de las personas con discapacidad, no un regulador que rastrea la web al azar.
Irlanda
Irlanda transpuso la EAA mediante normativas nacionales que designan a las autoridades de vigilancia del mercado y de ejecución, y establecen sanciones tanto administrativas como penales por el incumplimiento persistente. La aplicación de la normativa se distribuye entre distintos organismos en función del producto o servicio. Para un hotel de habla inglesa que vende en el mercado irlandés y en el de la UE en general, Irlanda es una jurisdicción relevante porque el idioma y el alcance convierten a los consumidores irlandeses en un público natural. La postura operativa es la misma que en otros lugares: una queja o una inspección aleatoria da lugar a una intervención y a una orden de subsanación, con sanciones cada vez más severas para los operadores que ignoren la orden. Ten a mano tu declaración, tus pruebas de conformidad y tu registro de medidas correctivas para poder presentarlos.
Alemania: la BFSG
La transposición alemana es la Barrierefreiheitsstärkungsgesetz (BFSG), que entró en vigor el 28 de junio de 2025. Se trata de uno de los regímenes más claramente especificados y uno de los más citados debido a su rigor. La BFSG prevé multas administrativas de hasta 100 000 euros y otorga a la autoridad de vigilancia del mercado la facultad de prohibir la oferta de un servicio que incumpla la normativa, lo que, en el caso de un hotel en línea, supone una orden que afecta directamente al canal que vende las habitaciones. Alemania también cuenta con una estructura de vigilancia específica en todos los estados federados. Para cualquier hotel con una demanda alemana significativa —y eso supone una gran parte de los establecimientos europeos situados en ciudades y en los Alpes—, la BFSG es el régimen que hay que tener en cuenta a la hora de planificar, ya que combina un límite máximo de multa real con la facultad de detener el servicio.
Francia: el RGAA y la multa para grandes empresas
Francia ha superpuesto la EAA a un régimen de accesibilidad ya existente. El RGAA (Référentiel général d'amélioration de l'accessibilité) es el marco de referencia francés que pone en práctica las WCAG, y Francia ya multaba a las grandes empresas por no publicar información sobre accesibilidad y no cumplir los requisitos, con sanciones administrativas que alcanzan los 50 000 euros por cada servicio no conforme y una multa recurrente si el incumplimiento no se corrige en el plazo establecido. La transposición de la EAA amplía el alcance de las obligaciones y el aparato de supervisión. Francia cuenta además con una cultura activa de reclamaciones por parte de los consumidores y de las organizaciones de defensa de los derechos, por lo que la probabilidad práctica de que se presente una reclamación es mayor de lo que sugiere la mera ley. Si vendes en Francia, ten en cuenta que el RGAA será el criterio que utilice un auditor.
España
España transpuso la EAA a la legislación nacional con sanciones administrativas clasificadas según su gravedad, siguiendo la estructura habitual en España de infracciones leves, graves y muy graves, cada una con su propio rango de multas. La supervisión de la accesibilidad para las personas con discapacidad recae en organismos consolidados, como la OADIS (Oficina de Atención a la Discapacidad), mientras que las autoridades sectoriales se encargan de la vigilancia del mercado. En el caso de un inmueble en España o de cualquier hotel con una fuerte demanda en el mercado español, la estructura de sanciones graduadas implica que el coste de un incumplimiento varía en función de su gravedad y persistencia, lo que recompensa la corrección voluntaria temprana y castiga a los operadores que, tras recibir una advertencia, no toman medidas.
Italia: la tradición de la Legge Stanca
Italia cuenta con la trayectoria legislativa más larga en materia de accesibilidad de este grupo. La «Legge Stanca» data de 2004, y la transposición italiana de la EAA (basada en el marco del D.Lgs. 82/2022 y los decretos relacionados) amplía las obligaciones del sector privado y las competencias de supervisión, con la AgID (la Agenzia per l’Italia Digitale) como elemento central de la estructura de supervisión. La legislación italiana de esta tradición permite sanciones que, en los casos más graves, alcanzan hasta el 5 % de la facturación, lo que supone la exposición proporcional más elevada de los cinco mercados aquí analizados. Para un hotel italiano, la combinación de una tradición jurídica consolidada y un límite máximo vinculado a la facturación hace que merezca especialmente la pena adoptar una postura documentada y defendible.
La lección válida para todos los mercados no consiste en memorizar cinco baremos de multas. Se trata de que el mismo objetivo de la norma EN 301 549 y las WCAG 2.1 AA cumple con todos ellos a la vez, por lo que la estrategia más eficaz es cumplir con la norma una sola vez, publicar una declaración veraz, conservar las pruebas y responder con prontitud a cualquier reclamación. Un establecimiento que haga estas cuatro cosas estará en una posición defendible en cada una de estas jurisdicciones, independientemente de cuál sea el huésped que se queje primero.
Cómo auditar tu propio sitio web en una tarde
No necesitas una agencia para detectar tus mayores problemas. Un gestor de sitios web sin conocimientos de programación puede sacar a la luz la mayoría de los fallos de alto riesgo en una sola tarde utilizando herramientas gratuitas y el equipo que ya tiene en su escritorio. Merece la pena contratar una auditoría especializada una vez que hayas hecho esto y quieras una evaluación completa y certificada, pero la autoauditoría te indica la gravedad de la situación y qué debes solucionar primero.
Realiza estas cinco comprobaciones en orden. La comprobación con el teclado: desconecta o ignora el ratón y completa una reserva completa utilizando las teclas Tab, Mayús+Tab, las teclas de flecha y Intro. Anota cada punto en el que te quedes atascado, no puedas ver en qué elemento está el foco o no puedas salir de un control. Esta comprobación por sí sola detecta los fallos de nivel A, que son los más importantes. La prueba con lector de pantalla: activa VoiceOver (Mac, Cmd-F5) o Narrador (Windows, Ctrl-Win-Intro), cierra los ojos durante los pasos clave e intenta comprender cada página y completar la reserva. Presta atención a los campos que se leen como «en blanco», a las imágenes que se leen como nombres de archivo y a los pasos que cambian sin previo aviso. La comprobación de contraste: pasa el texto principal, los botones y los bordes de los formularios por un verificador de contraste gratuito (el de WebAIM es el estándar) y marca todo lo que esté por debajo de 4,5 a 1 para el texto o de 3 a 1 para el texto grande y los componentes. La comprobación automatizada: ejecuta un escáner gratuito, como la extensión del navegador WAVE o axe DevTools, en tu página de inicio, en una página de habitaciones y en cada paso de la reserva; estos detectan rápidamente etiquetas que faltan, texto alternativo y problemas con los encabezados, aunque solo encuentran quizás un tercio de los problemas, por lo que las comprobaciones manuales son lo primero. La comprobación de zoom: ajusta el zoom del navegador al 200 % y reajusta la página a una ventana estrecha; el contenido que desaparece, se superpone o obliga a desplazarse horizontalmente no cumple los criterios de reajuste y redimensionamiento.
Anota lo que se detecta en cada revisión en una lista compartida, etiquetado según su ubicación (motor de reservas, páginas de habitaciones, navegación, correos electrónicos, documentos) y según su gravedad (bloquea una reserva, deteriora una reserva, problema estético). Esa lista es la base del plan de corrección. La mayoría de los establecimientos independientes terminan la tarde con entre quince y cuarenta hallazgos y la clara sensación de que tres o cuatro de ellos son los que realmente están costando reservas.
El manual de limpieza de accesibilidad en 30 días
Un plan de 30 días para llevar un sitio web independiente típico de «nunca lo hemos probado» a «defendible y en mejora». Una persona con mentalidad operativa puede llevarlo a cabo, recurriendo al desarrollador web o al proveedor del motor de reservas para el trabajo de implementación. Se necesitan unas pocas horas a la semana por parte del responsable y un bloque de tiempo concentrado por parte de quien se encargue del mantenimiento del sitio.
Días 1 a 4: auditoría y clasificación. Realiza la autoauditoría de cinco pasos descrita anteriormente en el sitio web activo, tanto en versión de escritorio como móvil. Recopila todos los hallazgos en una sola lista, etiquétalos según la superficie y la gravedad, e identifica los tres o cuatro fallos que bloquean o dificultan gravemente una reserva. Esas son las prioridades; resiste la tentación de empezar por los aspectos cosméticos de menor importancia.
Días 5 a 7: localizar a los proveedores. Envía un correo electrónico a los proveedores del motor de reservas y del gestor de canales y solicita, por escrito, su documentación de conformidad con las WCAG 2.1 AA o la norma EN 301 549, la versión probada y la fecha. Pregunta cómo gestionan el widget integrado en el dominio de un cliente. Archiva las respuestas. Cuando un proveedor no pueda responder, anótalo como un riesgo y una posible decisión de contratación, en lugar de como una corrección que puedas realizar tú mismo.
Días 8 a 16: corrige el flujo de reserva. Esta es la parte más laboriosa. Haz que todo el proceso de reserva sea manejable mediante el teclado, restaura un indicador de foco visible, asigna una etiqueta real a cada campo del formulario, corrige los mensajes de error para que indiquen el campo y el problema, y ajusta el contraste del botón principal y del texto del cuerpo para que cumplan los requisitos. Vuelve a ejecutar las pruebas con el teclado y el lector de pantalla tras cada cambio hasta que se pueda completar una reserva íntegra sin ratón y con el lector de pantalla activado.
Días 17 a 22: corrige las páginas circundantes. Añade texto alternativo a las imágenes significativas y deja el campo «alt» vacío en las decorativas; corrige la estructura de los encabezados; adapta la navegación y el selector de idioma para su uso con el teclado; añade subtítulos al vídeo de presentación o de visita guiada; y asegúrate de que cualquier contenido en movimiento se pueda pausar. Comprueba que el sitio se reajusta correctamente con un zoom del 200 %.
Días 23 a 26: corrige los documentos y los correos electrónicos. Convierte los correos de confirmación, previos a la llegada, de recibo y de factura en HTML estructurado con un contraste legible y una alternativa en texto sin formato. Traslada los documentos que puedas a páginas HTML accesibles y etiqueta los PDF que debas conservar. Prueba uno de cada tipo con el lector de pantalla.
Días 27 a 28: publica la declaración. Redacta y publica una declaración de accesibilidad sincera que abarque la norma de referencia, el alcance, las limitaciones conocidas, una vía de contacto para resolver problemas y una fecha de revisión. Configura el canal de contacto para que llegue a una bandeja de entrada real que alguien supervise.
Días 29 a 30: documenta y planifica. Reúne el dossier de pruebas: los resultados de la auditoría y las correcciones realizadas, los documentos de conformidad de los proveedores, la declaración publicada y, si te acoges a la exención para microempresas, las cifras de plantilla y volumen de negocio que lo justifiquen. Anota en el calendario una nueva prueba trimestral periódica, ya que los sitios web sufren retrocesos cada vez que se actualiza el tema o el motor de reservas. Informa a quien edite el sitio de que las nuevas imágenes necesitan texto alternativo y que los nuevos componentes deben someterse a una comprobación de accesibilidad con el teclado, para que esta disciplina se mantenga una vez finalizado el proyecto.
Esfuerzo total durante los 30 días: entre 25 y 40 horas aproximadamente para el responsable y un bloque de tiempo dedicado por parte del desarrollador o el proveedor, concentrado principalmente en la semana dedicada al flujo de reservas. Los establecimientos que llevan a cabo este proceso de forma rigurosa eliminan los fallos que impiden el acceso a los huéspedes reales, adoptan una postura defendible y, por lo general, observan un pequeño aumento en la finalización de las reservas directas como efecto secundario, ya que las mismas correcciones que ayudan a un usuario de lector de pantalla también ayudan a un huésped cansado que utiliza el teléfono en condiciones de poca luz.
Dónde encaja Prostay, de forma breve y sincera
Escribo para Prostay, así que esta sección es inevitable; voy a ser claro al respecto. Prostay ofrece el motor de reservas, las plantillas de la página web y el sistema de mensajería para huéspedes con la accesibilidad integrada en los componentes, en lugar de añadida a posteriori, lo que significa que el proceso de reserva está diseñado para funcionar con el teclado, los campos de los formularios llevan etiquetas reales, se conserva el indicador de foco y la paleta de colores predeterminada de la marca está ajustada para cumplir con los requisitos de contraste. Los correos electrónicos de confirmación, previos a la llegada y de resumen de la estancia que envía el sistema de gestión de alojamientos utilizan plantillas estructuradas y compatibles con lectores de pantalla, en lugar de imágenes planas. Nada de esto es exclusivo de Prostay; Mews, Cloudbeds y otros proveedores han realizado un importante trabajo de accesibilidad en sus propias plataformas, y cualquiera de ellos puede ofrecerte una base que cumpla con las normas.
El argumento a favor de Prostay en concreto es que el motor de reservas, el sitio web, el PMS y los mensajes provienen de un mismo equipo que los prueba conjuntamente según las WCAG 2.1 AA en los cinco idiomas del sitio, por lo que no estás integrando un widget accesible en un tema inaccesible y esperando que las uniones aguanten. También podemos facilitarte la documentación de conformidad del proveedor que necesitas para tu dossier de pruebas, lo que elimina uno de los pasos más lentos del plan de 30 días. Si quieres conocer los detalles de la interfaz de cara al huésped, la descripción general del motor de reservas de Prostay te lo explica paso a paso; y si prefieres que nuestro equipo realice la autoauditoría y la limpieza en tu sitio web activo, reserva una demostración y analizaremos tu flujo de reservas real, en lugar de venderte un contrato de accesibilidad por separado.
Preguntas frecuentes
Las cinco preguntas que los hoteleros independientes plantean con más frecuencia sobre la Ley de Accesibilidad Europea, respondidas en base a la directiva y la norma armonizada, en lugar de al resumen de la prensa especializada.
