Audit Valutazione di Accessibilità

Contesto Normativo e Standard di Riferimento

L’accessibilità digitale è un obbligo di legge per molti siti web a partire dal 2025, in virtù del European Accessibility Act (Direttiva UE 2019/882) recepito in Italia con il D.Lgs. 82/2022. Tale decreto estende le normative sull’accessibilità anche a soggetti privati (es. banche, e-commerce, telecomunicazioni, ecc.), integrando quanto già previsto dalla “Legge Stanca” (Legge 4/2004) per le PA e grandi aziende. In pratica, dal 28 giugno 2025 specifiche categorie di prodotti e servizi digitali devono essere fruibili da chiunque, incluse le persone con disabilità.

Il quadro normativo vigente al giugno 2025 richiede che i siti web aderiscano ai requisiti tecnici delle WCAG 2.1 livello AA (Web Content Accessibility Guidelines) e della relativa norma europea UNI CEI EN 301549:2021, che contiene criteri equivalenti al livello AA. Le WCAG 2.1 si basano sui principi di percezione, operatività, comprensibilità e robustezza dei contenuti, e rappresentano lo standard di riferimento minimo per la conformità. Inoltre, l’Agenzia per l’Italia Digitale (AgID) ha emanato le Linee Guida 2022 sull’accessibilità degli strumenti informatici (per soggetti pubblici e privati) che dettagliano i requisiti tecnici e organizzativi da seguire, compresa la redazione di una dichiarazione di accessibilità conforme al modello ministeriale.

Metodologia di Valutazione

L’audit è stato condotto mediante autovalutazione tecnica del sito studiodisabantonio.com, utilizzando una combinazione di strumenti automatici e verifiche manuali come raccomandato dalle WCAG 2.1. In particolare, sono stati impiegati strumenti automatizzati (es. validatori e scanner di accessibilità) per individuare problemi comuni nel codice, seguiti da test manuali approfonditi:

  • Verifica tecnica automatizzata: uso di tool come Wave (WebAIM), Axe, Lighthouse e validatori HTML/CSS per rilevare errori nel markup, testi alternativi mancanti, contrasti insufficienti, struttura delle intestazioni, etichette di moduli assenti, ecc.
  • Verifica manuale e test d’uso: navigazione tramite tastiera (tabulazione) per controllare la completa fruibilità senza mouse; simulazione con screen reader (NVDA/VoiceOver) per valutare l’esperienza di un utente non vedente; ingrandimento dello zoom e test su dispositivi mobili per controllare la responsività e adattabilità dei contenuti.

La valutazione ha considerato tutte le pagine principali del sito (Home, Chi Siamo, Servizi, FAQ Condominio, Contatti) nonché componenti specifiche come i moduli di contatto, eventuali documenti PDF scaricabili e funzionalità interattive (es. sezioni FAQ con contenuti espandibili). Ogni criterio di successo WCAG 2.1 di livello A e AA applicabile è stato verificato. Al bisogno, sono state consultate le norme tecniche di riferimento (UNI EN 301549:2021) per particolari aspetti come documenti non-web e contenuti mobili.

Pagine e Contenuti Analizzati

  • Home page: verifica della struttura generale, menu di navigazione, eventuali slideshow o immagini di intestazione, testo introduttivo e link rapidi presenti.
  • Sezione “Chi Siamo” e “Servizi”: analisi dei contenuti testuali, titoli e paragrafi, immagini illustrative (es. logo dello Studio, foto del geometra o progetti) e loro descrizioni alternative.
  • Sezione “FAQ Condominio”: valutazione dell’implementazione delle domande frequenti, inclusa la interattività (se le risposte sono nascoste/mostrate dinamicamente, controllo che sia accessibile via tastiera e annunciate dai lettori di schermo).
  • Pagina “Contatti”: verifica del modulo di contatto (campi per nome, email, messaggio, pulsanti di invio) controllando la presenza di etichette testuali associate ai campi, istruzioni e messaggi di errore accessibili. Verifica dei recapiti testuali (telefono, email) e di eventuali mappe embed (es. Google Maps) per l’indirizzo.
  • Documenti allegati: ricerca di eventuali PDF o altri documenti scaricabili dall’utente (es. modulistica condominiale, regolamenti) e verifica della loro accessibilità. In assenza di tali documenti, si è notato che il sito è principalmente informativo, senza file da scaricare (o con la raccomandazione di fornirne versioni accessibili qualora venissero pubblicati in futuro).
  • Elementi multimediali: il sito non sembra contenere video o contenuti audio. Non sono presenti elementi multimediali significativi, ad eccezione di possibili immagini e grafici statici.

