Relazione di Audit di Accessibilità sito studionutrizionezanghi.it

Contesto Normativo e Obiettivi dell’Audit

Il sito www.studionutrizionezanghi.it è oggetto di un audit approfondito in materia di accessibilità digitale, in conformità con la normativa europea e italiana vigente. In particolare, il European Accessibility Act (Direttiva UE 2019/882) e il relativo decreto di recepimento in Italia (D.Lgs. 82/2022) richiedono che, entro giugno 2025, i servizi digitali offerti al pubblico da soggetti privati soddisfino requisiti stringenti di accessibilità. Tali requisiti tecnici si basano sulle WCAG 2.1 – Livello AA, standard internazionale per l’accessibilità web, come richiamato dalla norma europea EN 301 549 e dalla normativa italiana.

Obiettivo principale: verificare se le pagine pubbliche del sito rispettano le Web Content Accessibility Guidelines (WCAG) 2.1 livello AA e identificare eventuali non conformità. L’audit include:

• Verifica tecnica di conformità ai criteri WCAG 2.1 AA (ad es. testo alternativo per immagini, contrasto colori minimo 4.5:1, navigabilità da tastiera, ecc).
• Test con tecnologie assistive (screen reader NVDA/JAWS su PC, VoiceOver su dispositivi Apple, oltre alla sola navigazione tramite tastiera), per valutare la fruibilità reale per utenti con disabilità visive e motorie.
• Analisi semantica e strutturale del codice HTML delle pagine, verificando uso corretto di intestazioni, liste, tabelle, ruoli ARIA e struttura delle pagine per garantire un’esperienza coerente e comprensibile.
• Identificazione delle aree di non conformità rispetto ai requisiti di legge e linee guida tecniche.
• Raccomandazioni puntuali per correggere le criticità riscontrate e migliorare l’accessibilità del sito.
• Allineamento alle Linee Guida AgID (aprile 2022) per i soggetti privati (art. 3 co.1-bis Legge 4/2004), anche in vista della redazione della Dichiarazione di Accessibilità secondo il modello previsto.

Metodologia di Verifica

L’audit è stato svolto tramite un mix di strumenti automatici e verifiche manuali, in linea con le best practice raccomandate. In particolare, si è proceduto con:

• Analizzatori automatici WCAG: una scansione preliminare con tool automatici (es. axe, WAVE, Accessibility Checker) per individuare rapidamente problemi noti di conformità (es. immagini senza alt, errori ARIA, contrasti insufficienti, etc.). I risultati automatici sono stati poi verificati manualmente, poiché alcuni errori di accessibilità possono sfuggire o, viceversa, alcuni “false positive” vanno contestualizzati.
• Revisione manuale esperta: un esperto di accessibilità ha esaminato il codice HTML e il contenuto delle pagine, valutando il rispetto di ciascun criterio WCAG 2.1 di livello A e AA. Si sono controllati attributi e markup (ad esempio presenza di testi alternativi, struttura delle intestazioni, utilizzo di ruoli ARIA dove opportuno, presenza di didascalie per contenuti multimediali, ecc.).
• Test con screen reader: le pagine sono state navigate utilizzando i lettori di schermo NVDA e JAWS su Windows, nonché VoiceOver su macOS/iOS, per ascoltare l’output uditivo e verificare che tutti gli elementi (menu, paragrafi, link, moduli) vengano annunciati correttamente. Questo passaggio è fondamentale, perché molte organizzazioni trascurano di testare con screen reader reali, rischiando di non accorgersi di problemi che solo la navigazione assistita può rivelare. Durante il test, si è utilizzata la funzionalità di Speech Viewer di NVDA per catturare esattamente l’output testuale letto dal lettore di schermo.
• Test di navigazione da tastiera: si è verificato che ogni funzionalità del sito sia utilizzabile senza mouse, tramite il tasto Tab per spostarsi tra link e controlli, Invio/Spazio per attivarli, e altre scorciatoie standard. Questo è essenziale perché siti progettati solo per l’uso con mouse risultano inutilizzabili per chi ha disabilità motorie. Sono stati controllati in particolare: la visibilità del focus da tastiera (cioè l’evidenziazione dell’elemento attivo), l’assenza di “trappole” della tastiera (elementi da cui non si riesce più a uscire con Tab/Shift+Tab), e la possibilità di accedere a tutti i menù e contenuti interattivi.
• Ambiente di test: L’analisi ha riguardato le pagine pubblicamente accessibili del sito web (circa 32 pagine e 31 articoli del blog) realizzato con CMS WordPress. Il test è stato condotto su browser desktop (Chrome, Firefox) e mobile, tenendo conto della responsività del layout. Si è inoltre esaminata l’Area Riservata(sezione ad accesso limitato agli utenti registrati) per verificarne almeno la schermata di login e le funzionalità principali, laddove accessibili.

