Dichiarazione di accessibilità di Animiyo

Una piattaforma che conserva libretti sanitari, dosi, scadenze vaccinali e promemoria di terapia non può permettersi barriere. Chi si prende cura di un animale malato lo fa spesso in condizioni difficili: di fretta, con una mano occupata, su uno schermo piccolo, con la vista affaticata o in una stanza poco illuminata. Le stesse scelte che servono a una persona con disabilità permanente servono anche a chi si trova in una difficoltà temporanea o legata alla situazione del momento.

Questa dichiarazione riguarda il sito pubblico e l'applicazione web Next.js ospitati su Google Cloud Run e raggiungibili dal dominio della piattaforma. Non riguarda l'applicazione iOS nativa, che segue le linee guida di accessibilità del sistema operativo e sarà oggetto di una dichiarazione separata quando la valutazione sarà completata. Non riguarda i siti di terze parti eventualmente raggiunti dai collegamenti in uscita.

Il documento è scritto per essere utile, non per rassicurare. Dove una funzione manca lo diciamo, dove esiste un'alternativa la indichiamo, dove non c'è alcuna alternativa lo scriviamo senza giri di parole. Una dichiarazione di accessibilità che nasconde i propri limiti serve solo a chi la pubblica.

Il riferimento tecnico adottato sono le linee guida WCAG 2.2 di livello AA del World Wide Web Consortium. Sono il punto di arrivo comune sia della norma armonizzata europea sia della normativa italiana, quindi lavorare sui criteri WCAG significa lavorare contemporaneamente su tutti i quadri applicabili.

Le quattro fonti non sono alternative fra loro. Le WCAG forniscono i criteri verificabili, la EN 301 549 li inserisce nel quadro europeo, il decreto legislativo 82/2022 stabilisce l'obbligo per i servizi rivolti ai consumatori e la legge Stanca definisce il contesto nazionale e gli organi di vigilanza.

Animiyo dichiara una conformità parziale alle linee guida WCAG 2.2 di livello AA. Conformità parziale significa che una parte dei contenuti e delle funzioni soddisfa i criteri richiesti e una parte no. Non è una formula di cortesia: le parti non conformi sono quelle elencate nella sezione dedicata ai limiti noti, indicate una per una con il limite specifico e l'eventuale alternativa disponibile.

Lo stato dichiarato deriva da un'autovalutazione condotta dal titolare del progetto e conclusa il 2 agosto 2026. Non esiste una certificazione di terza parte, non è stato svolto un audit indipendente e non viene dichiarato alcun punteggio o percentuale di conformità.

• Che cosa è stato valutato: le pagine pubbliche del sito, i documenti legali, le pagine di contenuto editoriale e le schermate principali dell'applicazione web.
• Che cosa non è stato valutato: l'applicazione iOS nativa, i documenti caricati dagli utenti e dalle cliniche, i contenuti generati dagli utenti.
• Chi ha valutato: il titolare del progetto, senza l'intervento di un valutatore esterno.
• Quando: 2 agosto 2026.

La dichiarazione verrà aggiornata quando gli interventi pianificati saranno completati oppure quando una modifica sostanziale della piattaforma cambierà il quadro qui descritto. La versione del documento e la data di revisione sono indicate in testa alla pagina.

Le funzioni elencate qui sotto sono già attive nella piattaforma. Alcune sono sempre presenti e non richiedono alcuna azione, altre si attivano dalle impostazioni di aspetto e restano poi valide per le visite successive.

1. 1

   Apri le impostazioni di aspetto

   Le preferenze di aspetto raccolgono in un unico punto tema, contrasto, scala del testo, famiglia di caratteri e riduzione del movimento. Non serve modificare nulla nel browser o nel sistema operativo.

2. 2

   Scegli il tema e il livello di contrasto

   Il tema può essere chiaro, scuro oppure determinato dal sistema, così segue automaticamente l'impostazione del dispositivo. La modalità ad alto contrasto è indipendente dal tema e si attiva separatamente.

3. 3

   Regola la scala del testo e il carattere

   Le tre scale disponibili sono piccola, media e grande, e nessuna comporta perdita di contenuto o di funzionalità. La famiglia di caratteri si sceglie fra un carattere a bastoni neutro, un grottesco e un carattere con grazie.

4. 4

   Attiva la riduzione del movimento se ti serve

   Con la riduzione attiva le animazioni vengono ridotte al minimo. Le animazioni rispettano anche la preferenza di sistema prefers-reduced-motion, quindi chi l'ha già impostata a livello di sistema operativo non deve ripetere la scelta qui.