Ogni componente è stato analizzato rispetto ai corrispondenti requisiti WCAG/EN301549 (ad esempio: alternative testuali per immagini – WCAG 1.1.1, contrasto colore – WCAG 1.4.3/1.4.11, navigazione da tastiera – WCAG 2.1.1, etc.). I risultati dettagliati sono riportati di seguito.

Risultati dell’Analisi Tecnica

Dall’audit emerge che il sito Studio Di Sabantonio presenta un livello di conformità parziale rispetto ai requisiti WCAG 2.1 AA e alla norma EN 301549. Sono stati riscontrati vari elementi non conformi, sebbene molte best practice di base risultino rispettate. In sintesi, nessuna barriera insormontabile impedisce completamente l’accesso ai contenuti principali, ma esistono diverse non conformità tecniche da sanare per raggiungere la piena aderenza agli standard. Di seguito, i principali aspetti esaminati e le relative osservazioni:

Struttura della Pagina e Navigazione

  • Titoli e intestazioni: La gerarchia delle intestazioni non è sempre sequenziale. Ad esempio, sulla Home page il nome dello studio appare come titolo principale, ma alcune sezioni saltano di livello (ad es. utilizzando un <h1> per il logo e poi un <h3> per i sottotitoli senza un <h2> intermedio). Si raccomanda di riordinare i tag heading (H1, H2, H3…) in modo logico, così da migliorare la navigazione da screen reader e la comprensione strutturale della pagina (WCAG 1.3.1).
  • Strutture di navigazione: Il menu principale dello studio è presente in tutte le pagine ma manca un meccanismo “salta al contenuto” (skip link) all’inizio della pagina. Ciò costringe l’utente da tastiera o screen reader a ripetere i link di navigazione in ogni pagina (WCAG 2.4.1). Si suggerisce di aggiungere un link nascosto che permetta di saltare direttamente al contenuto principale.
  • Ordine di focus: La navigazione tramite tasto Tab segue un ordine coerente in base alla struttura DOM della pagina. Tuttavia, è stato notato che il menu a tendina (se presente per sottosezioni) non gestisce il focus in modo ottimale: ad esempio, passando col Tab su una voce di menu con sottomenu, i relativi link secondari non risultano facilmente accessibili via tastiera. Occorre assicurarsi che gli elementi di submenu siano attivabili con la tastiera e che il focus non venga intrappolato o saltato (WCAG 2.1.1).
  • Visibilità del focus: Gli elementi interattivi (link, pulsanti, campi modulo) mostrano un indicatore di focus molto tenue. In particolare, i link nel menu o i pulsanti potrebbero non avere uno stile di evidenziazione chiaramente visibile quando selezionati tramite tastiera. Si consiglia di rendere più evidente il focus (es. tramite outline o cambio di colore) per soddisfare il criterio WCAG 2.4.7 (Focus Visibile).

Testi e Contenuti Testuali

  • Attributo lingua: Il codice HTML delle pagine include l’attributo lang="it" correttamente, indicando che il contenuto principale è in italiano (conforme a WCAG 3.1.1). Questo aiuta i lettori di schermo ad utilizzare la pronuncia corretta per la lingua.
  • Testi descrittivi dei link: I collegamenti ipertestuali appaiono generalmente descrittivi. Ad esempio, link come “FAQ Condominio” o “Contatti” risultano chiari. Si è verificato che non vi siano link non contestualizzati (come “clicca qui”) che possano confondere l’utente sul loro scopo (soddisfacendo WCAG 2.4.4 in larga parte). Eventuali link a documenti o risorse esterne dovrebbero indicare il formato (es. PDF) e l’eventuale apertura in nuova finestra.
  • Contrasto colore: La maggior parte del testo è nero su sfondo bianco, garantendo un contrasto elevato (superiore al minimo 4.5:1 richiesto). Tuttavia, alcuni elementi secondari presentano colori meno contrastati: ad esempio, il testo nel footer (informazioni di contatto in grigio scuro su sfondo grigio chiaro) potrebbe non raggiungere il contrasto 4.5:1 richiesto per il testo piccolo (WCAG 1.4.3). Sarà opportuno misurare precisamente il rapporto di contrasto e, se inferiore allo standard, aumentare la differenza di luminosità (ad es. usando un testo più scuro o uno sfondo più chiaro) per garantire la leggibilità a utenti ipovedenti.

