Anteprima per lettori di schermo

Incolla HTML per vedere come uno screen reader lo linearizzerebbe e annuncerebbe. Verifica i tuoi testi alt, i tuoi titoli e i tuoi attributi ARIA.

Output dello screen reader

Incolla HTML e clicca su Analizza.
📚 Basi scientifiche e fonti

Per chi è progettato questo strumento

Gli screen reader sono una tecnologia assistiva essenziale per le persone cieche o con una significativa disabilità visiva. Secondo il Rapporto mondiale sulla vista dell'OMS (2019), almeno 2,2 miliardi di persone nel mondo soffrono di una disabilità visiva, di cui circa 43 milioni sono cieche. Il sondaggio WebAIM Screen Reader Survey (2024) rileva sistematicamente che la grande maggioranza degli utenti di screen reader sono persone con disabilità, con la cecità come motivo più frequente. Sviluppatori, designer e creatori di contenuti usano questo strumento per visualizzare l'anteprima di come il loro HTML sarà interpretato dalle tecnologie assistive, il che aiuta a individuare testi alternativi mancanti, strutture di titoli scorrette, pulsanti e campi senza nome accessibile e usi errati di ARIA, prima che gli utenti finali li incontrino.

Come funziona questo strumento

Questo strumento analizza il tuo HTML tramite il DOMParser nativo del browser (nessun dato lascia il tuo dispositivo), poi percorre l'albero di accessibilità per costruire un ordine di lettura linearizzato. Verifica la presenza di testi alternativi sulle immagini, la coerenza dei livelli dei titoli, link e pulsanti senza nome accessibile, ruoli ed etichette ARIA, così come campi modulo senza etichetta associata.

Riferimenti scientifici

  • WebAIM (2024). «Screen Reader User Survey #10 Results.» webaim.org · Il più grande sondaggio continuativo sui modi di utilizzo degli screen reader, sulle combinazioni di browser e sugli ostacoli all'accessibilità. Rileva sistematicamente che i titoli e i landmark sono le principali strategie di navigazione degli utenti.
  • Organizzazione mondiale della Sanità (2019). Rapporto mondiale sulla vista. · Riferisce che almeno 2,2 miliardi di persone nel mondo soffrono di una disabilità visiva da vicino o da lontano, di cui circa 43 milioni sono cieche.
  • Power, C., Freire, A., Petrie, H. & Swallow, D. (2012). «Guidelines are only half of the story: Accessibility problems encountered by blind users on the web.» Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '12). · Ha rilevato che una parte importante dei problemi di accessibilità incontrati dagli utenti ciechi non era coperta dalle WCAG da sole, sottolineando la necessità di una revisione manuale e di test con screen reader.
  • Lazar, J., Allen, A., Kleinman, J. & Malarkey, C. (2007). «What frustrates screen reader users on the web: A study of 100 blind users.» International Journal of Human-Computer Interaction, 22(3), 247–269. · Ha identificato testi alternativi mancanti, campi modulo senza etichetta ed etichette di link ingannevoli tra le principali frustrazioni riferite dagli utenti ciechi.
  • W3C WAI (2023). «WAI-ARIA Authoring Practices 1.2.» · Definisce come ruoli, stati e proprietà devono essere usati per rendere accessibile un contenuto dinamico alle tecnologie assistive.

Avvertenza

Questo strumento fornisce un'approssimazione semplificata dell'output di uno screen reader basata sull'albero di accessibilità HTML. Gli screen reader reali (NVDA, JAWS, VoiceOver, TalkBack) differiscono nel modo di annunciare il contenuto, di gestire gli attributi ARIA e di interagire con i widget dinamici. Questa anteprima non sostituisce i test con veri screen reader e veri utenti. È pensata per rilevare i problemi comuni in anticipo nel processo di redazione.

Una breve storia degli standard di accessibilità web