5. 5

   Verifica che la preferenza ti segua

   Le impostazioni sono salvate nella chiave animiyo.appearance dell'archiviazione locale del browser. Se hai un account e sei autenticato vengono salvate anche nel profilo, così seguono la persona fra dispositivi diversi e non restano legate a un solo browser.

Uno script in linea applica le preferenze prima del primo disegno della pagina. Serve a evitare lo sfarfallio dovuto al passaggio dal tema predefinito a quello scelto, che per molti è solo un difetto estetico ma per chi ha sensibilità alla luce è un disturbo reale.

I contenuti editoriali e i documenti legali di Animiyo non sono scritti in HTML grezzo. Sono composti da blocchi tipizzati: paragrafi, elenchi, tabelle, riquadri, passi e citazioni. Il renderer trasforma ogni blocco in marcatura semantica, sempre nello stesso modo.

• La gerarchia dei titoli è generata dal modello, quindi non ci sono salti di livello dovuti a una scelta tipografica di chi scrive.
• Le intestazioni di tabella sono dichiarate come tali e associate alle celle, quindi un lettore di schermo può annunciare a quale colonna appartiene un valore.
• Gli elenchi sono elenchi veri e non righe separate da simboli, quindi la tecnologia assistiva ne annuncia la lunghezza e la posizione corrente.
• I riquadri di rilievo portano un titolo e un tono dichiarati, quindi il significato non è affidato al solo colore.
• Non essendoci HTML grezzo nei file di contenuto non esistono marcature inventate caso per caso.

Ogni pagina di contenuto ha un indice delle sezioni con ancore stabili. L'indice permette di raggiungere una sezione senza scorrere tutto il documento, e le ancore non cambiano quando il testo viene aggiornato: un collegamento profondo condiviso con un'altra persona continua a funzionare anche dopo una revisione.

Questo modello riduce i difetti alla radice. Un difetto di accessibilità strutturale nasce quasi sempre da una scelta manuale sbagliata e ripetuta molte volte; spostando la struttura nel modello dei dati, l'errore diventa impossibile da commettere per chi scrive, perché il compilatore rifiuta un blocco malformato e il renderer produce sempre la stessa marcatura. Restano possibili gli errori di contenuto, per esempio un testo alternativo poco descrittivo, ma non gli errori di struttura.

Animiyo pubblica nove lingue: italiano, inglese, francese, spagnolo, tedesco, cinese semplificato, estone, russo e arabo. I codici usati nelle rotte sono it, en, fr, es, de, zh-Hans, et, ru e ar.

• L'arabo è reso con direzione del testo da destra a sinistra, con l'attributo dir impostato sull'elemento radice della pagina, quindi la direzione vale per l'intera interfaccia e non solo per i paragrafi.
• Ogni pagina dichiara la propria lingua, così la sintesi vocale di un lettore di schermo usa la pronuncia corretta invece di leggere un testo straniero con le regole della lingua sbagliata.
• Date e numeri seguono le convenzioni locali della lingua scelta, non un formato unico imposto a tutte le versioni.
• Gli hreflang elencano solo le versioni realmente tradotte: una pagina non tradotta non viene annunciata come disponibile in quella lingua.

La copertura linguistica è una questione di accessibilità prima ancora che di mercato: leggere istruzioni sanitarie in una lingua che non si padroneggia è una barriera come un contrasto insufficiente. Il limite attuale è la qualità della revisione, non la copertura: le traduzioni nelle lingue diverse da italiano e inglese non sono ancora state riviste da un revisore madrelingua per la chiarezza dei testi delle etichette.

La piattaforma è costruita per funzionare con le tecnologie assistive, ma le prove effettivamente svolte non coprono tutte le combinazioni possibili. Qui sotto è indicato che cosa è stato provato e che cosa no, perché senza questa distinzione una dichiarazione di compatibilità non ha valore pratico.

• Provato: navigazione con la sola tastiera sulle pagine pubbliche e sulle schermate principali dell'applicazione, verificando che l'indicatore di fuoco resti sempre visibile e che nessun elemento diventi irraggiungibile.
• Provato: ingrandimento del testo fino al duecento per cento, verificando che il contenuto resti leggibile e le funzioni utilizzabili.
• Provato: resa da destra a sinistra della versione araba, compresa la direzione degli elementi di navigazione.
• Provato: struttura dei titoli ed etichette dei moduli sulle pagine principali.
• Non provato in modo sistematico: le combinazioni di lettore di schermo, browser e sistema operativo. Le verifiche svolte sono state parziali e non coprono tutte le schermate.
• Non provato: comandi vocali, tastiere alternative e dispositivi di puntamento assistito.
• Non provato: i documenti PDF e le immagini caricati dagli utenti e dalle cliniche, che non passano da alcun controllo di accessibilità.

