Sito web accessibile

1. Fornire alternative equivalenti al contenuto audio e visivo.
2. Non fare affidamento solo sul colore.
3. Usare marcatori e fogli di stile e farlo correttamente.
4. Identificare la lingua utilizzata.
5. Creare tabelle che si trasformino in maniera corretta.
6. Assicurarsi che le pagine con nuove tecnologie si trasformino correttamente.
7. Garantire all’utente il controllo sui cambi dei contenuti tempo-dipendente.
8. Assicurare l’accessibilità diretta delle interfacce utente incorporate.
9. Fare il design tenendo conto l’indipendenza del dispositivo.
10. Utilizzare soluzioni provvisorie.
11. Usare le tecnologie e le linee guida del W3C.
12. Fornire informazioni di contesto e orientamento.
13. Fornire meccanismi chiari di navigazione.
14. Assicurare che i documenti siano chiari e semplici.

Ogni linea guida contiene diversi punti di verifica che dovremo controllare per garantire l’accessibilità del sito web in sviluppo. Questi punti di controllo sono classificati in tre livelli di priorità secondo la loro importanza:

• Priorità 1 Sono quei punti che il sito deve rispettare perché, altrimenti, alcuni gruppi di utenti non potranno accedere alle informazioni del sito.
• Priorità 2 Sono quei punti che il sito dovrebbe rispettare perché, altrimenti, se non fossero così, sarebbe molto difficile accedere alle informazioni per determinati gruppi di utenti.
• Priorità 3 Sono quei punti che il sito deve rispettare perché altrimenti, alcuni utenti potrebbero sperimentare alcune difficoltà per accedere alle informazioni.

Per essere efficace nel verificare se il nostro sito è accessibile, è meglio cominciare con i punti più critici (priorità 1) di ciascuna delle quattordici linee guida e seguire poi i punti con priorità 2 e priorità 3. Per facilitare questo compito è spesso utilizzato un modello, dove si può spuntare le voci realizzate. È possibile scaricare un modello semplice dal W3C-WAI. Il W3C-WAI prevede inoltre tre livelli di conformità per permettere un facile smistamento dei siti web in base alla loro accessibilità:

• Livello di conformità “A”
  (A) si applica quando il sito soddisfa tutti i punti di controllo Priorità 1
• Livello di conformità “AA”
  (AA) si applica quando il sito soddisfa tutti i punti di controllo di priorità 1 e 2.
• Livello di conformità “AAA”
  (AAA) si applica quando il sito soddisfa tutti i punti di controllo di priorità 1, 2 e 3.

Se le pagine del tuo sito web seguono queste linee guida per l’accessibilità, è possibile inserire il loro logo, che indica la conformità della pagina per il livello di adeguatezza. I loghi possono essere scaricati direttamente dal WCAG 1.0 da questa pagina. Questi loghi permettono di vedere facilmente il livello di accessibilità di ogni sito. È responsabilità dello sviluppatore mettete nel vostro sito web se lo ritiene sia necessario giacché non è possibile chiederlo al W3C, né ci sono verifiche da fare. Tuttavia, per uno sviluppatore web, la posizione di questi loghi porta grande responsabilità nel mantenere i contenuti accessibili. In cambio, porta anche molti vantaggi per l’utente finale e aumenta il numero potenziale di utenti che possono accedere al nostro sito.

• Principi: a un primo livello ci sono 4 principi che sono i pilastri di accessibilità del web: il sito deve essere visibile, operabile, comprensibile e robusto.
• Linee guida: i principi sono divisi in 12 linee guida che definiscono gli obiettivi di base che gli autori dovrebbero soddisfare per garantire contenuti accessibili. Queste linee guida non sono verificabili, ma creare il quadro e gli obiettivi generali per aiutare a gli autori a comprendere i criteri di successo eimplementare meglio le tecniche, che comprendono i seguenti due strati.
  • Criteri di successo: per ogni modello, ci sono dei criteri di successo verificabili, che sono utilizzati anche per compiere test di conformità. Proprio come nelle WCAG 1.0, che distinguono tre livelli di conformità: bassa (A), medio (AA) e alta (AAA).
  • Tecniche di implementazione e consulenza: per ciascun criterio di successo ci sono 2 tipi di tecniche: quelle che sono necessarie per il rispetto del criterio e quelle che sono semplici consigli.

In linea con gli indirizzi dell’Unione europea, il 9 gennaio 2004 è stata emanata la cosiddetta “Legge Stanca” sull’accessibilità. Lo scopo della legge, in applicazione del principio costituzionale di eguaglianza, è quello di abbattere le “barriere virtuali” che limitano l’accesso dei disabili alla Società della Informazione e li escludono dal mondo del lavoro, dalla partecipazione democratica e da una migliore qualità della vita. La Legge Stanca, nei confronti della pubblica amministrazione, reca degli obblighi sorretti da efficaci sanzioni. Infatti prevede la nullità dei nuovi contratti stipulati dalla pubblica amministrazione per la realizzazione di siti Internet nel caso in cui non rispettino i requisiti di accessibilità, l’inosservanza delle disposizioni della legge da parte del pubblico amministratore comporta responsabilità dirigenziale e responsabilità disciplinare.
Simili alle WCAG 1.0, ogni esigenza ha una priorità stabilita. I requisiti di Priorità 1 sono di maggiore obbligo quando si esegue un Web accessibile. Per quelli di Priorità 2 è importante compierli per avere un adeguato livello di accessibilità, e per le Priorità 3 aiutano a migliorare l’accessibilità, pur non essenziale come i primi due. A seconda dei requisiti si stabiliscono due marchi, secondo lo standard, in grado di soddisfare il sito web:

