L'accessibilità dei siti web degli hotel e la legge europea sull'accessibilità del 2026

La legge che ha trasformato il tuo motore di prenotazione in un software soggetto a regolamentazione

Il 28 giugno 2025 un software che probabilmente non hai scritto tu è diventato soggetto alla normativa UE: il tuo motore di prenotazione. L’Atto europeo sull’accessibilità, formalmente la Direttiva (UE) 2019/882, è entrato in vigore quel giorno, e una delle categorie di servizi che copre è l’e-commerce. La vendita di una camera a un consumatore tramite un sito web o un’app è commercio elettronico. Ciò significa che il widget in cui un ospite seleziona le date, sceglie una camera, inserisce i dati della carta di credito e clicca su “Paga ora” deve funzionare per chi naviga con la tastiera, utilizza uno screen reader o necessita di caratteri più grandi e di un contrasto maggiore per leggere il prezzo. La maggior parte degli hotel indipendenti non ha mai effettuato test in tal senso. Il flusso di prenotazione che genera i ricavi diretti, la parte del sistema di cui la maggior parte degli operatori va più fiera, è anche quella che rischia maggiormente di fallire al primo passaggio con la tastiera. Un moderno motore di prenotazione alberghiera deve superare questa soglia ora, non come un optional, ma come requisito legale per vendere online ai residenti dell’UE.

La legge non si limita al widget di prenotazione. Riguarda l’intero servizio digitale legato alla vendita: le pagine del sito web che portano alla prenotazione, l’e-mail di conferma, l’area account in cui l’ospite gestisce la prenotazione, l’app mobile se ne avete una e i documenti che inviate dopo il soggiorno. Il percorso dell’ospite orchestrato dal vostro sistema di gestione della struttura, dalla conferma della prenotazione al messaggio pre-arrivo fino al conto che inviate via e-mail al momento del check-out, rientra ora nell’ambito del servizio di e-commerce. Questo articolo offre un quadro realistico della situazione nel 2026 per un operatore indipendente: cosa richiede l’EAA, chi rientra effettivamente nell’ambito di applicazione una volta applicata correttamente l’esenzione per le microimprese, lo standard tecnico alla base della legge, gli undici casi di non conformità che comportano il fallimento di un audit, come funzionano l’applicazione della normativa e le sanzioni nei cinque mercati principali, e un piano di 30 giorni che un gestore può attuare senza ricorrere a un’agenzia specializzata.

Scrivo per Prostay, e il nostro team fornisce il motore di prenotazione, i modelli di sito web e il sistema di messaggistica per gli ospiti su cui si basano molti di questi flussi; per questo abbiamo dedicato due anni a garantire che questa piattaforma superi le verifiche di accessibilità in cinque lingue e una dozzina di trasposizioni nazionali. Le scadenze, le soglie e le modalità di non conformità riportate di seguito derivano dalla direttiva e dagli standard pubblicati, dal nostro lavoro di adeguamento sui siti dei clienti già attivi e dalla prima ondata di reclami e linee guida emesse dagli organismi nazionali di controllo nel corso del 2025 e fino al 2026. Non c’è più alcun periodo di tolleranza da attendere. La data di applicazione è già trascorsa. L’unica domanda che vale la pena porsi è se il vostro sito sia oggi difendibile, e per la maggior parte dei siti indipendenti la risposta onesta è: non ancora.

Cosa richiede effettivamente l’Atto europeo sull’accessibilità

L’EAA è una direttiva sul mercato unico. Il suo scopo è impedire che ventisette paesi elaborino ventisette norme di accessibilità incompatibili tra loro, stabilendo un unico standard di riferimento per un elenco definito di prodotti e servizi venduti in tutta l’UE. L’elenco dei prodotti comprende computer, smartphone, terminali di pagamento, biglietterie automatiche ed e-reader. L’elenco dei servizi è la parte che riguarda gli hotel: copre i servizi bancari al consumo, le comunicazioni elettroniche, l’accesso ai media audiovisivi, alcuni aspetti del trasporto passeggeri e il commercio elettronico. La direttiva definisce il commercio elettronico come la vendita di prodotti o servizi a un consumatore tramite un sito web o un’applicazione mobile. Un hotel che vende camere direttamente online a un membro del pubblico rientra pienamente in tale definizione.

Ciò che la direttiva richiede, in parole povere, è che il servizio sia percepibile, utilizzabile, comprensibile e robusto per le persone con disabilità. Il testo giuridico non riporta una lista di controllo. Stabilisce invece risultati funzionali (le informazioni devono essere disponibili attraverso più di un canale sensoriale, i contenuti devono essere navigabili senza mouse, il testo deve essere ridimensionabile e leggibile, i limiti di tempo devono essere regolabili) e rimanda a uno standard tecnico armonizzato per i dettagli verificabili. Per il web, tali dettagli sono definiti dalle WCAG, che approfondirò in una sezione successiva. In pratica, per un operatore ciò significa che la prenotazione e tutte le operazioni correlate devono poter essere completate da un ospite che non possa vedere lo schermo, non possa utilizzare un mouse, non possa udire i messaggi audio o non possa leggere testi scritti in caratteri piccoli e a basso contrasto.

Accanto a quello tecnico vi sono tre obblighi facili da dimenticare. In primo luogo, è necessario pubblicare una dichiarazione di accessibilità che spieghi in che modo il servizio soddisfa i requisiti e fornisca un canale di contatto in caso di problemi. In secondo luogo, è necessario conservare le prove di conformità, poiché se un’autorità di regolamentazione o un ospite contesta la vostra posizione, l’onere di dimostrare che il servizio è accessibile (o che si ha diritto a un’esenzione) ricade su di voi. In terzo luogo, se si sostiene che una specifica modifica comporterebbe un onere sproporzionato, è necessario documentare tale valutazione in anticipo; non è possibile inventare una scusa dopo che è pervenuto un reclamo. Nessuna di queste tre misure è tecnicamente difficile da attuare. Tuttavia, tutte e tre vengono sistematicamente trascurate.

