Notizie

Progetti attivi

Ultimo aggiornamento: 31 ottobre 2026

In corso

v3: Una suite completa di controllo qualità

27 settembre 2026

Presentazione alla DrupalCon Europe 2026

Principali novità

• Nucleo di test unificato con Sa11y. Il nuovo set di regole, sviluppato insieme, aggiunge test per sviluppatori, controllo del contrasto e punteggio di leggibilità al set di regole di base per i contenuti.
• Supporto per più lingue
• Strumento per la creazione di test personalizzati
• Strumenti di manutenzione della dashboard
• Uno strumento di scansione del sito per aggiungere nuovi risultati.
• Consente a determinati test (questo PDF è accessibile?) di escludere gli avvisi a livello di sito per determinati ruoli.
• Configurazione separata: test e viste dei report distinti in base al ruolo, per sviluppatori ed editor di contenuti.

E forse, cosa ancora più importante per il futuro del progetto:

• Ottenuta una sovvenzione per avviare questa organizzazione sostenitrice, che potrà supportare gli utenti esistenti e finanziare il lavoro sulle idee per i progetti futuri.

v2: Esclusioni e report

2 marzo 2023

Due anni fa abbiamo presentato lo strumento di verifica dell'accessibilità Editoria11y, un plugin per Drupal pronto all'uso che offre agli autori un riscontro automatico e immediato, con consigli utili per migliorare i loro contenuti.

Pensavamo che avrebbe risposto a un'esigenza ancora insoddisfatta. Tutte le opzioni esistenti richiedevano formazione e un uso diligente per risultare utili, e l'esperienza ci aveva insegnato che formare e monitorare migliaia di autori di contenuti in una grande organizzazione non era un modo efficiente di affrontare il problema. Eravamo convinti che, per avere successo, un programma dovesse essere altamente automatizzato e offrire agli autori una cortese “formazione al momento giusto” ogni volta che rilevava un errore comune.

Ha funzionato.

A Princeton ha in gran parte invertito la direzione delle mie comunicazioni. Sulle piattaforme in cui era installato, siamo passati dall'inviare email ripetitive agli autori di contenuti per chiedere testo alternativo o miglioramenti a collegamenti e titoli, al ricevere domande dagli autori su come migliorare la propria scrittura per non ricevere così tante segnalazioni.

All'esterno, la reazione è stata di euforia:

Scrivere suggerimenti autonomi

Per i suggerimenti della v1 abbiamo adottato un approccio “riepilogo e dettagli”: una breve spiegazione del problema e un collegamento per maggiori dettagli.

Era un passo avanti rispetto agli strumenti scritti per gli sviluppatori: i suggerimenti erano brevi e chiari. Ma decidere dove far puntare il collegamento è sempre stato un problema. Diversi utenti della pubblica amministrazione e dell'istruzione superiore hanno sentito il bisogno di modificare i suggerimenti per togliere i collegamenti alla documentazione di Princeton, il che significava per loro lavoro in più. Così abbiamo riscritto i suggerimenti predefiniti rendendoli autonomi, con esempi direttamente nel testo.

La distinzione tra avvisi rossi (problemi certi) e avvisi gialli (possibili problemi) si è rivelata fonte di confusione e, a volte, di fastidio.

Abbiamo quindi trasformato gli avvisi gialli in “controlli manuali” per chiarirne il significato, e aggiunto pulsanti che consentono agli autori di nascondere gli avvisi. Gli avvisi “ignorati” vengono nascosti solo per la persona che ha fatto clic; quelli “contrassegnati come OK” vengono nascosti per tutti gli editor del sito. Gli amministratori del sito possono scegliere chi ha il permesso di fare l'una o l'altra cosa.

Creare una dashboard

I proprietari dei siti lamentavano spesso che lo strumento era bravissimo a trovare problemi in tutto il sito, ma non c'era modo di consultare un report a livello di sito.