L'accessibilità sul web è governata da una piccola pila di standard dell'Iniziativa di Accessibilità Web W3C (WAI), oltre alle leggi nazionali che li referenziano. WCAG 1.0 è stato pubblicato a maggio 1999, la prima guida formale per rendere accessibili i contenuti web. Era largamente HTML-centrica e divenne rapidamente obsoleta. WCAG 2.0 (dicembre 2008) è stata una riscrittura maggiore organizzata attorno a quattro principi (Percepibile, Utilizzabile, Comprensibile, Robusto) e tre livelli di conformità (A, AA, AAA). È diventata uno standard ISO (ISO/IEC 40500) nel 2012 ed è l'obiettivo di conformità a cui la maggior parte delle leggi fa ancora riferimento. WCAG 2.1 (giugno 2018) ha aggiunto 17 nuovi criteri di successo che coprono mobile, ipovisione e disabilità cognitive. WCAG 2.2 (ottobre 2023) ne ha aggiunti altri 9, in particolare 2.4.11 Focus Non Oscurato e 3.3.8 Autenticazione Accessibile. WAI-ARIA 1.0 è stata finalizzata a marzo 2014; 1.2 a giugno 2023 è la Raccomandazione attuale. Sul lato legale, l'Aggiornamento della Sezione 508 USA (gennaio 2018) ha incorporato WCAG 2.0 AA negli appalti federali USA. La Legge Europea sull'Accessibilità (Direttiva 2019/882) è entrata in vigore il 28 giugno 2025, richiedendo che la maggior parte dei prodotti digitali rivolti ai consumatori nell'UE soddisfi gli standard di accessibilità. La maggior parte dei paesi fa riferimento a WCAG, quindi costruire per WCAG 2.2 AA è l'obiettivo pratico per qualsiasi prodotto globale oggi.

Il panorama degli screen reader oggi

Il WebAIM Screen Reader User Survey #10 (2024) è la fonte canonica su quali screen reader le persone usano effettivamente. Cinque prodotti dominano desktop, mobile e ChromeOS.

  • JAWS (Freedom Scientific, primo rilascio 1989) è il leader commerciale di lunga data su Windows. Costa ~$1000+. WebAIM 2024 lo trova come screen reader principale per circa il 40% degli intervistati, leggermente sotto NVDA.
  • NVDA (NV Access, primo rilascio 2006, scritto in Python) è l'alternativa open-source per Windows. Gratis. WebAIM 2024 lo riporta come lo screen reader principale più usato, circa il 47% degli intervistati. La crescita di NVDA da strumento di nicchia a leader di mercato in 15 anni è una delle grandi storie di successo open-source nella tecnologia assistiva.
  • VoiceOver (Apple, 2005 su macOS, 2009 su iOS) è integrato in ogni Mac, iPhone, iPad, Apple Watch, Apple TV. È lo screen reader mobile più usato. Strettamente integrato con Safari e il rotore iOS per la navigazione.
  • TalkBack (Google, 2009 su Android) è la controparte Android. Open-source da Android 4. Usa gesti e il menu di navigazione.
  • ChromeVox (Google, 2012) e Narrator (Microsoft, 2000, modernizzato in Windows 10) completano il quadro. Ciascuno ha una base utenti piccola ma fedele.

Una singola pagina può essere annunciata diversamente da ogni prodotto. Le pagine robuste testano pulite in almeno due: solitamente NVDA + Firefox o Chrome, e VoiceOver + Safari.