Chi rientra nell’ambito di applicazione e l’esenzione per le microimprese che tutti interpretano erroneamente

La frase più ricorrente nei resoconti del settore alberghiero sull’EAA è «i piccoli hotel sono esenti». È vera solo a metà, e proprio quella metà errata mette le strutture in difficoltà. La direttiva esclude le microimprese che forniscono servizi, e una microimpresa è definita come un’impresa con meno di 10 dipendenti e un fatturato annuo o un totale di bilancio non superiore a 2 milioni di euro. Se il vostro hotel è un’entità giuridica autonoma che rientra in entrambi questi limiti, i vostri obblighi in qualità di fornitori di servizi vengono meno. Si tratta di un’esenzione reale e utile per una struttura davvero piccola.

È qui che gli operatori fraintendono la normativa. La soglia viene calcolata a livello dell’entità giuridica che fornisce il servizio, e gli hotel sono strutturati in modi che li fanno superare silenziosamente tale limite. Una struttura con otto addetti al front office, ma con una società di gestione, una società proprietaria e un team centrale condiviso per le prenotazioni, può facilmente superare i dieci dipendenti una volta conteggiato il numero effettivo di addetti. Un hotel boutique con un modesto fatturato derivante dalle camere può comunque superare i 2 milioni di euro una volta aggiunti al fatturato i ricavi derivanti da ristorazione, eventi e spa. Un singolo hotel all’interno di un piccolo gruppo raramente è una microimpresa, anche se ogni singola struttura sembra piccola. L’esenzione è a livello di entità, non a livello di percezione, e l’onere di dimostrare di esserne idonei ricade su di voi. Se intendete avvalervene, annotate il numero di dipendenti e il fatturato o il dato di bilancio relativi all’entità in questione e all’esercizio finanziario, e conservate tale nota insieme agli altri documenti di conformità.

Altre due avvertenze. L’agevolazione per le microimprese si applica agli obblighi relativi ai servizi; non esenta i prodotti che vendete né i fornitori da cui acquistate. Il vostro fornitore del motore di prenotazione, il vostro channel manager e le OTA che rivendono le vostre camere sono quasi tutti ben al di sopra della soglia e devono fornire software accessibile indipendentemente dalle vostre dimensioni; ciò significa che gli strumenti stanno migliorando a vostro vantaggio, indipendentemente dal fatto che rientriate o meno personalmente nell’ambito di applicazione. Inoltre, l’esenzione è un obiettivo in continua evoluzione: il giorno in cui assumerete l’undicesimo dipendente o supererete i 2 milioni di euro, il conto alla rovescia avrà inizio e non potrete più fare affidamento su un periodo di transizione pluriennale, poiché le finestre di transizione previste dalla direttiva si sono già chiuse. Considerare l’accessibilità come una caratteristica permanente della struttura del sito è più economico che trattarla come una soglia da aggirare finché non sarà più possibile.

C’è un altro gruppo che rientra decisamente nell’ambito di applicazione e che spesso viene dimenticato: chiunque non sia una microimpresa. Un hotel da 60 camere con un ristorante, una struttura urbana da 120 camere, un gruppo con quattro proprietà, un operatore di appartamenti serviti con una presenza a livello regionale. Si tratta di operatori indipendenti ordinari secondo gli standard del settore alberghiero e sono chiaramente soggetti a regolamentazione. Se questa descrizione vi riguarda, la discussione sull’esenzione è irrilevante e l’unica domanda utile è: in quanto tempo potete rendere il sito conforme?

Lo standard alla base della legge: EN 301 549 e WCAG 2.1 AA

La direttiva stabilisce i risultati; la norma definisce i criteri di verifica. La norma EN 301 549 è la norma europea armonizzata per l’accessibilità dei prodotti e dei servizi ICT, ed è il documento a cui fa riferimento un’autorità di regolamentazione o un revisore quando vuole verificare se il vostro sito sia effettivamente conforme. Il rispetto delle parti pertinenti della norma EN 301 549 conferisce una presunzione di conformità all’EAA, il che in parole povere significa: se si supera la norma, si presume che la legge sia stata rispettata, a meno che qualcuno non dimostri il contrario.

Per quanto riguarda i contenuti web, la norma EN 301 549 non introduce regole proprie, ma adotta le WCAG (Linee guida per l’accessibilità dei contenuti web) pubblicate dal W3C, al livello di conformità AA. Le WCAG 2.1 AA rappresentano l’obiettivo operativo per il 2025 e il 2026; le WCAG 2.2 aggiungono una serie di criteri supplementari e rappresentano la direzione verso cui si sta orientando lo standard, pertanto sviluppare in base alle 2.2 è la scelta lungimirante, ma le 2.1 AA costituiscono il livello minimo attualmente previsto dalla legge. Si tratta dello stesso obiettivo che i siti web del settore pubblico dell’UE devono soddisfare sin dall’entrata in vigore della Direttiva sull’accessibilità del web del 2016; pertanto, lo standard è consolidato, gli strumenti a disposizione sono validi e il vostro sviluppatore non ha alcuna scusa per considerarlo una novità esotica.