• Marca AA: se si soddisfano i requisiti di priorità 1 e 2.
• Marca AAA: se si soddisfano i requisiti di priorità 1, 2 e 3.

1. I validatori automatici sono utilizzati per verificare automaticamente l’accessibilità di un sito, e può far emergere il 30% dei problemi di accessibilità.
2. In secondo luogo, è necessario controllare manualmente ogni punto di verifica, poiché molti punti non possono essere controllati automaticamente, com’è il caso con colori contrastanti, l’uso non corretto dello spazio della pagina, la dimensione del testo, immagini o testi lampeggianti o in movimento, ecc. Per i controlli manuali sono disponibili anche per altre applicazioni che possono essere utili, molti dei quali sono inclusi nella pagina Web del KAW.
3. Infine, si consiglia fare dei test con degli utenti disabili e diverse tecnologie di accesso.

Validare la sintassi e i fogli di stile. È essenziale che l’XHTML che genera il sito sia ben formato, in modo da garantire che qualsiasi dispositivo o browser, con capacità di interpretare XHTML, possa leggerlo in modo corretto. Attualmente, il W3C raccomanda eseguire lo schema XHTML 1.0 Strict, perché non permette di utilizzare i tags o gli attributi per controllare lo stile della pagina (font, i bordi, ecc.), poiché l’intero progetto dovrebbe essere risolto attraverso fogli di stile. Per verificare un corretto controllo della conformità con lo schema che la nostra pagina si ha un validatore W3C, chiamato Markup Validation Service. In sostanza, per fare in modo che il nostro codice sia XHTML 1.0. Strict, deve soddisfare le seguenti condizioni:

• Utilizzare solo elementi XHTML Strict. Ciò esclude gli elementi XHTML legate all’aspetto.
• Tutti gli elementi XHTML devono essere annidati correttamente.
• I tags XHTML devono essere sempre in minuscolo.
• Gli elementi XHTML devono essere chiusi sempre.

Allora come dare lo stile alle nostre pagine? La risposta è : da CSS. Il principale vantaggio di usare i CSS per modificare l’aspetto del sito è che permette a molti utenti di sostitui re il foglio di stile con il proprio, con grandi caratteri e contrasti di colore diverso, più accessibili a loro.

• Come strutturare le pagine
  Non molti anni fa, le pagine erano generate attraverso tabelle e spesso, porzioni di contenuti erano nidificate in tabelle all’interno di altre tabelle. Ciò ha causato che il contenuto al loro interno perdesse tutti i tipi di linearità quando uno screen reader (lettore di schermo) ci leggeva sopra. Per combattere questa cattiva pratica, l’XHTML ci offre degli strati e posizionamento tramite CSS. Un buon esempio di progettazione accessibile con CSS ce l’abbiamo sul sito web Zen Garden.
• Tabelle accessibli
  In tabelle di dati complesse, i lettori vocali non sono in grado di identificare quale intestazione corrisponde a ciascuna cella se gli sviluppatori non l’hanno indicato con il codice nella tabella. Tra le altre cose, le tabelle dovrebbero fornire riassunti, intestazioni, abbreviazioni e associazioni tra le celle e le loro voci corrispondenti.
• Forms accessibli
  Quando un’utente con uno screen reader è di fronte ad un form, ha bisogno di sapere cosa scrivere su ogni campo che ha davanti. Se non associamo il campo a un testo specifico, l’utente non potrà sapere se nel campo txt1 piuttosto che nel txt2 deve essere scritto, per esempio, il nome o il cognome.
• L’essenziale
  Se vogliamo garantire un sito web accessibile, dopo aver seguito le linee guida sull’accessibilità e portate a termine le convalide, si consiglia di controllare tre cose:
  • che le pagine abbiano una buona resa in diversi browser e diverse risoluzioni dello schermo,
  • provare con un lettore di schermo (come JAWS per esempio, frequentemente utilizzato dai non vedenti),
  • e portare le nostre pagine web su diversi dispositivi (PDA, cellulare, ecc).

Tuttavia, in un grande progetto non è possibile rivedere tutte le pagine. Di cosa si dovrebbe rispondere in modo essenziale perché il nostro sito web sia accessibile? Beh, si raccomanda che se il sito web è molto grande, scegliere un campione delle pagine più importanti e verificare quanto segue:

• Verificare che la pagina sia conforme allo schema XHTML 1.0 Strict (usare il W3C Markup Validation Service).
• Verificare che il CSS è conforme alle specifiche del CSS 2.1 (usare il CSS Validator del W3C) e verificare che quando si disattiva contenuto CSS lo mostri nel giusto ordine.
• Assicurarsi che le pagine siano accessibili a livello Doppia-A (Usare TAW o Hera, oltre ad una revisione manuale).
• Assicurarsi che le pagine di 800×600 e 1280×1024 si vedano bene almeno in IE 6.x, 7.x IE, Firefox 3.x.

Infine, è sempre consigliabile offrire un modulo di contatto nel sito Web (come un form mail, un’e-mail o il numero di telefono) agli utenti finali per farci comunicare i loro reclami o suggerimenti in materia di accessibilità del sito web.