Quando ricorrere a questo strumento

  • Audit pre-lancio. Incolla una pagina chiave (homepage, modulo di iscrizione, checkout) e leggi ad alta voce l'output linearizzato. Se non ha senso per te, non avrà senso per un utente di screen reader.
  • Code review. Prima di fare merge di una PR con cambiamenti significativi di markup, incolla l'HTML renderizzato e conferma che intestazioni, landmark e alt text siano sopravvissuti intatti.
  • Verifica del handoff di design. I designer possono incollare il loro HTML finale per confermare che la gerarchia visiva corrisponda alla gerarchia semantica. Una pagina che sembra un'intestazione dovrebbe esserlo anche nel DOM.
  • Insegnare l'accessibilità. Mostra a una classe o a un team cosa riceve effettivamente uno screen reader. Il divario tra layout visivo e output linearizzato è spesso la prima volta che gli sviluppatori non disabili capiscono perché l'HTML semantico è importante.
  • Controlli di conformità con WCAG. Controlli rapidi a campione per i quattro criteri più violati: 1.1.1 Contenuto non testuale (alt text), 1.3.1 Informazioni e relazioni (struttura semantica), 2.4.4 Scopo del link, 4.1.2 Nome, Ruolo, Valore.
  • Controlli di siti CMS / no-code. Gli editor visivi spesso producono div invece di intestazioni o link senza testo. Incolla l'HTML pubblicato, vedi cosa è scivolato.
  • Accessibilità dei template email. Le email HTML sono notoriamente difficili da rendere accessibili. Usa l'anteprima per verificare l'alt text su ogni immagine, l'ordine corretto delle intestazioni e un flusso di lettura leggibile.

Errori comuni che gli screen reader espongono

  • Alt text mancante o inutile. alt="image", alt="photo", alt="logo" sono appena meglio di nulla. Lazar et al. (2007) ha identificato l'alt text mancante come la principale frustrazione degli utenti web ciechi. Scrivi un alt text che trasmetta lo scopo dell'immagine nel contesto circostante, o usa alt="" per le immagini puramente decorative in modo che lo screen reader le salti.
  • Livelli di intestazione che saltano o ricominciano. Andare da h1 a h3 saltando h2 confonde la navigazione. Usare più elementi h1 sulla stessa pagina (un pattern abbastanza comune nel design guidato da componenti) rompe lo schema del documento attraverso cui navigano gli utenti di screen reader. WebAIM 2024 trova che le intestazioni sono la strategia di navigazione più comune per gli utenti di screen reader.
  • Divite. Avvolgere testo cliccabile in <div> con un click handler invece di usare <button> o <a> significa nessun supporto da tastiera, nessun anello di focus, nessun annuncio di ruolo. Inizia sempre dall'HTML semantico e aggiungi ARIA solo quando nessun elemento nativo si adatta.
  • ARIA usato dove HTML basterebbe. Prima regola di ARIA (secondo le W3C WAI-ARIA Authoring Practices): «se puoi usare un elemento HTML nativo... fallo». <button role="button"> è ridondante; <div role="button"> è un segno che dovresti usare un vero bottone.
  • ARIA usato in modo errato. aria-hidden="true" su un elemento focalizzabile lo rende invisibile agli screen reader ma comunque focalizzabile da tastiera, una ricetta per un tab order disorientante. role="button" senza tabindex="0" e gestori da tastiera non fa nulla di utile.
  • Campi modulo senza label. Un <input> senza un <label>, aria-label o aria-labelledby associato viene annunciato come «edit, blank» senza contesto. Il testo placeholder non è un sostituto, scompare al focus e spesso fallisce il contrasto.
  • Link «clicca qui» e «leggi di più». Gli utenti di screen reader spesso navigano tirando su l'elenco di tutti i link sulla pagina. «Clicca qui» da solo non dice loro nulla. Fai che il testo del link descriva la destinazione: «Leggi il sondaggio WebAIM 2024» batte «Leggi di più qui».
  • Rimuovere gli stili di focus. outline: none senza un indicatore di focus sostitutivo è uno dei criteri WCAG più violati (2.4.7 Focus Visibile). Gli utenti da tastiera, inclusi molti utenti di screen reader, devono vedere dov'è il focus.