Le WCAG organizzano i propri criteri di successo secondo quattro principi che vale la pena conoscere per nome, poiché rispecchiano chiaramente i punti in cui gli hotel falliscono. Percepibile: l’ospite è in grado di cogliere le informazioni? Si tratta di alternative testuali per le immagini, didascalie e contrasto cromatico. Operabile: l’ospite è in grado di interagire con l’interfaccia? Si tratta di accessibilità tramite tastiera, tempo sufficiente per compilare un modulo e assenza di contenuti che lampeggiano in modo tale da provocare crisi epilettiche. Comprensibile: il contenuto e il comportamento sono prevedibili? Si tratta di etichette chiare, linguaggio leggibile e messaggi di errore utili. Robustezza: funzionerà con le tecnologie assistive ora e in futuro? Si tratta di un markup pulito e basato su standard che uno screen reader possa analizzare. Quasi ogni errore degli hotel che descriverò di seguito è una violazione specifica e verificabile di uno di questi quattro principi, e le soluzioni sono di conseguenza concrete.

Le istruzioni pratiche per un gestore che non scrive codice sono brevi. Comunicate a chi sviluppa e gestisce il vostro sito che l’obiettivo è il livello AA delle WCAG 2.1, chiedete loro di confermare per iscritto che il sito e il flusso di prenotazione lo rispettino, e richiedete il rapporto di audit o di test a sostegno di tale affermazione. Se non sono in grado di fornirlo, avete individuato la vostra prima lacuna. Se invece lo possono fornire, conservatelo insieme alla vostra dichiarazione di accessibilità e alla nota sulla microimpresa, poiché insieme questi documenti costituiranno la vostra difesa nel caso in cui dovesse pervenire un reclamo.

Undici errori di accessibilità che non superano l’audit

Tra i siti di hotel che il nostro team ha risanato e i modelli di reclamo pubblicati dagli enti nazionali nel primo anno, le stesse undici carenze rappresentano la maggior parte del rischio. Sono elencate approssimativamente in ordine di frequenza di comparsa e di gravità con cui ostacolano un ospite reale, ciascuna con la soluzione e il criterio WCAG a cui si riferisce.

1. Impossibilità di completare la prenotazione con la tastiera. La singola non conformità più grave. Un selettore di date che risponde solo al clic del mouse, una scheda camera che non è possibile selezionare con il tasto Invio, un calendario che si può aprire ma dal quale non è possibile uscire (una «trappola da tastiera»). Se un ospite non può selezionare le date, scegliere una camera e raggiungere il pulsante di pagamento utilizzando solo i tasti Tab, freccia e Invio, la prenotazione è impossibile per gli utenti che utilizzano la tastiera e gli screen reader. Si tratta di un errore di livello A delle WCAG (2.1.1 Tastiera, 2.1.2 Assenza di trappole da tastiera) e un solo caso di non conformità fa fallire l’intera valutazione. Soluzione: utilizzare controlli HTML nativi ove possibile e garantire che i gestori da tastiera su qualsiasi widget personalizzato siano testati.
2. Contrasto cromatico al di sotto della soglia. Il grigio chiaro su sfondo bianco tanto amato dai designer. Il testo normale richiede un rapporto di contrasto di almeno 4,5 a 1 rispetto allo sfondo; il testo di grandi dimensioni e i componenti interattivi come pulsanti e bordi dei moduli richiedono almeno 3 a 1 (WCAG 1.4.3 e 1.4.11). L’errore più comune è il pulsante principale «Prenota ora», realizzato in un colore tenue del marchio che registra un rapporto di 2,8 a 1. Soluzione: scurire il pulsante o il testo fino a superare il controllo del contrasto e integrare i valori corretti nella tavolozza del marchio per evitare recessi.
3. Campi del modulo privi di etichetta programmatica. Un campo che mostra “Ospiti” come testo segnaposto grigio ma non ha un’etichetta vera e propria risulta vuoto per uno screen reader; l’utente sente “modifica testo, vuoto”. I segnaposto non sono etichette (WCAG 1.3.1, 4.1.2). Soluzione: un elemento di etichetta corretto associato a ciascun campo di immissione, visibile, non solo un segnaposto che scompare quando si mette a fuoco il campo.
4. Immagini che veicolano significato senza testo alternativo. Una foto di una camera, una mappa, una planimetria o un banner promozionale con un prezzo integrato nell’immagine e senza testo alternativo. L’utente dello screen reader non riceve alcuna informazione (WCAG 1.1.1). Soluzione: testo alternativo descrittivo per le immagini significative, testo alternativo vuoto per quelle puramente decorative, e non inserire mai un prezzo o una scadenza solo all’interno di un’immagine.
5. Messaggi di errore che non specificano cosa non va o dove. Un bordo rosso e la scritta «Errore, riprova» senza alcuna indicazione su quale campo abbia generato l’errore o perché. Un visitatore che non vede il bordo rosso non sa come procedere (WCAG 3.3.1, 3.3.3). Soluzione: un testo di errore che indichi il campo e il problema (“La data di check-out deve essere successiva alla data di check-in”), collegato al campo in modo che la tecnologia assistiva lo annunci.
6. Intestazioni utilizzate per motivi estetici, non strutturali. Gli utenti di lettori di schermo navigano tramite le intestazioni proprio come gli utenti vedenti sfogliano il testo. Una pagina che applica uno stile al testo per farlo sembrare un'intestazione senza utilizzare un vero elemento di intestazione, o che salta da H1 a H4, è difficile da navigare (WCAG 1.3.1). Soluzione: una struttura logica delle intestazioni, un solo H1 per pagina, senza livelli saltati per motivi estetici.
7. Focus non visibile. Quando si naviga nella pagina con il tasto Tab, l’elemento selezionato deve mostrare un contorno visibile. Molti temi rimuovono l’anello di focus per motivi estetici, lasciando disorientati gli utenti che utilizzano la tastiera (WCAG 2.4.7). Soluzione: un indicatore di focus chiaro e ad alto contrasto su ogni elemento interattivo, e smettere di eliminare il contorno predefinito senza sostituirlo.
8. Contenuti che funzionano solo in un unico orientamento o con un unico modo di interagire. Una fase di prenotazione che funziona solo in orientamento orizzontale, oppure istruzioni che si basano sulla forma o sulla posizione (“fai clic sull’icona verde rotonda a destra”). Ciò crea difficoltà agli utenti che utilizzano dispositivi diversi e configurazioni assistive (WCAG 1.3.4, 1.3.3). Soluzione: supportare entrambi gli orientamenti e descrivere i controlli per nome, non solo per colore o posizione.
9. Limiti di tempo senza possibilità di proroga. Una sessione di prenotazione che scade e svuota il carrello dopo pochi minuti, senza alcun avviso né opzione di proroga, penalizza chiunque impieghi più tempo a digitare, leggere o utilizzare un dispositivo a interruttori (WCAG 2.2.1). Soluzione: avvisare prima del timeout e offrire una proroga con un solo clic, oppure rimuovere il limite rigido.
10. Elementi incorporati di terze parti inaccessibili. Il widget della chat, il carosello delle recensioni, la mappa, il banner dei cookie. Un banner dei cookie che intrappola il focus e blocca la pagina finché non viene chiuso con il mouse è un ostacolo totale sorprendentemente comune (WCAG 2.1.1, 2.4.3). Soluzione: scegliere componenti di terze parti accessibili e testarli sul posto, poiché i loro malfunzionamenti diventano i vostri.
11. Mancanza di una dichiarazione di accessibilità e di un canale di contatto. Non si tratta di un errore di codice, ma di natura legale. L’EAA richiede la pubblicazione di una dichiarazione e la disponibilità di un canale attraverso cui l’utente possa segnalare un problema di accessibilità. La sua assenza è la cosa più facile da individuare per un’autorità di regolamentazione e la più semplice da correggere per voi. Soluzione: pubblicate la dichiarazione (di cui si parla più avanti) e monitorate il canale di contatto.

