Nelle amministrazioni pubbliche e nelle grandi aziende troveremo sempre con il requisito obbligatorio che le applicazioni o siti web che sviluppiamo devono essere “accessibili“. In questo post cercherò di spiegare cosa implica l’accessibilità web e come viene realizzata.
Internet si sta introducendo sempre di più nelle nostre vite, visto il numero crescente di utenti e l’allargamento della gamma della loro età. Inoltre, molti disabili su Internet trovano una grande fonte d’informazioni e risorse. Tutti questi fattori fanno sì che avere un Web accessibile a tutti è qualcosa di veramente essenziale.
Le WAI del W3C

L’importanza di accessibilità del web per creare siti Web accessibili è un obbligo sociale e legale da tenere in mente sia dai content manager sia dagli sviluppatori, poiché quasi tutti gli utenti hanno in misura maggiore o minore dei problemi, quali la percezione e il movimento. Sebbene il tradizionale concetto di accessibilità del Web significasse che dovevamo rendere i nostri siti web pensati per le persone con disabilità o per gli anziani che la utilizzano, dobbiamo estenderlo anche al suo utilizzo nei dispositivi con visualizzazione limitata (ad esempio, piccoli schermi dei telefoni cellulari), o di tecnologia (mancanza di supporto per alcuni plug-in), o velocità (le vecchie linee telefoniche).
Come si vedrà in questo post, c’è una serie di linee guida che lo sviluppatore deve seguire per ottenere un sito Web accessibile a tutti. Per promuovere la Web Accessibility, W3C ha un gruppo di lavoro chiamato WAI. Questo gruppo ha pubblicato nel 1999 una serie di linee guida da seguire per raggiungere l’accessibilità dei contenuti Web noti come WCAG, versione 1.0. Nel dicembre 2008, ha rilasciato la seconda versione delle linee guida, WCAG 2.0, con un cambiamento radicale nell’organizzazione, ma che, tuttavia, continua con la stessa filosofia di offrire delle alternative per consentire l’accesso ai contenuti in modi diversi.
Le WCAG 1.0
Le WCAG 1.0 sono un insieme di quattordici linee guida sviluppate dal WAI per aiutare agli sviluppatori e ai content manager a rendere i siti Web accessibili. Queste linee guida sono le seguenti:

  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.

Le WCAG 2.0
Questa seconda versione delle WCAG, realizzata dal W3C-WAI, aggiorna le raccomandazioni sull’accessibilità. Al momento è difficile sapere come andrà a influenzare la legislazione attuale e agli sviluppatori in generale, perché la documentazione fornita da quest’organismo è molto ampia ed è ancora in fase di attuazione per evaluare la loro efficienza. Di seguito viene spiegato gli aspetti più importanti. La seconda versione delle WCAG è divisa in una serie di strati

  • 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.
Come convalidare l'accessibilità
La validazione dell’accessibilità si compone di 3 fasi:

  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.

Alcune regole
  • 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.

Similari
Marcatura HTML5
7% Html5
Anche se molte persone non hanno mai sentito parlare, l’XHTML è davvero il futuro di Internet. È l’ultima generazione di HTML, venuta dopo la versione 4, che ha molte nuove caratteristiche che lo avvicinano, in qualche mod…
Google svela le sue linee guida
7% Best Practices
Mi piace la navigazione attraverso le linee guida. Di solito ci sono delle regole ovvie, quelle che sembrano bizzarre e ci sono anche quelle gemme nascoste che non avevano scoperto prima. Purtroppo, poche aziende hanno il …
CSS consistente ed idiomatico
6% Css
Il seguente documento espone una ragionevole guida di stile per lo sviluppo in CSS. Esso non è inteso per essere un rigido regolamento e non voglio imporre le mie preferenze di stile sul codice degli altri. A parte tutto, …
Utilizzando il metodo data() di jQuery
6% JQuery
Ad un certo punto, tutti noi dobbiamo memorizzare qualche set di dati sul client. Possiamo memorizzare lo spazio dei nomi di variabili sempre in maggiore quantità evitando collisioni; possiamo memorizzare le variabili in q…
Alcuni Tag HTML5 che potrebbero servire
5% Html5
Come sviluppatore front-end senza dubbio si utilizza costantemente HTML e probabilmente ci sono poche incognite. Tuttavia, il modo in cui si è evoluto (in particolare con l’avvento di HTML5) può sorprendere, a volte. In qu…