La riscrittura aggiunge un'opzione per sincronizzare i risultati con il database del sito. Ora i proprietari dei siti possono sfogliare i risultati per pagina o per problema, vedere quali problemi sono stati ignorati o contrassegnati come OK e ripristinarli se non sono d'accordo!

Tour del codice della v2 per sviluppatori

La v2 è stata una riscrittura quasi completa. Tra le nuove funzionalità:

• L'eliminazione della dipendenza da jQuery ne consente l'installazione su più piattaforme e raddoppia le prestazioni.
• Lo strumento di verifica può ora essere configurato per esaminare più parti indipendenti della pagina (ad esempio, il contenuto dell'articolo e il piè di pagina).
• Lo strumento di verifica può ora testare gli elementi all'interno dello shadow DOM, usato da vari Web component e librerie JavaScript.
• Molti nuovi parametri facilitano le integrazioni con le piattaforme, ad esempio ignorando automaticamente tutti i problemi su determinate pagine per determinati utenti, se non sono responsabili dei contenuti di quella pagina ma potrebbero comunque voler visualizzare i risultati su richiesta.
• Lo strumento di verifica include ora più temi di base e parametri per personalizzare i colori.
• I test automatizzati aiutano a prevenire le regressioni del codice.

A11yTalks 2024

11 giugno 2024

Drupal GovCon 2023

27 ottobre 2023

DrupalCamp NJ 2023

28 marzo 2023

v1: Aiuto contestuale

11 marzo 2021

Creare contenuti Web altamente accessibili è complicato, e di solito si comincia con molta formazione.

Bisogna scoraggiare pratiche familiari:

• Le tabelle non vanno usate per creare false colonne
• Il testo corrente non va centrato né giustificato
• Non ci si deve affidare alla sola formattazione visiva (spessore e dimensione del carattere) per trasmettere significato agli utenti, che potrebbero ascoltare il contenuto o visualizzarlo in “modalità lettura”

Bisogna incoraggiare pratiche nuove:

• Le immagini hanno bisogno di un testo alternativo significativo nel contesto
• Le pagine hanno bisogno di una vera struttura
• I collegamenti devono avere titoli significativi

Certo, una parte della nostra formazione nasce dal fatto che stiamo insegnando concetti nuovi, ma a un certo punto bisogna chiedersi: quanto del bisogno di nuove competenze deriva dalla novità dei concetti, e quanto dal fatto che introduciamo nuove aspettative senza aggiornare i nostri strumenti? Il fatto che qualcosa sia nuovo non significa che non possa essere intuitivo.

Lezioni dalla storia dell'ortografia

Fase 1: La colpa è dell'autore

Dagli albori della storia scritta fino ai primi anni Ottanta, quando una parola era scritta male la colpa era dell'autore. Spettava a lui imparare a scrivere correttamente.

Come si migliorava la propria ortografia? La risposta suonerà familiare:

1. Si seguivano corsi, con un precettore o in classe
2. Si ricevevano elenchi, linee guida e dizionari da studiare, una tradizione che risale agli antichi lessici cuneiformi incisi nell'argilla.

Fase 2: La colpa è del dizionario

Ma negli anni Ottanta qualcosa è cambiato: chiamiamola “fase 2 dell'ortografia”. I programmi di videoscrittura più diffusi hanno introdotto il controllo ortografico.

E che ne è stato del gioco delle colpe? Quasi dall'oggi al domani, la colpa è passata allo strumento:

• Non sai come si scrive una parola? Provi a indovinare e speri che ci sia una corrispondenza. Se non c'è, la colpa è del dizionario.
• Usi una parola che esiste, ma il dizionario la segnala perché non la conosce? Brontoli e decidi se ignorare la sottolineatura o fare clic con il tasto destro e aggiungerla al dizionario.

Il controllo ortografico ha risolto tutti i nostri errori? Certo che no. Ma è stato d'aiuto. E ha spostato gran parte del peso e della responsabilità dall'autore alla macchina.

Ma non era finita qui…

Fase 3: La colpa è dello strumento di scrittura

Negli ultimi anni c'è stato un altro passo avanti: i computer hanno iniziato a scrivere al posto nostro:

• Gli algoritmi predittivi cercano di indovinare la parola successiva, la frase successiva, forse perfino un'intera risposta a un messaggio.
• Gli strumenti di formattazione automatica cercano di convertire asterischi, numeri e lettere in elenchi, codici brevi in caratteri speciali ed emoji, e così via.
• Gli strumenti di dettatura cercano di riconoscere i concetti per scegliere tra parole omofone.

E di chi è la colpa quando tutto va a rotoli? Dello strumento!

Gli aggregatori dei social media adorano l'imbarazzante screenshot “Non è quello che volevo dire!”.

Editoria11y è un passo verso la fase 2

Nella nostra formazione parliamo molto di test e presentiamo diversi strumenti di test piuttosto validi. Nessuno di questi può rilevare tutto: concetti come “evitare di spiegare i concetti tramite riferimenti cromatici o spaziali” devono essere verificati da una persona; in genere gli strumenti rilevano poco meno della metà dei problemi effettivi di un sito. Ma sono molto bravi a individuare numerosi errori comuni nei contenuti redazionali.

Ci sono però tre problemi:

1. La maggior parte sono strumenti manuali. Chi crea i contenuti deve aver imparato a usarli, deve ricordarsi che esistono mentre scrive e deve ricordarsi di eseguirli quando ha finito. Questi tre punti deboli congiurano per lasciare senza verifica gran parte (la maggior parte?) dei contenuti.
2. Segnalano troppe cose. Non si limitano agli errori appena commessi dall'autore: segnalano anche i problemi di colore introdotti dal designer, i problemi tecnici introdotti dallo sviluppatore, gli elementi strutturali a scopo informativo e così via. Questo alza l'asticella della formazione: gli autori non devono solo capire lo strumento, ma anche imparare a ignorare un elenco di falsi positivi o di problemi verissimi che però non spetta a loro risolvere oggi, mentre scrivono proprio questo articolo.
3. Gli strumenti automatizzati tendono a seguire il paradigma “scansiona il sito, visita la dashboard”. Ancora una volta, si presume che l'autore sia stato formato a visitare la dashboard e che si ricordi di farlo.

Princeton si è quindi proposta di creare qualcosa di nuovo: uno strumento di verifica automatico, integrato nel sito web, che si occupasse solo degli errori redazionali più comuni.

Automatico è… difficile.

1. Gli strumenti di verifica automatici devono essere discreti: se sono troppo insistenti, interrompono e frustrano l'autore. Se sono troppo educati, diventano un rumore di fondo facile da ignorare.
2. Gli strumenti di verifica automatici devono essere molto performanti: se la pagina sussulta o esita durante l'esecuzione, gli autori ne detesteranno la presenza e li disattiveranno.
3. Gli strumenti di verifica automatici hanno bisogno di suggerimenti adatti ai principianti. Per molti autori sarà la prima volta che sentono parlare dei tag, della struttura e del linguaggio che renderanno i loro contenuti più accessibili. Gli avvisi devono usare un linguaggio semplice e non tecnico, con consigli pratici per migliorare il contenuto.

Siamo quindi partiti dallo strumento più vicino a questi obiettivi che siamo riusciti a trovare: Sa11y, nato alla Toronto Metropolitan University. Abbiamo ripreso la sua architettura di test e il suo approccio intuitivo, con un pannello informativo e tooltip, e abbiamo dedicato sei mesi ad adattarlo perché i test venissero sempre eseguiti automaticamente, ottimizzandone le prestazioni, perfezionando i tooltip e creando un lungo elenco di opzioni di configurazione con cui gli sviluppatori potessero adattarlo rapidamente a qualsiasi piattaforma.

Ecco come appare oggi:

Quando un autore ha effettuato l'accesso al proprio sito, il pulsante di Editoria11y indica il numero e il tipo di problemi (nessun problema, controlli manuali necessari, probabili problemi rilevati) in ogni pagina. Facendo clic, l'autore può visualizzare evidenziazioni e suggerimenti direttamente nel testo. Se l'errore è nuovo, perché sta guardando una pagina appena modificata, il pannello si apre automaticamente.

A marzo 2021, questo significa che oltre 400 siti web di Princeton controllano automaticamente:

• Una buona struttura del documento
  • Livelli di titolo saltati
  • Titoli vuoti
  • Titoli molto lunghi
  • Citazioni sospettosamente brevi che potrebbero in realtà essere titoli.
• Alternative testuali
  • Immagini senza testo alternativo
  • Immagini con un nome di file come testo alternativo
  • Immagini con un testo alternativo molto lungo
  • Testo alternativo che contiene parole ridondanti come “immagine di” o “foto di”
  • Immagini in collegamenti il cui testo alternativo sembra descrivere l'immagine anziché la destinazione del collegamento
  • Visualizzazioni incorporate che di solito richiedono un'alternativa testuale
• Collegamenti significativi
  • Collegamenti senza testo
  • Collegamenti con un nome di file come titolo
  • Collegamenti con un titolo solo generico: “fai clic qui”, “scopri di più”, “scarica” e così via
  • Collegamenti che si aprono in una nuova finestra senza un'icona di collegamento esterno
• Controllo qualità generale
  • Verifica che venga usata la formattazione degli elenchi anziché asterischi, numeri e lettere
  • GRANDI QUANTITÀ DI TESTO TUTTO IN MAIUSCOLO
  • Tabelle senza intestazioni e tabelle con titoli del documento (“Titolo 3”) anziché intestazioni di tabella (<th>)
  • Collegamenti a PDF e altri documenti, con un promemoria per verificare l'accessibilità del file scaricabile o fornire un formato alternativo accessibile
  • Video incorporati, con un promemoria per aggiungere i sottotitoli
  • Audio incorporati, con un promemoria per fornire una trascrizione
  • Contenuti incorporati dai social media, con un promemoria per fornire gli elementi alt

Abbiamo rilasciato la libreria JavaScript alla comunità, creato un'integrazione per Drupal pronta all'uso e iniziato a lavorare a un'integrazione per WordPress pronta all'uso.

Verso la fase 3: Accessibile per impostazione predefinita

Per molti versi, Editoria11y è una soluzione tampone. La maggior parte degli errori che rileva nasce dal fatto che abbiamo imposto nuove aspettative agli autori di contenuti (“struttura bene i tuoi contenuti con i tag”), dando loro però strumenti che incoraggiavano il contrario.

La strada da seguire è rendere la creazione di contenuti accessibili più semplice e il più automatica possibile. Come si traduca in pratica non è ancora chiaro, ma probabilmente include cose come:

• Ripensare quali opzioni sono disponibili. Ad esempio: se continuiamo a dire agli utenti di non giustificare il testo sul Web, non è ora di ritirare quel pulsante “Giustifica”?
• Ripensare le opzioni predefinite. Ad esempio: la tabella predefinita nella maggior parte dei sistemi di gestione dei contenuti non ha intestazioni. Spetta all'utente sapere di dover fare clic su “Proprietà” e aggiungere le funzionalità di accessibilità; forse è ora di invertire le cose?
• Riflettere sulla formattazione predittiva e sui “suggerimenti mentre si lavora”. Se un utente mette in grassetto un'intera riga, possiamo suggerirgli di trasformarla in un titolo? Se un utente sta per selezionare un titolo, possiamo intuire quali livelli potrebbe volere anziché dargli sei opzioni? Possiamo offrire una formazione al momento giusto per i concetti difficili?