Il motore di prenotazione: il primo punto in cui la maggior parte degli hotel fallisce

Se dovete rafforzare un solo aspetto, rafforzate il motore di prenotazione, perché concentra il rischio legale e il fatturato nello stesso punto. Gestisce la transazione a cui la legge attribuisce maggiore importanza, è la parte più interattiva del sito ed è solitamente un widget di terze parti su cui l’hotel ha il minor controllo. È proprio questa combinazione il motivo per cui fallisce per primo e in modo più grave.

I problemi ricorrenti nei widget di prenotazione sono prevedibili. Selettori di date personalizzati realizzati in JavaScript che ignorano la tastiera. Schede di selezione delle camere che sono elementi `div` cliccabili anziché veri e propri pulsanti, invisibili alle tecnologie assistive. Flussi in più fasi che spostano l’utente a un nuovo passaggio senza comunicare allo screen reader che la pagina è cambiata, così l’utente non si accorge che sia successo qualcosa. Campi di pagamento all’interno di un iframe che non è stato etichettato. Un pulsante “continua” che si attiva solo dopo il passaggio del mouse, un evento che un utente che utilizza la tastiera non può attivare. Ognuno di questi problemi è risolvibile, e nessuno di essi riguarda il vostro codice se utilizzate un motore ospitato, ed è proprio per questo che il rapporto con il fornitore è fondamentale.

Considerate i fornitori del vostro motore di prenotazione e del channel manager come operatori economici con i propri obblighi in materia di accessibilità (EAA) e fate in modo che lo dimostrino. Richiedete, per iscritto, la loro documentazione di conformità alle WCAG 2.1 AA o alla norma EN 301 549. Chiedete in base a quale versione dello standard abbiano effettuato i test e quando. Chiedete se il test abbia coperto il widget incorporato così come viene visualizzato su un dominio del cliente, non solo sul loro sito demo, poiché un widget può superare il test in isolamento e fallirlo una volta che il CSS del vostro tema rimuove il contorno di focus. Conservate le risposte in archivio. Se un fornitore non è in grado o non intende fornire prove di conformità nel 2026, questo costituisce un segnale di approvvigionamento su cui vale la pena agire, ed è sempre più spesso un motivo addotto dagli hotel per cambiare motore.

Quindi testatelo voi stessi, perché il contratto vi tutela legalmente ma è l’ospite a sperimentare il sito dal vivo. Mettete via il mouse e prenotate una camera sul vostro dominio utilizzando solo la tastiera. Attivate lo screen reader integrato nel vostro laptop (VoiceOver su Mac, Narrator su Windows) e provate la stessa operazione ad occhi chiusi per il passaggio finale. In quindici minuti imparerete più di quanto potreste apprendere in una settimana leggendo i PDF dei fornitori, e individuerete i punti esatti in cui un ospite reale si arrende e prenota invece su un’OTA.

Il sito web e il percorso dell’ospite oltre la prenotazione

Il motore di prenotazione è il punto cruciale, ma l’EAA copre il servizio, e il servizio è l’intero percorso che un consumatore compie per acquistare e utilizzare la camera. Questo fa rientrare nel campo di applicazione il resto del sito in modi che gli hotel sottovalutano.