Dichiarare quali combinazioni non sono state provate fa parte della dichiarazione stessa. Senza questa informazione una persona non può sapere se il proprio strumento sia stato considerato, e scoprirlo sul campo significa perdere tempo su un servizio che gestisce scadenze sanitarie. Le prove con lettori di schermo su più combinazioni di sistema operativo e browser sono fra i miglioramenti pianificati.

Questi sono i limiti che conosciamo alla data della valutazione. Sono elencati per intero, con l'alternativa disponibile quando esiste e con la dichiarazione esplicita che non esiste quando manca.

Nessuno di questi limiti viene presentato come marginale. Le mappe delle passeggiate e i documenti caricati sono barriere concrete per chi usa un lettore di schermo, e finché non saranno risolte la conformità resta parziale.

La valutazione è un'autovalutazione condotta dal titolare del progetto. Non c'è certificazione di terza parte, non c'è audit indipendente e nessun soggetto esterno ha verificato le conclusioni riportate in questo documento.

1. Controlli automatici sulle pagine principali del sito e dell'applicazione web.
2. Prove manuali di navigazione condotte con la sola tastiera.
3. Verifica dei rapporti di contrasto fra testo e sfondo.
4. Prove con l'ingrandimento del testo fino al duecento per cento.
5. Controllo della struttura dei titoli e delle etichette dei moduli.
6. Verifica della resa da destra a sinistra nella versione araba.

Data della valutazione: 2 agosto 2026. I risultati si riferiscono alla versione della piattaforma pubblicata a quella data.

Un'autovalutazione ha un limite strutturale che va detto: chi ha costruito l'interfaccia è anche chi la giudica, conosce i percorsi che funzionano e tende a percorrerli. Per questa ragione la valutazione di un audit indipendente è fra i miglioramenti pianificati, prima dell'apertura al pubblico.

Se incontri una barriera puoi segnalarla dalla pagina Contatti del sito, al percorso /contatti. Ogni segnalazione è utile anche quando riguarda un limite già elencato in questo documento, perché aiuta a capire quanto pesa nell'uso reale.

1. 1

   Apri la pagina Contatti

   La pagina /contatti del sito apre un messaggio di posta elettronica con oggetto già pronto verso l'indirizzo indicato lì. Non esiste un modulo da compilare e non serve avere un account per scrivere.

2. 2

   Indica l'indirizzo della pagina

   Copia l'indirizzo completo della pagina in cui hai incontrato il problema. Senza l'indirizzo la verifica richiede molto più tempo e a volte non è possibile riprodurre la situazione.

3. 3

   Descrivi browser e tecnologia assistiva

   Indica quale browser e quale tecnologia assistiva stavi usando, con la versione se la conosci. La stessa pagina può comportarsi in modo diverso a seconda della combinazione, quindi questo dato è spesso decisivo.

4. 4

   Racconta che cosa non ha funzionato

   Spiega che cosa stavi cercando di fare e che cosa è successo invece. Se puoi, indica anche che cosa ti aspettavi che accadesse: la differenza fra atteso e ottenuto è l'informazione più utile.

Il riscontro arriva entro trenta giorni dalla segnalazione. Se la risposta non è soddisfacente oppure non arriva, in Italia è possibile presentare una segnalazione all'Agenzia per l'Italia digitale, che vigila sull'attuazione della normativa in materia di accessibilità. Per i servizi che rientrano nel decreto legislativo 82/2022 è possibile rivolgersi alle autorità di vigilanza designate. Resta in ogni caso salva la tutela giurisdizionale.

Gli interventi elencati qui sotto sono quelli decisi per superare i limiti dichiarati. Sono ordinati per priorità e riguardano tanto le funzioni quanto il metodo con cui l'accessibilità viene verificata.

Le priorità riflettono la gravità della barriera, non la facilità di realizzazione. In questo documento non viene promessa alcuna data di consegna: quando un intervento è completato la dichiarazione viene aggiornata, la versione cambia e la riga corrispondente esce dai limiti noti.