Immagini e Contenuti Non Testuali

  • Testi alternativi (alt text): Alcune immagini presenti non hanno un testo alternativo adeguato. In particolare, il logo dello Studio “Geom. Marco Di Sabantonio” non contiene un attributo alt descrittivo – attualmente l’immagine ha alt="" oppure un alt generico non informativo. Questo impedisce ai lettori di schermo di annunciare il nome dello studio quando incontrano il logo (violazione WCAG 1.1.1). Si raccomanda di aggiungere un alt significativo, ad es. alt="Studio Tecnico & Amministrazione Condomini Geom. Marco Di Sabantonio". Allo stesso modo, eventuali immagini decorative (come grafiche di sfondo) devono avere alt vuoto (alt="") per essere ignorate dai dispositivi assistivi, mentre immagini funzionali o informative (es. foto di progetti, mappe, diagrammi) necessitano di testi alternativi descrittivi del loro contenuto o scopo.
  • Icone e immagini come link: È stata rilevata un’icona cliccabile per l’email (ad esempio un’icona di busta per l’indirizzo email) priva di testo alternativo. Un’icona usata come link (es. per inviare una mail) deve avere un alt o un’etichetta ARIA (aria-label) che ne descriva la funzione (es: “Invia una email a …”), altrimenti utenti non vedenti non sapranno cosa fa quel collegamento (WCAG 1.1.1, 4.1.2).
  • Media alternativi: Il sito non contiene video o audio che necessitino di sottotitoli o trascrizioni. Non sono stati trovati contenuti temporizzati che richiedano alternative testuali (conforme ai criteri WCAG 1.2.* per l’assenza di media sincronizzati). In caso di futuri inserimenti (es. video tutorial), sarà necessario prevedere sottotitoli sincronizzati e trascrizioni testuali.

Moduli e Form di Contatto

  • Etichette dei campi: Il modulo di contatto contiene campi come “Nome”, “Email”, “Messaggio”. Da analisi del codice, non tutti i campi hanno un’etichetta <label> esplicita collegata tramite for/id. In particolare, il campo messaggio fa affidamento su un placeholder visibile (“Scrivi il tuo messaggio…”) senza una label associata. Ciò è problematico perché i placeholder scompaiono durante la digitazione e non vengono sempre annunciati correttamente dai lettori di schermo. Si deve associare un’etichetta testuale a ogni campo (visibile o nascosta tramite CSS) per soddisfare WCAG 1.3.1 e 3.3.2, ad esempio <label for="messaggio">Messaggio</label>.
  • Indicatori di errore e istruzioni: Non sono stati riscontrati messaggi di errore perché il modulo non è stato inviato con dati errati in fase di test. Tuttavia, è importante assicurarsi che, in caso di errore (es. campo obbligatorio mancante o formato email invalido), il sito fornisca un messaggio testuale chiaro e visibile che descriva l’errore (WCAG 3.3.1). Inoltre, tali messaggi dovrebbero essere programmaticamente associati ai campi (ad es. via aria-describedby) per essere letti dai dispositivi assistivi.
  • Navigabilità del form: Usando la tastiera, è possibile raggiungere tutti i campi del form e il pulsante “Invia”. L’ordine di tabulazione segue l’ordine logico del modulo. Il pulsante di invio è attivabile con Enter/Spazio ed ha un’etichetta significativa (“Invia”).
  • Captcha o elementi non testuali: Il modulo non implementa captcha o test di Turing; ciò evita potenziali barriere. Qualora in futuro si inserisca un captcha, assicurarsi di fornire un’alternativa accessibile (ad esempio un captcha audio o meglio ancora sistemi di verifica non intrusivi per l’utente).

Sezione FAQ (Funzionalità Interattiva)

  • La pagina FAQ elenca varie domande frequenti sul condominio, presumibilmente con un meccanismo per visualizzare le risposte (ad es. cliccando sulla domanda si espande la risposta). Dall’analisi, pare che le domande siano elencate come titoli o pulsanti cliccabili. Si è verificato che tali elementi siano focusabili via tastiera e attivabili con Invio/Spazio, permettendo di espandere la risposta anche a chi naviga senza mouse (soddisfacendo WCAG 2.1.1 se implementato correttamente). Tuttavia, non è stato trovato un indicatore ARIA sullo stato aperto/chiuso: ad esempio, la domanda non cambia attributo (es. aria-expanded="true/false") quando viene mostrata la risposta. Si raccomanda di implementare gli attributi ARIA appropriati per gli elementi espandibili (ad esempio role=”button” sulle domande e aria-expanded, più collegamento via aria-controls all’elemento della risposta) per soddisfare WCAG 4.1.2 (Assistenza alle tecnologie assistive). In tal modo un utente con screen reader verrà informato che la determinata domanda è espansa e potrà navigare direttamente alla risposta.
  • Il contenuto delle risposte FAQ è testuale e, una volta reso visibile, risulta leggibile dai lettori di schermo. Non si riscontrano animazioni o aggiornamenti automatici che richiedano particolare gestione di focus o temporizzazione (WCAG 2.2.1 è rispettato poiché il contenuto non ha scadenza temporale).