Inizia dalle pagine che portano alla prenotazione, perché un ospite che non riesce a leggere le descrizioni delle camere o a confrontare le tariffe non arriva mai al widget. Pagine delle camere con gallerie fotografiche prive di testo alternativo, tabelle tariffarie che si affidano esclusivamente al colore per evidenziare l’opzione più economica e prezzi “a partire da 149 EUR” visualizzati all’interno di un’immagine sono comuni e ognuno di questi elementi ostacola un utente diverso. Anche la navigazione è importante: un mega-menu che si apre solo al passaggio del mouse, un menu mobile che intrappola il focus o un selettore di lingua non raggiungibile tramite tastiera si trovano tutti sul percorso critico verso una vendita. Nessuna di queste attività è affascinante, ma un sito ben costruito le considera parte della stessa disciplina che produce, in primo luogo, un sito web alberghiero veloce e ad alta conversione, perché accessibilità e conversione vanno nella stessa direzione.

Poi guarda oltre la vendita. L’area account o di gestione delle prenotazioni, dove un ospite modifica le date o annulla, fa parte del servizio di e-commerce. Lo stesso vale per qualsiasi portale rivolto agli ospiti che utilizzi per up-selling, moduli pre-arrivo o check-in digitale. Se un ospite può effettuare una prenotazione in modo accessibile ma poi non può modificare o cancellare la prenotazione senza l’uso della vista o di un mouse, avete semplicemente spostato il problema invece di risolverlo. Mappate l’intero percorso una volta (ricerca, pagina della camera, prenotazione, conferma, gestione della prenotazione, pre-arrivo, check-in, check-out) e controllate ogni fase, non solo il flusso principale.

Due problemi meno evidenti meritano una menzione. I video senza sottotitoli nella sezione principale della homepage o nei tour della struttura non sono accessibili agli ospiti non udenti o ipoudenti (WCAG 1.2.2), e la “riproduzione automatica con audio” aggrava la situazione. Inoltre, qualsiasi contenuto in movimento, caroselli che ruotano a intervalli prestabiliti o animazioni che non possono essere messe in pausa distraggono e, per alcuni utenti, causano vere e proprie difficoltà (WCAG 2.2.2). La soluzione in entrambi i casi è la moderazione: aggiungete i sottotitoli al video e consentite all’utente di mettere in pausa o interrompere qualsiasi elemento in movimento.

PDF, e-mail di conferma e i documenti che nessuno verifica

I documenti inviati da un hotel sono l’aspetto più trascurato, perché nessuno considera un’e-mail o un PDF come parte di un servizio digitale regolamentato. Eppure lo sono, quando fanno parte di una transazione di e-commerce.

L’e-mail di conferma della prenotazione è l’esempio più evidente. Se è realizzata come un’unica immagine appiattita (cosa ancora sorprendentemente comune con i vecchi strumenti di posta elettronica), uno screen reader non legge nulla di utile e l’ospite non ha alcuna traccia accessibile di ciò che ha prenotato. La soluzione consiste nell’inviare una vera e-mail in HTML con una struttura logica, un contrasto leggibile, testo descrittivo nei link e un’alternativa in testo semplice. Lo stesso vale per il messaggio pre-arrivo, la ricevuta di pagamento e il conto che inviate via e-mail al momento del check-out. Questi documenti provengono dal PMS e dal sistema di messaggistica, quindi la soluzione consiste solitamente in una modifica del modello piuttosto che in un intervento specifico per ogni ospite.

I PDF sono ancora peggio perché nascondono il contenuto. Un PDF con i termini e le condizioni, una fattura, una proposta per un evento, un contratto di gruppo o un menu scaricabile generato esportando un documento impaginato è in genere un PDF senza tag, che per uno screen reader è più o meno come lo sarebbe la foto di una pagina: visibile, ma illeggibile. I PDF con tag, dotati di un ordine di lettura corretto, testo vero e proprio anziché immagini scansionate e testo alternativo per le immagini, rappresentano il formato accessibile. L’approccio pragmatico per un hotel è quello di passare il più possibile a pagine HTML accessibili (una pagina con i termini e le condizioni è preferibile a un PDF con gli stessi termini) e di taggare i PDF che è davvero necessario inviare. Se si producono contratti o proposte in grandi quantità, è meglio integrare l’accessibilità nel modello una volta sola, piuttosto che correggere ogni documento manualmente.

Una nota pratica su ambito e proporzionalità: la direttiva riconosce che correggere l’intero archivio storico di ogni documento può rappresentare un onere sproporzionato, e ci sono sfumature riguardo ai contenuti creati prima della data di applicazione. Ciò non costituisce un’autorizzazione a ignorare i documenti nel flusso delle transazioni attuali. La conferma che un ospite riceve questa settimana è attuale, rientra nell’ambito di applicazione ed è facile da correggere a livello di modello. Concentrate i vostri sforzi innanzitutto su questo.

La dichiarazione di accessibilità che siete tenuti a pubblicare

Questo è il passo di conformità più economico e quello che più spesso viene tralasciato. L’EAA si aspetta che un fornitore di servizi pubblichi, nelle sue condizioni generali o sul sito, informazioni su come il servizio soddisfi i requisiti di accessibilità. In pratica ciò significa una dichiarazione di accessibilità chiara e facilmente reperibile, e redigerne una richiede un pomeriggio di lavoro, non un progetto.

Una dichiarazione utile copre un breve elenco di punti. Un semplice impegno a favore dell’accessibilità e lo standard a cui mirate (WCAG 2.1 livello AA tramite EN 301 549). L’ambito di applicazione (il sito web, il motore di prenotazione, le e-mail agli ospiti). Le limitazioni note di cui si parla con onestà, compresi eventuali componenti di terze parti che non si controllano pienamente e le misure adottate al riguardo. Un canale di contatto, un’e-mail o un modulo, affinché un ospite possa segnalare un problema di accessibilità e richiedere informazioni in un formato accessibile. E la data dell’ultima revisione della dichiarazione, poiché una dichiarazione risalente a tre anni fa viene percepita come abbandonata. Se vi avvalete dell’esenzione per le microimprese, dichiaratelo chiaramente e conservate i dati a sostegno in archivio piuttosto che nella dichiarazione pubblica.