Da notare che, in base alle Linee Guida AgID, le informazioni della dichiarazione di accessibilità devono provenire “da un’autovalutazione effettuata dal soggetto erogatore oppure da una valutazione effettuata da terzi, tramite una combinazione di test automatici e verifiche manuali”. L’approccio sopra descritto risponde a tale indicazione, combinando strumenti automatizzati con test manuali assistiti.

Risultati dell’Audit Tecnico (WCAG 2.1 Livello AA)

Di seguito sono riportati i principali riscontri emersi confrontando il sito studionutrizionezanghi.it con i requisiti di accessibilità WCAG 2.1 livello AA (corrispondenti ai requisiti della norma EN 301 549 per i siti web). Vengono evidenziati sia gli aspetti conformi che, soprattutto, le criticità riscontrate (non conformità), organizzate per categorie di requisiti:

• Testi Alternativi per Immagini (WCAG 1.1.1): Il sito utilizza diverse immagini (fotografie della nutrizionista, immagini decorative nel layout, e immagini in articoli di ricette e nutrizione). È risultato che alcune immagini non possiedono un attributo alt testuale appropriato. In particolare, immagini puramente decorative (ad esempio grafiche di sfondo) dovrebbero avere alt vuoto (alt="") per essere ignorate dai lettori di schermo, mentre immagini informative (es. foto della Dott.ssa Zanghì o illustrazioni negli articoli) dovrebbero avere una descrizione significativa. Abbiamo riscontrato casi di alt mancanti o non descrittivi (ad es. nomi di file come “foto1.jpg” annunciati dal screen reader al posto di una descrizione) che costituiscono una violazione del requisito di testi alternativi. Impatto: Utenti non vedenti o con disabilità visive non ricevono l’informazione veicolata dall’immagine, perdendo contenuto o contesto importante.
• Contrasto dei Colori (WCAG 1.4.3): La palette cromatica del sito (colori principali: blu/grigio #6786a1, grigio scuro #333, grigio chiaro #aaa, sfondo crema #ede3a8, sfondo bianco #fff) è stata verificata per assicurare un contrasto sufficiente tra testo in primo piano e colore di sfondo. È emerso che alcuni accostamenti di colore non raggiungono il contrasto minimo di 4.5:1 richiesto per testo di dimensioni normali. Ad esempio, il testo grigio chiaro (#aaaaaa) su sfondo bianco ha un contrasto di circa 2.3:1, ben al di sotto dello standard【26†】. Anche il testo color blu/grigio #6786a1 su sfondo bianco (contrast ~3.8:1) non soddisfa il criterio AA per testo piccolo. Questo significa che utenti con basse visioni o daltonismo potrebbero faticare a leggere tali testi. Impatto: Difficoltà di lettura per utenti con disabilità visive moderate; il sito risulta meno fruibile in condizioni di luce sfavorevoli o su schermi poco luminosi.
• Struttura delle Intestazioni e Contenuti Semantici (WCAG 1.3.1, 2.4.6): L’organizzazione dei contenuti mediante titoli (heading) e sezioni è stata analizzata su diverse pagine (Home, Chi Siamo, Servizi, Articoli del blog, Contatti, ecc.). In generale, ogni pagina dovrebbe avere un unico titolo di livello 1 (H1) descrittivo, e sottosezioni ordinate gerarchicamente con <h2>, <h3> etc, senza salti ingiustificati di livello. Abbiamo riscontrato alcuni problemi di gerarchia delle intestazioni non ottimale: ad esempio, nella homepage il nome dello studio potrebbe essere marcato come H1 e i titoli delle sezioni successive come H2, ma in certe pagine si passa da un H1 direttamente a un H3 saltando l’H2, oppure si utilizzano dimensioni visive grandi per testi che però nel codice non sono marcati come intestazioni. Ciò compromette la navigazione tramite intestazioni per gli screen reader (che spesso forniscono agli utenti un elenco di heading disponibili). Inoltre, è stato notato che non sempre vengono utilizzati tag semantici HTML5 (<header>, <nav>, <main>, <footer>): ad esempio, la sezione principale potrebbe non essere racchiusa in un <main> (o in alternativa manca un ruolo ARIA main), e il menu di navigazione non avere un landmark ARIA esplicito. L’assenza di questi landmark semantici rende meno agevole la comprensione della struttura della pagina per chi naviga tramite tecnologie assistive. Impatto: Utenti con screen reader potrebbero orientarsi con maggior difficoltà nella pagina, non potendo sfruttare appieno le scorciatoie di navigazione strutturale (per saltare al contenuto principale, saltare al menu, etc.).
• Moduli e Form (WCAG 1.3.1, 3.3.2): Il sito include moduli di contatto e iscrizione (ad esempio una form “Contatti” con campi Nome, Email, Messaggio, e un eventuale campo per prenotare consulenze). Si è verificata la presenza di etichette testuali associate a ciascun campo di input. È emerso che, in alcuni casi, le etichette non erano collegate correttamente ai campi tramite l’attributo for/id, oppure venivano usati placeholder come sostituti delle etichette. Ogni campo dovrebbe avere un’etichetta chiara (visibile o nascosta via aria-label/aria-labelledby) in modo che lo screen reader annunci lo scopo del campo. Qualora vi fossero campi obbligatori, bisogna assicurare che ciò sia comunicato (ad es. con aria-required="true" o indicazioni nel testo). Un altro aspetto verificato è la gestione degli errori nei moduli: se un utente invia il form con errori (campi mancanti o formato email errato), i messaggi di errore sono facilmente individuabili e leggibili dallo screen reader? In assenza di messaggi di errore adeguatamente collegati ai campi (es. tramite aria-describedby), un utente non vedente potrebbe non capire come correggere l’errore. Impatto: Utenti con disabilità visive o cognitive potrebbero non riuscire a compilare correttamente il form, ostacolando la possibilità di contattare lo studio.
• Navigazione da Tastiera e Focus (WCAG 2.1.1, 2.4.7): Dalla prova pratica è risultato che tutte le funzionalità principali del sito sono accessibili via tastiera, ma con alcune riserve. In particolare: il menu di navigazione principale in cima alla pagina è raggiungibile premendo Tab, tuttavia non è stato trovato un link “Salta al contenuto” (skip link) visibile al primo focus. Un link di salto è raccomandato (e per i siti pubblici obbligatorio) per permettere agli utenti che usano la tastiera di bypassare i menù ripetitivi e saltare direttamente al contenuto principale della pagina. La mancanza di tale funzione significa che, ad esempio, per raggiungere il contenuto di una pagina interna occorre tabulare attraverso tutti gli elementi di menu ogni volta. Inoltre, è stato riscontrato che il focus indicator è presente ma poco visibile in alcune sezioni: il tema grafico evidenzia il link attivo con un leggero cambio di colore (ad esempio un bordo azzurrino su sfondo crema) che potrebbe non essere sufficiente contrastato per utenti con vista limitata. Si raccomanda di assicurare un evidente outline o stile di focus su elementi attivi, conforme al criterio 2.4.7 (Focus Visibile). Infine, durante la navigazione è emerso che elementi come il footer (contenente i contatti e link ai social) sono accessibili da tastiera, ma le icone sociali (es. Facebook, Instagram) non hanno testi alternativi o etichette ARIA descrittive: lo screen reader annuncia solo “link, Facebook” se l’icona contiene il nome nell’URL o null’altro. Sarebbe opportuno fornire aria-label tipo aria-label="Visita la nostra pagina Facebook" per maggiore chiarezza.
• Compatibilità con Screen Reader (WCAG 4.1.2): In generale, il sito è navigabile con screen reader, ma i problemi sopra elencati (mancanza di alt testuali, struttura di heading subottimale, etichette form incomplete) incidono sulla qualità dell’esperienza. Ad esempio, navigando con NVDA in modalità “browse”, la pagina di Chi sono è risultata intellegibile, ma in alcuni punti NVDA ha letto elementi di formattazione non desiderati (forse a causa di contenuto copiato con simboli non testuali) e ha annunciato troppi “graphic” dovuti a immagini decorative prive di alt vuoto. Sul blog, l’elenco degli articoli appare come una serie di link con i titoli, che lo screen reader interpreta correttamente; tuttavia, sarebbe utile se i titoli dei post fossero marcati come intestazioni (<h2> per esempio) per permettere all’utente di scorrere rapidamente da un articolo all’altro con i comandi del lettore di schermo. Non sono stati riscontrati elementi dinamici complessi (come carousel, popup modali o menu a espansione) sul sito – a parte l’eventuale menù mobile “hamburger” che, se presente, va verificato attentamente. Se presente, occorre garantire che venga annunciato come “menu” e che i controlli di apertura/chiusura siano accessibili (ad es. pulsante con aria-label “apri menu”). In sintesi, alcuni elementi ARIA risultano mancanti dove sarebbero opportuni (es. role="navigation" per il nav principale, o landmark ARIA come main, banner, contentinfo), e alcuni attributi andrebbero corretti (ad esempio, assicurarsi che l’attributo lang nel codice HTML sia impostato a lang="it" per la lingua italiana della pagina). Queste accortezze rientrano nei requisiti di robustezza del contenuto (Principio Robust delle WCAG), garantendo compatibilità con le tecnologie assistive presenti e future.

Aree di Non Conformità Identificate

Confrontando i risultati dell’analisi con i requisiti di legge, si individuano le seguenti principali aree di non conformitàdel sito rispetto alle WCAG 2.1 livello AA e alle prescrizioni del D.Lgs. 82/2022:

1. Testi alternativi mancanti o non adeguati: Alcune immagini non hanno alternative testuali significative, in violazione del criterio WCAG 1.1.1 (Equivalente testuale). Ad esempio, il logo dello studio e alcune foto decorative risultano privi di alt text (o con alt generico). Requisito normativo: fornire sempre un testo alternativo per immagini informative, oppure marcare come decorative quelle non informative.
2. Insufficiente contrasto cromatico: Diversi elementi testuali non rispettano il contrasto minimo (rapporto 4.5:1) richiesto da WCAG 1.4.3. In particolare, testi grigio chiaro su bianco e testi colorati su sfondo chiaro risultano di difficile lettura per utenti ipovedenti. Requisito normativo: garantire contrasto adeguato per tutti i testi (o fornire meccanismi di selezione di contrasto elevato).
3. Mancanza di meccanismi di salto e navigazione rapida: Il sito non offre un link “Salta al contenuto” né altre modalità di bypassare contenuti ripetitivi, richiesti dal criterio WCAG 2.4.1 (Bypass dei blocchi). Inoltre, la struttura di intestazioni non uniforme rende difficile la navigazione da parte di screen reader. Requisito normativo:prevedere sistemi per saltare direttamente al contenuto principale e strutturare le pagine con intestazioni gerarchiche corrette.
4. Problemi di navigazione da tastiera: Alcuni elementi non sono facilmente utilizzabili solo con la tastiera – ad esempio, focus poco visibile, o potenziali elementi attivabili solo al passaggio del mouse. Sebbene tutto il contenuto sia raggiungibile, l’esperienza da tastiera è sub-ottimale in violazione di WCAG 2.1.1/2.4.7 (Focus visibile). Requisito normativo: assicurare che ogni funzionalità sia operabile tramite tastiera e che il focus sia sempre evidente.
5. Etichette di modulo non associate: Nei form di contatto non tutte le etichette sono correttamente legate ai rispettivi campi tramite attributi for/id, e alcune indicazioni (es. form di ricerca o iscrizione newsletter, se presenti) mancano di label testuale. Questo non rispetta WCAG 3.3.2 (Etichette o istruzioni). Requisito normativo: fornire etichette chiare e programmaticamente associate per ogni campo modulo.
6. Assenza di dichiarazione di accessibilità sul sito: Al momento dell’audit, il sito non presenta una Dichiarazione di Accessibilità pubblicata, obbligatoria per i soggetti rientranti nel campo di applicazione della normativa (es. privati che offrono servizi al pubblico ai sensi del D.Lgs. 82/2022). La mancanza di tale dichiarazione comporta non conformità al Decreto 82/2022 e alle Linee Guida AgID, che impongono ai soggetti obbligati di pubblicare entro il 23 settembre di ogni anno un’auto-dichiarazione aggiornata sullo stato di accessibilità del sito. Requisito normativo: pubblicare sul sito la Dichiarazione di Accessibilità secondo il modello AgID, contenente lo stato di conformità, i contenuti non accessibili e i riferimenti di contatto per segnalazioni.

Oltre a queste, sono emerse alcune non conformità minori (es.: codice HTML con errori di validazione che però non impattano direttamente l’accessibilità, descrizioni estese mancanti per alcuni link che aprono PDF esterni, ecc.), che andrebbero comunque corrette per ottemperare pienamente alle WCAG 2.1 e migliorare l’usabilità complessiva.

Nota sulle esenzioni: Si segnala che, in base all’Art. 3 comma 3 del D.Lgs. 82/2022, le microimprese (meno di 10 dipendenti e fatturato annuo < 2 mln €) godono temporaneamente di una deroga sull’obbligo di conformità. Tuttavia, l’orientamento UE è di estendere gradualmente l’accessibilità a tutte le aziende. Indipendentemente dall’obbligo legale immediato, si raccomanda vivamente di risolvere le non conformità sopra descritte: infatti l’accessibilità migliora l’esperienza di tutti gli utenti e previene possibili contenziosi o sanzioni (che in Italia possono arrivare fino a €40.000 in caso di inadempienza grave).

Raccomandazioni Tecniche e Correttive

Per ciascuna criticità identificata, si propongono di seguito interventi correttivi e suggerimenti pratici al fine di allineare il sito Studio Nutrizione Zanghì ai requisiti di legge e alle WCAG 2.1 AA:

• Testi alternativi per immagini: Rivedere tutte le immagini del sito e aggiungere attributi alt appropriati. In particolare:
  • Fornire una breve descrizione significativa per immagini che contengono informazioni (es. alt=”Maria Luisa Zanghì, biologa nutrizionista” sulla foto della nutrizionista nella pagina Chi sono).
  • Per icone o immagini decorative usate a scopo di layout o estetico, utilizzare alt vuoto (alt="") oppure via CSS come background, in modo che siano ignorate dai lettori di schermo.
  • Evitare testi alternativi ridondanti (ad es. non ripetere nel alt ciò che è già scritto accanto all’immagine; usare alt brevi ma descrittivi).
• Contrasto colore: Adeguare la palette grafica per migliorare il contrasto:
  • Scurire il colore del testo grigio chiaro (es. #777 invece di #aaa) o usarlo solo su sfondi scuri. In alternativa, cambiare lo sfondo bianco in una tonalità più scura quando viene usato testo chiaro sopra.
  • Per il testo blu/grigio (#6786a1) su bianco, aumentare leggermente la saturazione o la oscurità del colore finché il contrasto non raggiunge almeno 4.5:1, oppure usarlo solo per titoli grandi (corpo >18pt) che tollerano contrasto minore (3:1) secondo WCAG.
  • Verificare con strumenti come Contrast Checker ogni variazione di stile, puntando a rispettare sempre il rapporto 4.5:1 per testi normali e 3:1 per testi grandi o elementi grafici essenziali.
  • In sezione di stile personalizzato CSS, evitare di usare testo #aaa su sfondo #fff per paragrafi o placeholder; preferire #555 o #333 per il testo secondario su bianco, ad esempio.
• Struttura di pagina e intestazioni: Migliorare la semantica e la struttura:
  • Assicurarsi che ogni pagina abbia un tag <h1> unico e significativo (es. il titolo “Nutrizionista a Roma – Maria Luisa Zanghì” in home page). I sottotitoli o slogan possono essere <h2> o <h3> in modo coerente.
  • Riorganizzare i livelli di heading in ordine gerarchico senza saltare livelli. Se lo stile visuale richiede un certo aspetto, utilizzare CSS per modificarlo ma mantenere l’ordine logico nell’HTML.
  • Utilizzare i landmark ARIA/HTML5: ad esempio avvolgere il menu principale in un <nav role="navigation">, il contenuto principale in <main> (o role="main"), il footer in <footer role="contentinfo">. Questo aiuta i navigatori screen reader a saltare direttamente alle sezioni principali (es. NVDA ha la funzione “landmarks list”).
  • Inserire un link di “Salta al contenuto” come primo elemento focussabile nella pagina (ad es. <a class="skip-link" href="#main">Salta al contenuto principale</a> visibile solo al focus). Questo implementa il criterio 2.4.1 e facilita la vita agli utenti da tastiera.
  • Nel codice, impostare l’attributo di lingua principale del sito: <html lang="it"> per l’italiano. Questo consente ai screen reader di usare la pronuncia corretta per il testo in italiano.
• Form e controlli: Rendere i moduli pienamente accessibili:
  • Associare ogni campo di input con un elemento <label> esplicito. Ad esempio: <label for="nome">Nome</label><input id="nome" ...>. In caso di design minimalista, la label può essere nascosta via CSS ma deve essere presente nel DOM per essere letta dallo screen reader.
  • Fornire istruzioni chiare per la compilazione dove necessario (es. form di prenotazione: indicare il formato della data o altri requisiti).
  • Gestire gli errori: dopo l’invio del form, in caso di campi mancanti o errori, visualizzare messaggi testuali vicino ai campi e assicurarsi di usare aria-live o focus management per portare l’attenzione sul messaggio. Ad esempio: <div id="error-email" role="alert">Inserire un indirizzo email valido</div> e collegare il campo al messaggio con aria-describedby="error-email".
  • Verificare che i controlli siano utilizzabili da tastiera (bottoni, checkbox, eventuali menu a discesa). Evitare elementi non standard (es. <div> interattivi) a meno di gestirli con ARIA e JavaScript per ruoli e stati.
• Navigazione e interazione via tastiera:
  • Migliorare la visibilità del focus: utilizzare CSS per evidenziare chiaramente l’elemento attivo (ad esempio un bordo di spessore 2px con colore ad alto contrasto, oppure un background highlight). Non rimuovere l’outline di default senza prevedere un’alternativa visibile.
  • Testare la navigazione completa da tastiera dopo le modifiche, assicurandosi che non vi siano elementi non raggiungibili. Se alcuni widget richiedono il mouse (ad es. slider), prevedere alternative (pulsanti “Precedente/Successivo” accessibili da tastiera e screen reader).
  • Per menu a tendina o voci di menu con sotto-voci (se esistenti): implementare la navigazione tramite tasti freccia e assicurarsi che l’espansione sia annunciata (ad esempio utilizzare aria-haspopup="true" e aria-expanded per indicare lo stato dei menu espansi).
  • Rimuovere eventuali keyboard trap: se ad esempio un popup si apre (come la cookie policy o un modale), quando attivo dovrebbe catturare il focus al suo interno e restituirlo al trigger solo alla chiusura, ma permettendo sempre di uscire con un tasto (Es. Esc per chiudere modale).
• Compatibilità generale con screen reader:
  • Verificare con NVDA/JAWS dopo le modifiche che la lettura sequenziale della pagina sia fluida. Usare gli strumenti dei reader (lista link, lista intestazioni, lista landmark) per assicurarsi che ogni cosa abbia un nome comprensibile (link con nomi significativi, niente voci duplicate o vuote).
  • Dove necessario, aggiungere attributi ARIA per colmare lacune semantiche. Ad esempio, se c’è una sezione di testimonianze scorrevole non ovvia, aggiungere aria-label o titoli nascosti per contestualizzare (“Testimonianze di clienti”).
  • Evitare di utilizzare elementi che possono disturbare gli screen reader, come contenuto testuale nascosto non utile o aggiornamenti dinamici senza notifica. Se ad esempio c’è un banner che cambia (carousel), aggiungere controlli per fermarlo e aria-live="off" se non è critico.
• Dichiarazione di Accessibilità: Preparare e pubblicare sul sito una Dichiarazione di Accessibilità, in formato accessibile (preferibilmente pagina HTML dedicata, linkata dal footer del sito). Questa dichiarazione, conforme al modello AgID userway.it, deve riassumere:
  • Lo stato di conformità del sito (es. “parzialmente conforme” alle WCAG 2.1 AA),Gli eventuali contenuti non accessibili e i motivi (non conformità, deroghe, fuori campo),Le misure correttive pianificate e i tempi di adeguamento,Un meccanismo di feedback (email/telefono per segnalare problemi di accessibilità),Le informazioni previste dalla legge (come la data di pubblicazione del sito, esito dell’ultimo audit, ecc., vedi Linee Guida AgID).
  Si veda a tal proposito la sezione seguente, in cui viene fornita la Dichiarazione di Accessibilità proposta per il sito in esame.

L’adozione di queste misure correttive dovrebbe portare il sito Studio Nutrizione Zanghì in linea con i requisiti WCAG 2.1 AA, migliorando significativamente l’esperienza d’uso per utenti con disabilità. Si raccomanda inoltre di istituzionalizzare un processo di mantenimento dell’accessibilità: ad esempio, verifiche periodiche (almeno annuali, come richiesto dalla normativa) e formazione di chi aggiorna i contenuti, affinché nuovi articoli o funzionalità siano inseriti rispettando i principi di accessibilità fin dall’inizio. In vista della scadenza del 28 giugno 2025 fissata dall’Accessibility Act, agire tempestivamente su queste raccomandazioni consentirà di evitare il rischio di sanzioni e, soprattutto, di offrire un sito realmente fruibile a chiunque.

Considerazione delle Linee Guida AgID (Soggetti Privati)

Durante l’audit si sono seguite le “Linee guida sull’accessibilità degli strumenti informatici – per i soggetti erogatori di cui all’art. 3 comma 1-bis della Legge 4/2004” (AgID, 26/04/2022). Tali linee guida confermano che il riferimento tecnico per i siti web è la conformità alle WCAG 2.1 livello AA, equivalente al soddisfacimento dei punti pertinenti della norma europea EN 301 549. Le verifiche tecniche descritte in precedenza sono quindi allineate ai requisiti elencati nel Prospetto A.1 delle norme citate.

Le Linee Guida AgID forniscono inoltre il modello ufficiale per la dichiarazione di accessibilità (Allegato 1) e indicazioni operative sulla pubblicazione e aggiornamento di tale dichiarazione. Abbiamo tenuto conto di queste indicazioni nella predisposizione della Dichiarazione di Accessibilità per il sito studionutrizionezanghi.it. In particolare, la dichiarazione seguente è redatta in lingua italiana e in formato conforme alle prescrizioni AgID per i privati, includendo lo stato di conformità, le non conformità riscontrate, le misure già adottate e i piani di adeguamento, nonché i riferimenti di contatto per feedback e le modalità di segnalazione previste.