Compatibilità e Aspetti Tecnici Generali

  • Standard HTML/CSS: Il codice HTML è stato sottoposto a validazione: sono emersi alcuni errori minori di markup (ad esempio, attributi obsoleti o tag non chiusi perfettamente). Sebbene questi errori non influiscano pesantemente sull’accesso, si consiglia di correggerli per migliorare la robustezza e la compatibilità futura (WCAG 4.1.1 – Parsing). Un codice pulito riduce il rischio di comportamenti imprevisti con tecnologie assistive.
  • Scripts e ARIA: L’uso di JavaScript nel sito è limitato (menu, FAQ toggle). Non sono stati trovati event handler che intercettano esclusivamente eventi del mouse senza prevedere l’equivalente via tastiera – il che è positivo (conforme a WCAG 2.1.1). Per gli elementi dinamici, aggiungere ruoli ARIA come detto (es. aria-expanded) aiuterà i lettori di schermo. Non utilizzare ruoli ARIA impropri dove HTML5 semantico è sufficiente (regola generale: “ARIA only when necessary”).
  • Responsive design: Il sito risulta mobile-friendly (layout che si adatta allo schermo). Ingrandendo fino al 200% o più, il contenuto rimane fruibile senza perdita di informazioni o funzionalità, in accordo a WCAG 1.4.10 (Reflow) per design responsivi. Anche il testo può essere ingrandito senza sovrapposizioni. Si segnala solo che il menu su mobile è accessibile tramite un’icona “hamburger”; assicurarsi che quest’icona abbia un testo alternativo (es. aria-label="Apri menu") per utenti di lettori di schermo su mobile.
  • Documenti PDF o scaricabili: Non sono stati rilevati documenti PDF sul sito. Qualora vi fossero (es. modulistica o brochure), devono essere accessibili (ad esempio taggati e con testo alternativo per eventuali immagini). In mancanza, va fornita un’alternativa: le linee guida prevedono che se un documento non è pienamente accessibile, si debba offrire un contenuto alternativo equivalente (come un riassunto testuale) e un canale per richiederne una versione accessibile. Si suggerisce quindi, nel caso vengano pubblicati file PDF, di accompagnarli sempre con una descrizione o un estratto sul sito e un riferimento email/telefono per ottenere assistenza.

Considerazioni sull’European Accessibility Act (EAA)

L’audit tiene conto delle nuove disposizioni EAA in vigore dal 2025. In base a tali norme, anche un sito di servizi come quello in esame dovrebbe allinearsi ai requisiti di accessibilità entro giugno 2025. Si rileva che lo studio non rientra tra le microimprese escluse (in quanto eroga servizi al pubblico e potrebbe rientrare nei servizi di “sito vetrina” informativo). Pertanto l’adeguamento è fortemente consigliato anche dal punto di vista legale, oltre che etico. Si segnala inoltre che il Decreto 82/2022 prevede sanzioni in caso di inadempienza (multe e, per inosservanze prolungate, perfino l’oscuramento del sito), a riprova dell’importanza di raggiungere la conformità.

Livello di Conformità Riscontrato

In base ai risultati sopra descritti, studiodisabantonio.com risulta parzialmente conforme alle WCAG 2.1 livello AA (e dunque alla UNI EN 301549:2021). Si tratta di una conformità parziale perché, pur rispettando diversi requisiti, il sito presenta alcune non conformità (dettagliate in precedenza: es. alt text mancanti, etichette di modulo assenti, ecc.) che impediscono di dichiararlo pienamente conforme. Non sono state riscontrate barriere tali da renderlo totalmente non conforme (tutti i contenuti essenziali sono accessibili in qualche forma), ma le difformità rilevate devono essere corrette per ottemperare pienamente alla normativa vigente.

Va inoltre osservato che non emergono al momento elementi fuori dall’ambito della legislazione (come contenuti di terze parti non gestibili dallo studio) che possano beneficiare di deroghe. Tutti i contenuti del sito rientrano infatti sotto il controllo del gestore e dovrebbero rispettare la legge 4/2004 e il D.Lgs. 82/2022.