Due avvertimenti. Non copiate integralmente un modello di dichiarazione di accessibilità del settore pubblico; tali modelli sono redatti per un regime giuridico diverso (la Direttiva sull’accessibilità del web) e fanno riferimento a meccanismi di segnalazione che non sono applicabili a un hotel privato. E non pubblicate una dichiarazione che affermi una piena conformità che non potete dimostrare, perché una dichiarazione che esagera è peggiore di una modesta ma accurata: trasforma una lacuna in buona fede in una falsa dichiarazione nel momento in cui un ospite individua una mancanza che avevate affermato non esistesse. Scrivete la verità, fissate una data di revisione e tenete sotto controllo il canale di contatto.

Come funzionano l’applicazione della normativa e le sanzioni, paese per paese

L’EAA è una direttiva, quindi non infligge direttamente multe a nessuno. Ogni Stato membro l’ha recepita nel proprio ordinamento giuridico e ha istituito il proprio organismo di controllo, la propria procedura di reclamo e il proprio limite massimo di sanzione. Ciò significa che il rischio concreto dipende in larga misura da dove si trovano i vostri ospiti e da dove operate, e le cifre variano di un ordine di grandezza. L’andamento nel primo anno è stato coerente in tutti i mercati: le autorità pubblicano linee guida, intervengono in seguito a reclami e controlli a campione di vigilanza sul mercato, e ordinano la correzione delle irregolarità entro una scadenza prima di ricorrere alla sanzione massima. Il vero fattore scatenante per un hotel è solitamente un reclamo da parte di un ospite o di un’organizzazione che difende i diritti delle persone con disabilità, non un’autorità di regolamentazione che setaccia il web a caso.

Irlanda

L’Irlanda ha recepito l’EAA tramite normative nazionali che designano le autorità di vigilanza sul mercato e di applicazione della legge e prevedono sanzioni sia amministrative che penali per la mancata conformità persistente. L’applicazione della legge è suddivisa tra diversi organismi a seconda del prodotto o del servizio. Per un hotel di lingua inglese che vende sul mercato irlandese e su quello più ampio dell’UE, l’Irlanda è una giurisdizione rilevante perché la lingua e la portata rendono i consumatori irlandesi un pubblico naturale. L’approccio operativo è lo stesso che altrove: un reclamo o un controllo a campione porta a un intervento e a un ordine di adeguamento, con sanzioni crescenti per gli operatori che ignorano l’ordine. Tenete a portata di mano la vostra dichiarazione, le prove di conformità e il registro delle misure correttive per poterli esibire.

Germania: la BFSG

Il recepimento tedesco è rappresentato dal Barrierefreiheitsstärkungsgesetz (BFSG), entrato in vigore il 28 giugno 2025. Si tratta di uno dei regimi più chiaramente specificati e uno dei più citati per la sua severità. La BFSG prevede sanzioni amministrative fino a 100.000 euro e conferisce all’autorità di vigilanza sul mercato il potere di vietare l’offerta di un servizio non conforme, il che, per un hotel online, significa un provvedimento che incide direttamente sul canale che vende le camere. La Germania dispone inoltre di una struttura di vigilanza dedicata a livello dei Länder. Per qualsiasi hotel con una domanda significativa proveniente dalla Germania – e ciò riguarda gran parte delle strutture ricettive nelle città europee e nelle località alpine – la BFSG è il regime contro cui pianificare le proprie strategie, poiché combina un limite massimo effettivo per le ammende con il potere di bloccare il servizio.

Francia: l’RGAA e la sanzione per le grandi imprese

La Francia ha integrato l’EAA in un regime di accessibilità già esistente. L’RGAA (Référentiel général d’amélioration de l’accessibilité) è il quadro di riferimento francese che attua le WCAG, e la Francia ha già multato le grandi aziende per la mancata pubblicazione delle informazioni sull’accessibilità e il mancato rispetto dei requisiti, con sanzioni amministrative che raggiungono i 50.000 euro per ogni servizio non conforme e una sanzione ricorrente se l’inadempienza non viene corretta entro il termine stabilito. Il recepimento dell’EAA estende la portata degli obblighi e dell’apparato di vigilanza. La Francia presenta inoltre una cultura attiva di reclami da parte dei consumatori e delle associazioni di tutela, pertanto la probabilità concreta di un ricorso è più elevata di quanto suggerisca la semplice disposizione di legge. Se vendete in Francia, aspettatevi che l’RGAA sia il metro di valutazione utilizzato da un revisore.

Spagna

La Spagna ha recepito l’EAA nel diritto nazionale con sanzioni amministrative graduate in base alla gravità, secondo la consueta struttura spagnola delle infrazioni leves, graves e muy graves, ciascuna con una propria fascia di multe. La supervisione dell’accessibilità per le persone con disabilità spetta a organismi consolidati, tra cui l’OADIS (la Oficina de Atención a la Discapacidad), mentre le autorità di settore si occupano della sorveglianza del mercato. Per un immobile in Spagna o per qualsiasi hotel con una forte domanda sul mercato spagnolo, la struttura delle sanzioni graduate implica che il costo di una violazione sia proporzionale alla sua gravità e alla sua persistenza, il che premia la correzione volontaria tempestiva e punisce gli operatori che, pur essendo stati avvertiti, non intervengono.