ARIA a colpo d'occhio: cosa fa ogni tipo di ruolo

  • Ruoli landmark (banner, navigation, main, complementary, contentinfo, search) dividono la pagina in regioni tra cui un utente di screen reader può saltare. La maggior parte ha equivalenti HTML nativi (<header>, <nav>, <main>, <aside>, <footer>). Usa prima l'elemento nativo.
  • Ruoli widget (button, checkbox, combobox, menu, tabpanel, ecc.) descrivono controlli interattivi. I ruoli widget implicano pattern di interazione da tastiera che la W3C ARIA Authoring Practices Guide (APG) documenta in dettaglio. Se non puoi corrispondere esattamente alla specifica APG, preferisci HTML nativo.
  • Ruoli struttura documento (article, list, listitem, row, cell, ecc.) descrivono contenuto non interattivo. La maggior parte ha anche equivalenti HTML nativi. Usali solo quando l'elemento nativo non è disponibile (es. costruire una griglia dati personalizzata dove <table> non si adatta).
  • Regioni live (aria-live="polite", aria-live="assertive", role="status", role="alert") dicono agli screen reader di annunciare aggiornamenti dinamici senza spostare il focus. Usato per messaggi di chat, errori di modulo, stati di caricamento. L'uso eccessivo causa stanchezza da notifica; riserva assertive per vere emergenze come stati di errore.

Altre domande frequenti

Questa anteprima corrisponde a ciò che NVDA / JAWS / VoiceOver diranno effettivamente?

Approssima. Questo strumento legge l'albero di accessibilità del browser (la stessa struttura che usano gli screen reader) e produce una versione linearizzata di ciò che verrebbe annunciato. I veri screen reader aggiungono comportamenti specifici del prodotto: annunci di cambi di focus, navigazione tabella, intestazioni tabella, conteggi elementi lista, gestione cortesia ARIA-live, impostazioni di verbosità personalizzate. Trattate l'anteprima come un primo controllo di buon senso; per i lanci in produzione, testate con almeno un vero screen reader sui sistemi operativi che il vostro pubblico usa.

Qual è la differenza tra WCAG e ARIA?

WCAG (Web Content Accessibility Guidelines) è una lista di requisiti: «ogni contenuto non testuale deve avere un'alternativa testuale». Ti dice cosa raggiungere ma non sempre come. ARIA (Accessible Rich Internet Applications) è uno degli strumenti per soddisfare WCAG: un set di attributi HTML (ruoli, stati, proprietà) che espone la semantica alla tecnologia assistiva quando l'HTML nativo è insufficiente. Puoi soddisfare WCAG senza alcun ARIA se il tuo HTML è abbastanza semantico. ARIA è per i casi in cui non lo è.

Come scrivo un buon alt text?

Tre regole dall'Albero Decisionale alt del W3C: (1) Se l'immagine è puramente decorativa, usa alt="" in modo che lo screen reader la salti completamente. (2) Se l'immagine trasmette informazioni non già nel testo circostante, descrivi quelle informazioni in modo conciso (tipicamente sotto i 125 caratteri). (3) Se l'immagine è funzionale (es. un logo che linka alla home, o un pulsante icona), descrivi l'azione piuttosto che l'aspetto. «Cerca» batte «icona lente di ingrandimento». Evita «immagine di...», «foto di...», gli screen reader già annunciano che l'elemento è un'immagine.

Il mio sito usa div ovunque. Da dove inizio?

Inizia aggiungendo i cinque elementi landmark: <header>, <nav>, <main>, <aside>, <footer>. Poi sostituisci i div cliccabili con <button> (per azioni) o <a> (per navigazione). Poi audita le intestazioni: ogni pagina dovrebbe avere un <h1> e il resto in ordine annidato. Questi tre passi risolvono forse il 70% dei problemi di accessibilità su un tipico sito carico di div. ARIA e gestione del focus JavaScript vengono dopo, una volta che la base semantica è in posizione.

L'HTML che incollo qui viene inviato da qualche parte?

No. Il parsing usa il DOMParser integrato del browser e l'analisi gira interamente lato client. Apri la scheda Rete in DevTools e clicca Analizza, vedrai zero richieste in uscita durante la linearizzazione. Sicuro per template interni, pagine non rilasciate o HTML contenente dati clienti.

Strumenti correlati

Controllo intestazioni WCAG Risorse per l'accessibilità Generatore di tavolozze di colori accessibili Verificatore contrasto colori