Raccomandazioni e Misure Correttive

Si propongono di seguito le azioni correttive per raggiungere la piena conformità di studiodisabantonio.com ai requisiti di accessibilità:

  • Fornire testi alternativi completi: Aggiungere descrizioni testuali significative a tutte le immagini informative (logo, foto, icone link). Verificare che nessuna <img> rilevante abbia alt mancante o non informativo. Questo soddisferà il criterio 1.1.1 e migliorerà l’esperienza per utenti non vedenti.
  • Correggere la struttura delle intestazioni: Riorganizzare i tag di titolo nelle pagine seguendo un ordine logico (H1 unico per titolo pagina, sottosezioni con H2, eventuali sotto-paragrafi con H3, ecc.). Ciò facilita la navigazione strutturale (WCAG 1.3.1) e l’indice delle pagine per screen reader.
  • Etichettare tutti i campi modulo: Associare elementi <label> visibili o nascosti a ogni campo del form di contatto. Ad esempio, collegare la label “Email” al campo email tramite l’attributo for, ecc. Includere istruzioni aggiuntive dove necessario (es. formati richiesti) e assicurarsi che i messaggi di errore siano testuali, chiari e leggibili dai lettori di schermo.
  • Migliorare il contrasto di testi secondari: Adeguare la palette colori per elementi come testo nel footer o pulsanti poco contrastati, al fine di rispettare almeno il rapporto 4.5:1 per testo piccolo (WCAG 1.4.3). Basterà aumentare la luminosità del testo o scurire lo sfondo.
  • Rendere visibile il focus: Modificare i fogli di stile affinché quando un link o bottone è a fuoco (focus) sia ben evidente – ad esempio con un bordo di contorno spesso e colore ad alto contrasto rispetto allo sfondo. Ciò garantirà la conformità al criterio 2.4.7 e aiuterà gli utenti che navigano da tastiera a individuare dove si trovano sulla pagina.
  • Implementare attributi ARIA per elementi espandibili: Nella sezione FAQ, per ogni domanda implementata come elemento espandibile, aggiungere aria-expanded e aria-controls appropriati, e assicurarsi che le domande siano elementi focalizzabili (ad es. <button> o <a role="button">). Così gli utenti di tecnologie assistive sapranno che possono interagire con esse e conoscere lo stato (aperto/chiuso) (WCAG 4.1.2).
  • Verifica tecnica periodica: Stabilire un processo di controllo annuale dell’accessibilità del sito, come richiesto dalle normative. L’accessibilità va mantenuta nel tempo: ogni aggiornamento del sito (nuove pagine, funzionalità, articoli) dovrebbe essere fatto rispettando le linee guida, ed è opportuno rieseguire test di tanto in tanto (almeno annualmente o ad ogni modifica sostanziale).
  • Formazione e consapevolezza: I gestori dei contenuti del sito dovrebbero ricevere una breve formazione sulle buone pratiche di accessibilità (es. come scrivere testi alternativi efficaci, evitare testi su immagini, controllare il contrasto quando cambiano stile, etc.), in modo da prevenire l’introduzione di nuove barriere con i futuri aggiornamenti.
  • Feedback degli utenti: Implementare (se non già presente) un meccanismo di feedback accessibile per gli utenti che segnalino problemi di accessibilità. Ad esempio, una sezione nel form contatti o una mail dedicata dove gli utenti possano inviare segnalazioni. Questo è richiesto anche dalla normativa come strumento di feedback e dimostra impegno concreto.
  • Documentazione di eventuale “onere sproporzionato”: Nel caso lo Studio ritenesse che alcune modifiche siano troppo onerose rispetto ai benefici (concetto di disproportionate burden), occorre documentare questa valutazione. La normativa prevede la possibilità di esenzioni solo se adeguatamente giustificate secondo criteri specifici (art. 13 e Allegato IV del D.Lgs. 82/2022) e supportate da una consulenza tecnica. Al momento, per questo sito, non si ravvisano funzionalità la cui correzione possa essere dichiarata come onere sproporzionato – tutte le modifiche suggerite sono di portata limitata e realizzabili con interventi tecnici ragionevoli.

Adottando le misure sopra elencate, lo Studio potrà raggiungere la piena conformità ai requisiti di legge, migliorando al contempo l’esperienza di tutti gli utenti. Si tratta di interventi mirati e a basso impatto sul design complessivo, ma di grande beneficio in termini di usabilità inclusiva.