Italia: la tradizione della Legge Stanca

L’Italia vanta la tradizione legislativa più lunga in materia di accessibilità tra i paesi di questo gruppo. La Legge Stanca risale al 2004 e il recepimento italiano della EAA (basato sul quadro normativo del D.Lgs. 82/2022 e dei relativi decreti) estende gli obblighi del settore privato e i poteri di vigilanza, con l’AgID (l’Agenzia per l’Italia Digitale) al centro dell’architettura di controllo. La normativa italiana in questo contesto prevede sanzioni che, nei casi più gravi, possono arrivare fino al 5% del fatturato, il livello proporzionale più elevato tra i cinque mercati qui considerati. Per un hotel italiano, la combinazione di una tradizione giuridica consolidata e di un limite massimo legato al fatturato rende particolarmente vantaggioso adottare una posizione documentata e difendibile.

La lezione trasversale a tutti i mercati non è quella di memorizzare cinque tabelle di sanzioni. È piuttosto che lo stesso standard EN 301 549 e l’obiettivo WCAG 2.1 AA soddisfano tutti e cinque contemporaneamente; pertanto, la strategia più efficiente consiste nel conformarsi una volta sola allo standard, pubblicare una dichiarazione trasparente, conservare le prove e rispondere tempestivamente a qualsiasi reclamo. Una struttura che attui queste quattro misure è difendibile in ciascuna di queste giurisdizioni, indipendentemente da quale ospite presenti il reclamo per primo.

Come effettuare un audit del proprio sito in un pomeriggio

Non serve un’agenzia per individuare i problemi più gravi. Un gestore di siti web senza competenze di programmazione può individuare la maggior parte delle criticità ad alto rischio in un solo pomeriggio utilizzando strumenti gratuiti e le risorse già disponibili sulla propria scrivania. Vale la pena acquistare una verifica da parte di uno specialista una volta che hai fatto questo e desideri una valutazione completa e certificata, ma l’autoverifica ti dice quanto sia grave la situazione e cosa correggere per primo.

Esegui questi cinque passaggi in ordine. Il passaggio con la tastiera: scollega o ignora il mouse e completa una prenotazione intera utilizzando i tasti Tab, Shift-Tab, i tasti freccia e Invio. Prendi nota di ogni punto in cui ti blocchi, non riesci a vedere su cosa è posato il focus o non riesci a uscire da un controllo. Questo passaggio da solo individua gli errori di livello A che contano di più. La fase con lo screen reader: attiva VoiceOver (Mac, Cmd-F5) o Narrator (Windows, Ctrl-Win-Invio), chiudi gli occhi durante i passaggi chiave e cerca di comprendere ogni pagina e di completare la prenotazione. Presta attenzione ai campi che vengono letti come «vuoti», alle immagini che vengono letti come nomi di file e alle fasi che cambiano senza alcun avviso. Il controllo del contrasto: sottoponete il testo principale, i pulsanti e i bordi dei moduli a uno strumento gratuito di verifica del contrasto (quello di WebAIM è lo standard) e contrassegnate qualsiasi valore inferiore a 4,5 a 1 per il testo o a 3 a 1 per il testo di grandi dimensioni e i componenti. Il controllo automatizzato: esegui uno scanner gratuito come l’estensione per browser WAVE o axe DevTools sulla tua homepage, su una pagina di camera e su ogni fase della prenotazione; questi strumenti individuano rapidamente etichette mancanti, testo alternativo e problemi con i titoli, anche se individuano forse solo un terzo dei problemi, motivo per cui i controlli manuali vengono prima. La verifica dello zoom: imposta lo zoom del browser al 200% e ridimensiona la pagina in una finestra stretta; i contenuti che scompaiono, si sovrappongono o costringono allo scorrimento orizzontale non superano i criteri di ridimensionamento e adattamento.

Annotate ciò che ogni controllo rileva in un unico elenco condiviso, contrassegnato in base alla posizione (motore di prenotazione, pagine delle camere, navigazione, e-mail, documenti) e alla gravità (blocca una prenotazione, compromette una prenotazione, problema estetico). Quell’elenco costituisce la base per il piano di correzione. La maggior parte degli operatori indipendenti conclude il pomeriggio con un numero di risultati compreso tra quindici e quaranta e la chiara consapevolezza che tre o quattro di essi sono quelli che effettivamente causano la perdita di prenotazioni.

Il manuale di pulizia dell’accessibilità in 30 giorni

Un piano di 30 giorni per portare un tipico sito indipendente da “non abbiamo mai effettuato test” a “difendibile e in miglioramento”. Può essere gestito da una persona con un approccio operativo, coinvolgendo lo sviluppatore web o il fornitore del motore di prenotazione per il lavoro di implementazione. Sono necessarie alcune ore alla settimana da parte del responsabile e un blocco di tempo concentrato da parte di chi si occupa della manutenzione del sito.

Giorni da 1 a 4: verifica e selezione. Eseguite l’autoverifica in cinque fasi sopra descritta sul sito live, sia su desktop che su dispositivi mobili. Raccogliete tutti i risultati in un unico elenco, contrassegnateli in base all’area interessata e alla gravità, e identificate i tre o quattro errori che bloccano o compromettono gravemente una prenotazione. Queste sono le priorità; resistete alla tentazione di iniziare con gli aspetti estetici secondari.

Giorni da 5 a 7: individuare i fornitori. Inviare un’e-mail ai fornitori del motore di prenotazione e del channel manager e richiedere, per iscritto, la documentazione di conformità alle WCAG 2.1 AA o alla norma EN 301 549, la versione testata e la data. Chiedete come gestiscono il widget incorporato su un dominio del cliente. Archiviate le risposte. Laddove un fornitore non sia in grado di rispondere, registratelo come un rischio e una possibile decisione di approvvigionamento piuttosto che come una correzione che potete apportare autonomamente.

Giorni dall’8 al 16: correggere il flusso di prenotazione. Questa è la fase più impegnativa. Rendere l’intero processo di prenotazione utilizzabile tramite tastiera, ripristinare un indicatore di focus visibile, assegnare a ogni campo del modulo un’etichetta significativa, correggere i messaggi di errore in modo che indichino il campo e il problema, e garantire che il contrasto tra il pulsante principale e il testo del corpo sia conforme. Eseguite nuovamente i test con la tastiera e lo screen reader dopo ogni modifica, finché non sarà possibile completare l’intera prenotazione senza mouse e con lo screen reader attivo.

Giorni dal 17 al 22: correggere le pagine circostanti. Aggiungere un testo alternativo alle immagini significative e lasciare vuoto quello delle immagini decorative; correggere la struttura delle intestazioni; sistemare la navigazione e il selettore di lingua per l’uso con la tastiera; aggiungere didascalie al video di presentazione o al tour; e garantire che qualsiasi contenuto in movimento possa essere messo in pausa. Verificare che il sito si ridimensioni correttamente con uno zoom al 200%.

Giorni dal 23 al 26: correggere i documenti e le e-mail. Convertire le e-mail di conferma, pre-arrivo, ricevuta e conto in HTML strutturato con contrasto leggibile e un’alternativa in testo semplice. Trasferire i documenti possibili in pagine HTML accessibili e taggare i PDF che è necessario conservare. Testarne uno di ciascun tipo con lo screen reader.

Giorni dal 27 al 28: pubblica la dichiarazione. Scrivi e pubblica una dichiarazione di accessibilità trasparente che includa lo standard di riferimento, l’ambito di applicazione, le limitazioni note, un canale di contatto in caso di problemi e una data di revisione. Imposta il canale di contatto in modo che raggiunga una casella di posta reale monitorata da qualcuno.

Giorni dal 29 al 30: documentazione e pianificazione. Metti insieme il fascicolo probatorio: i risultati dell’audit e le correzioni apportate, i documenti di conformità dei fornitori, la dichiarazione pubblicata e, se ti avvali dell’esenzione per le microimprese, i dati relativi al numero di dipendenti e al fatturato a sostegno della richiesta. Inserite nel calendario un nuovo test trimestrale ricorrente, poiché i siti subiscono regressioni ogni volta che il tema o il motore di prenotazione vengono aggiornati. Informate chi si occupa della modifica del sito che le nuove immagini necessitano di testo alternativo e che i nuovi componenti richiedono una verifica della navigabilità da tastiera, in modo che questa disciplina venga mantenuta anche dopo la conclusione del progetto.

Impegno totale nei 30 giorni: circa 25-40 ore per il responsabile e un blocco di tempo dedicato da parte dello sviluppatore o del fornitore, concentrato principalmente nella settimana dedicata al flusso di prenotazione. Le strutture che gestiscono questo processo in modo così accurato eliminano gli ostacoli che impediscono l’accesso agli ospiti reali, assumono una posizione difendibile e, di solito, registrano come effetto collaterale un leggero aumento del completamento delle prenotazioni dirette, poiché le stesse correzioni che aiutano un utente di uno screen reader aiutano anche un ospite stanco al telefono in condizioni di scarsa illuminazione.

Il ruolo di Prostay, in breve e con sincerità

Scrivo per Prostay, quindi questa sezione è inevitabile; vorrei essere chiaro al riguardo. Prostay fornisce il motore di prenotazione, i modelli del sito web e il sistema di messaggistica per gli ospiti con l’accessibilità integrata nei componenti anziché aggiunta in un secondo momento; ciò significa che il flusso di prenotazione è progettato per funzionare tramite tastiera, i campi dei moduli riportano etichette significative, l’indicatore di focus viene mantenuto e la tavolozza cromatica predefinita del marchio è ottimizzata per soddisfare i requisiti di contrasto. Le e-mail di conferma, pre-arrivo e di riepilogo del conto inviate dal sistema di gestione della struttura utilizzano modelli strutturati e compatibili con gli screen reader, anziché immagini piatte. Nulla di tutto ciò è esclusivo di Prostay; Mews, Cloudbeds e diversi altri fornitori hanno svolto un serio lavoro di accessibilità sui propri stack, e ognuno di essi può offrirvi una base conforme.

Il punto di forza specifico di Prostay è che il motore di prenotazione, il sito web, il PMS e la messaggistica provengono da un unico team che li testa insieme secondo le WCAG 2.1 AA in tutte e cinque le lingue del sito; in questo modo non si finisce per inserire un widget accessibile in un tema inaccessibile sperando che le giunture reggano. Possiamo inoltre fornirvi la documentazione di conformità del fornitore necessaria per il vostro pacchetto di prove, eliminando così una delle fasi più dispendiose in termini di tempo del piano di 30 giorni. Se desiderate i dettagli sull’interfaccia rivolta agli ospiti, la panoramica del motore di prenotazione Prostay ve li illustra; se invece preferite che sia il nostro team a eseguire l’autoverifica e la correzione sul vostro sito live, prenotate una demo e analizzeremo il vostro flusso di prenotazione effettivo, anziché proporvi un servizio di consulenza sull’accessibilità separato.

Domande frequenti

Le cinque domande che gli albergatori indipendenti pongono più spesso riguardo alla legge europea sull’accessibilità, con risposte basate sulla direttiva e sulla norma armonizzata piuttosto che sui riassunti della stampa di settore.