Archivi tag: corso

Accessibilità web in Italia e nel mondo

Pubblicato il da

Questo articolo fa parte di un corso gratuito di accessibilità web ospitato su questo sito.

Garantire l’accessibilità web, lo abbiamo detto più volte, non è solo una questione di software. Non esistono strumenti totalmente automatici che verifichino le pagine e ne correggano tutti i problemi di accessibilità.

Le linee guida facilitano comunque la verifica e la correzione delle pagine da parte di tutte le figure professionali coinvolte nella costruzione di un sito accessibile.

Le più importanti linee guida oggi disponibili sono:

Altre linee guida sono state realizzate da aziende software, tra le quali ricordiamo le
Ibm Web Accessibility Checklist [nuova finestra]

Web Content Accessibility Guidelines

È uno dei tre tipi di linee guida rilasciati dalla Wai e si preoccupa di definire uno standard per la costruzione di pagine web che siano accessibili nella loro struttura e nel loro contenuto.

Le altre linee guida realizzate dal Wai sono:

Il documento è suddiviso in 14 linee guida, di cui riportiamo una libera traduzione in italiano:

  1. Fornire alternative equivalenti al contenuto audio e visivo
  2. Non fare affidamento sul solo colore
  3. Usare marcatori e fogli di stile e farlo in modo appropriato
  4. Evidenziare il passaggio da una lingua ad un’altra
  5. Creare tabelle che degradino in modo efficace
  6. Assicurarsi che le pagine con nuove tecnologie degradino in modo efficace
  7. Assicurarsi che l’utente possa tenere sotto controllo i cambiamenti di contenuto con il passare del tempo
  8. Assicurare che le interfacce di programmi incorporati mantengano alto il livello di accessibilità
  9. Progettare per garantire l’indipendenza da dispositivo
  10. Usare soluzioni ad interim
  11. Usare le tecnologie e le raccomandazioni del W3c
  12. Fornire informazioni per la contestualizzazione e l’orientamento
  13. Fornire chiari meccanismi di navigazione
  14. Assicurarsi che i documenti siano scritti in modo chiaro e semplice

Accanto alle linee guida, sono disponibili altri documenti Wai che ne approfondiscono l’uso:

Le linee guide sono suddivise in punti (checkpoint), a loro volta raggruppati in 3 categorie di priorità:

  • Priorità 1: l’adozione di questo punto deve essere garantita da tutti gli sviluppatori, pena l’inaccessibilità del documento
  • Priorità 2: l’adozione di questo punto dovrebbe essere garantita da tutti gli sviluppatori, pena difficoltà nell’accedere al documento
  • Priorità 3: l’adozione di questo punto è consigliata, poiché alcune tipologie di utenti potrebbero trovare difficoltà nell’accedere al documento

Il numero del checkpoint segue quello della linea guida ed è separato da un punto. 1.4, ad esempio, indica il checkpoint 4 della linea guida 1.

Le linee guida del W3c sono alla base della Section 508 e di quasi tutte le proposte per la realizzazione di documenti accessibili.

La critica che spesso viene rivolta a queste linee guida è che non sembra facile riuscire ad applicarle tutte insieme, cioé i checkpoint di livello 1,2 e 3.

In particolare, garantire una visualizzazione corretta ad un vasto pubblico, ma utilizzare i fogli di stile anche per il layout della pagina sono due esigenze all’oggi inconciliabili. Difficile quindi costruire un sito accattivante e con un buon numero di pagine che riesca a tenere conto di tutte le esigenze delle linee guida, anche se nel medio periodo la penetrazione dei browser versione 5+ non può che favorire questa situazione.

Le Wcag sono in fase di attenta revisione e per rendersene conto è possibile dare un’occhiata ad una proposta di riorganizzazione [nuova finestra].

Section 508

Sono state pubblicate dall’US Access Board nel 2000 e coprono diversi aspetti dell’accessibilità in ambito informatico, non solo nel web.

Tutti i siti creati o gestiti per conto del governo americano devono soddisfare i requisiti di queste linee guida.

Sono basate sulle Wcag 1.0 del W3c e ne presentiamo una libera traduzione in italiano:

  1. Per ogni elemento di testo deve essere previsto un equivalente testuale (usando “alt”, “longdesc”, ecc.)
  2. Il contenuto alternativo ad ogni presentazione multimediale deve essere sincronizzato con la presentazione
  3. Le pagine web devono essere progettate perché tutte le informazioni portate dal colore siano disponibili anche senza colore, per esempio dal contesto o dalla marcatura
  4. I documenti dovrebbero essere realizzati in modo da essere fruibili anche senza il foglio di stile associato
  5. È necessario includere link di testo ridondanti per ogni regione attiva di un’image map server-side
  6. Dopo possibile è necessario usare image map di tipo client-side invece di tipo server-side, a parte dove le regioni non possono essere definite come forma geometrica
  7. Devono essere identificate le colonne e le righe per le tabelle di dati
  8. È necessario usare la marcatura per associare le celle dei dati alle intestazioni delle celle nel caso la tabella contenga due o più livelli di intestazioni di riga o di colonna
  9. Il titolo dei frame deve facilitare l’identificazione e la navigazione dei frame
  10. Le pagine devono essere progettate in modo da evitare allo schermo di lampeggiare con una frequenza maggiore di 2Hz e minore di 55 Hz
  11. Quando la conformità non può essere raggiunta in nessun altro modo è necessario prevedere una pagina di solo testo che contenga le stesse informazioni e le stesse funzionalità. Il contenuto della pagina di solo testo deve essere aggiornato insieme alla pagina principale
  12. Se le pagine utilizzano linguaggi di scripting per visualizzare il contenuto o per creare elementi di interfaccia, l’informazione resa disponibile dallo script deve essere anche disponibile dalla tecnologia in aiuto alle persone disabili
  13. Quando in una pagina web ci sono applet, plug-in o altre applicazioni che vengono eseguite dal client, questi devono essere conformi alla 1194.21(a) fino alla (l) (ovvero, essere a loro volta accessibili)
  14. Una form online deve consentire alle persone che fanno uso di screen reader, software vocali, ecc. di accedere alle informazioni, ai campi e alle funzionalità richieste per il completamento della form, inclusi aiuti e suggerimenti
  15. L’utente deve poter saltare i link di navigazione persistente
  16. Quando è necessaria una risposta entro un certo lasso di tempo, l’utente deve essere avvertito e gli deve essere concesso sufficiente tempo per completare il compito

Differenze tra Wcag e Section 508

Impossibile ignorare una profonda somiglianza tra le linee guida Wcag e Section 508, fatto normale considerato che le Section 508 si basano sulle specifiche del Wai.

Quasi tutti i checkpoint uno sono presenti nella Section 508, ad eccezione di:

  • Fino a quando i browser non saranno in grado di leggere il testo di trascrizione di un video, è necessario includere anche una versione audio (1.3)
  • È necessario identificare i cambiamenti di lingua nel testo (4.1)
  • Assicurare che il contenuto alternativo a quello dinamico sia aggiornato insieme a quest’ultimo (6.2)
  • Usare un linguaggio semplice e appropriato per il contenuto del sito (14.1)

Alcune linee guida della Section 508 sono in corrispondenza con i checkpoint di priorità 2 e 3.

In generale non esistono sostanziali differenze, se non per il fatto che alcuni checkpoint Wcag di priorità 2 e 3 sono “premiati” nella Section 508.

Per un’approfondita analisi delle differenze tra le due serie di linee guida vi suggeriamo la lettura di un articolo [nuova finestra] scritto da Jim Thatcher, autore di Constructing Accessible Web Sites.

La situazione in Italia

Una circolare firmata dal ministro Bassanini nel Marzo del 2001 pone l’accento sui requisiti di usabilità ed accessibilità per i siti delle pubbliche amministrazioni. Il documento [nuova finestra] indica come riferimento primario le linee guida del W3c.

A seguito del documento, Aipa ha prodotto una circolare [nuova finestra] per chiarire gli strumenti e i metodi a disposizione per migliorare l’accessibilità web. Si tratta di una riscrittura e in qualche caso di un approfondimento alle linee guida del W3c, ed è incluso anche qualche parametro quantitativo per misurare l’accessibilità, come i browser da usare per valutare il grado di accessibilità di un documento.

Siamo comunque ancora in una fase in cui sono fornite indicazioni di massima su come includere le politiche di accessibilità nel proprio sito. Basta navigare i siti delle pubbliche amministrazioni per rendersi conto che c’è ancora molta strada da compiere. Nei casi più fortunati sono state predisposte delle versioni alternative accessibili dei siti, come è accaduto per la Camera dei Deputati [nuova finestra].

Quale standard usare?

Come abbiamo visto, la scelta tra le Section 508 e le Wcag è sostanzialmente equivalente. Ricordate comunque che il vostro unico metro di giudizio sarà il test finale al quale sottoporre ogni pagina del sito per verificarne l’accessibilità.

Un test, come vedremo più avanti, non ha l’unico scopo di verificare la conformità del codice scritto, ma anche il livello di efficacia dell’interfaccia grafica del sito, nonché lo stile di scrittura, che nel web dev’essere particolarmente diretto e facilmente scansionabile.

Nel corso dei nostri esempi cercheremo di soddisfare sia le Wcag sia la Section 508, senza nascondervi che questo a volte non sarà possibile o non sarà conveniente. Giustificheremo allora le nostre sceltre proponendo delle personali, e come tali sicuramente criticabili, soluzioni.

ASP.NET: Introduzione ad ADO.NET

Pubblicato il da

Corso ASP.NET: nona puntata

Con l’avvento della piattaforma .NET, Microsoft ha anche rilasciato la nuova versione delle librerie di accesso ai dati, chiamate oggi ADO.NET.

Le caratteristiche di ADO.NET che ne hanno motivato la nascita sono essenzialmente:

  • modello di dati disconnesso
  • accesso “trasparente” a documenti Xml
  • forte integrazione con i controlli .NET (DataGrid, DataList, ecc.)

Modello di dati disconnesso

Lavorando con ADO.NET e in particolare con l’oggetto DataSet, ci si rende conto di come in ADO.NET si lavora disconnessi dalla sorgente dati:

  • si prelevano i dati dal database o dai file con cui si intende lavorare
  • si manipolano/visualizzano i dati di interesse che sono stati copiati nella “memoria” del DataSet
  • terminate le operazioni, si possono nuovamente salvare i dati

Questa caratteristica poteva essere esplicitamente richiesta in ADO 2.6, mentre in ADO.NET diventa il comportamento di default.

Accesso trasparente a documenti Xml

ADO.NET dispone di un supporto nativo per la gestione e manipolazione di documenti Xml, nonché di sincronizzazione con gli oggetti di tipo DataSet. Passare da una rappresentazione all’altra è quasi trasparente e consente di utilizzare il Data Binding sia quando le sorgenti dati sono database, sia quando stiamo accedendo a documenti Xml.

Integrazione con i controlli

Come abbiamo visto nella puntata precedente, tra le caratteristiche di ASP.NET che tagliano i ponti con il passato ci sono le tecniche di Data Binding, che consentono di legare un controllo ad una sorgente dati. Negli esempi precedente abbiamo in realtà utilizzato delle sorgenti fittizie, come degli array. La vera potenzialità del Data Binding si ottiene associando i controlli a oggetti ADO.NET.

Il modello ad oggetti ADO.NET

[D]

Per collegarsi ai dati in ADO.NET sono possibili diverse strade.

È possibile utilizzare direttamente un oggetto di tipo Command o un DataReader, ma l’oggetto più completo e complesso è sicuramente il DataSet.

In ADO.NET gli oggetti appartengono a due insiemi:

  • i Data Provider, che sono lo strato a contatto con la sorgente dati
  • il DataSet, un “contenitore” dei dati

Nel .NET Framework sono per il momento compresi 2 tipi di Data Provider, quelli per:

  • sorgenti dati di tipo OLE DB
  • Sql Server

Nessuno vi impedisce chiaramente di accedere a SQL Server con il Data Provider di tipo OLE DB; le prestazioni, comunque, non saranno paragonabili a quelle del Data Provider dedicato.

Esiste in realtà un Data Provider per ODBC [nuova finestra], non compreso nel .NET Framework, ma scaricabile dal sito Msdn di Microsoft. Questo provider è utile nel caso sia necessario accedere a sorgenti di tipo non OLE DB, come un database Dbase.

In fase di preparazione c’è inoltre un Data Provider per Oracle [nuova finestra].

Ogni Data Provider è composto da 4 oggetti:

  • Connection, la connessione fisica alla sorgente dati
  • Command, utilizzato per:
    • ottenere un DataReader
    • ottenete un DataSet
    • eseguire delle SELECT, UPDATE e DELETE dirette alla sorgente dati
  • DataReader, un insieme di risultati di tipo forward-only e read-only
  • DataAdapter, un oggetto utilizzato per popolare un DataSet e aggiornare la sorgente dati

DataReader e DataSet

Il DataReader è sicuramente l’oggetto da preferire quando le operazioni sui dati sono visualizzazioni, iterazioni, paginazioni: consente di ottenere le performance maggiori.

Se invece è necessario aggiornare i dati, il DataSet può rappresentare la scelta migliore. Poiché il modello ADO.NET è di tipo disconnesso, il DataAdapter ricopre il ruolo di ponte tra la sorgente dati e il DataSet.

Il DataAdapter si preoccupa così di popolare il DataSet con i dati della sorgente dati e successivamente di aggiornare la sorgente dati con le modifiche eventualmente apportate al DataSet.

Il DataSet è sempre disconnesso dalla sorgente dati e può contenere, a differenza del Recordset ADO, dati provenienti da diverse tabelle e sorgenti dati. Per questo motivo l’oggetto DataSet dispone di un metodo Tables che restituisce una collezione delle tabelle che contiene

Conclusione

Abbiamo appena sfiorato le caratteristiche di ADO.NET, tralasciando tutta la parte relativa al supporto Xml. Lo scopo di questa lezione è in realtà porre l’accento sulle differenze di ADO.NET rispetto ad ADO. Quello che va ricordato è che esistono due tipi di oggetti tra cui scegliere: DataReader, efficiente con dati in sola lettura e forward-only e il DataSet, oggetto completamente disconnesso dalla sorgente dati e comandato da un DataAdapter.

Siti accessibili

Pubblicato il da

Questo articolo fa parte di un corso gratuito di accessibilità web ospitato su questo sito.

Navigando per la rete, la probabilità che un sito sia veramente accessibile è oggi piuttosto scarsa. Molti sono i tranelli che rendono un sito non accessibile, ma i più comuni sono:

  • immagini e mappe senza l’attributo alt
  • etichette dei link poco significative
  • colori con poco contrasto
  • dimensioni di font piccole e non personalizzabili dal lettore
  • uso esagerato di animazioni (soprattutto Flash)

Non sempre è facile costruire un sito completamente accessibile, poiché tante sono le variabili da tenere in considerazione e non esistono software o servizi che automatizzino completamente il processo.

Questa non è comunque una scusa valida per abbandonare la costruzione di un sito accessibile. La maggior parte delle linee guida che rendono un sito sufficientemente accessibile sono facili da includere, soprattutto se stiamo progettando un nuovo sito.

Tipici casi di siti non accessibili

Vediamo come progettare un sito perché NON sia accessibile. Si tratta di alcuni esempi trovati per caso in rete durante la normale navigazione. Nostra intenzione non è quella di criticare questi siti, incolpevoli protagonisti della nostra prova, anche perché siamo sicuri che ce ne siano sicuramente altri, meno accessibili di questi.

Camera di commercio di Belluno [nuova finestra]

Il sito presenta numerose lacune che ne pregiudicano l’accessibilità. Tra le altre cose:

  • titolo – La pagina è senza titolo (tag title). Un utente dotato di software di sintesi vocale potrebbe dover aspettare minuti prima di capire in quale sito è capitato
  • immagini e testo alternativo – Le immagini del menu (La Camera, I servizi, Agenda, ecc.) non dispongono del tag alt. Un software di sintesi vocale non sarà mai in grado di aiutare a capire dove punta il link
  • applet – A fondo pagina compare un’applet Java con del testo scorrevole. Anche in questo caso non c’è modo, per un software di sintesi vocale, di “leggere” il testo che scorre

Barra di navigazione senza titolo
Mancano gli alt alle immagini

Federazione italiana sport equestri [nuova finestra]

In questo caso osserviamo un esempio di form non accessibile:

  • colore – I campi in rosso sono obbligatori, ma una persona affetta da daltonismo non sarà in grado di capire quali campi deve compilare e quali, invece, può tralasciare. Molto meglio mettere i campi obbligatori in grassetto oppure evidenziarli con un’immagine
  • accesso ai campi – Se provate a premere il tabulatore vi accorgete che dovete insistere per un bel po’ di volte prima che il cursore si posizioni nel primo campo della form. Non è un limite esclusivo delle form, ma di tutta la navigazione. È bene dare la possibilità di “saltare” tutti gli elementi di navigazione usando una combinazione di tasti
  • compilazione dei campi – In caso di dato mancante viene presentata una schermata con l’elenco degli errori e la possibilità di tornare alla pagina precedente. Questa soluzione ha due svantaggi:
    1. richiede di tornare indietro, quando la form potrebbe essere riproposta su questa stessa pagina
    2. è facile dimenticarsi qualcuno degli errori commessi; l’errore dovrebbe comparire in corrispondenza dei dati errati all’interno della form, con un sommario in testa alla pagina, così il software di sintesi vocale è il grado di leggerli per primi

Form con i campi obbligatori in rosso
Elenco di errori nella form

Provincia di Bolzano [nuova finestra]

  • alt text e testo – Qui il problema comincia dalla spash screen, poiché un software di sintesi vocale non ha la possibilità di distinguere tra le varie lingue; non rimane che provare a caso
  • organizzazione dei contenuti – Una volta entrati nel sito, ci si trova davanti un enorme elenco di link che scoraggia anche i più avventurosi. Sono presenti degli alt, purtroppo mancano ancora per i titoli delle sezioni, dove la loro presenza è fondamentale
  • grafica – Le etichette di testo nella parte bassa dello schermo sono ottenute applicando un effetto anti-alias troppo marcato e sono poco leggibili

Splash screen senza alternative
Pagina fitta di elenchi
Footer con anti-alias troppo marcato

Virgilio Mappe [nuova finestra]

  • alt text nelle image map – La mappa d’Italia non porta i nomi delle regioni né nell’immagine, né negli alternative
  • uso della tastiera – attenzione anche se scrivete il nome di una zona nella form e premete invio. Dovete in realtà spostarvi espressamente sul pulsante “cerca” perchè la ricerca funzioni correttamente

Mappa dell'Italia senza alt

Holden Lab [nuova finestra]

Il sito della scuola Holden, benché sia una cornucopia di contenuti, soffre di diversi problemi di usabilità ed accessibilità:

  • navigazione – La barra di navigazione sinistra, oltre che essere una serie di immagini, è anche poco chiara concettualmente. Da evitare metafore sulla quali l’utente si interroga ogni volta
  • trascrizioni – La recensione dei libri è presente solo come file sonoro, mentre riteniamo fondamentale la presenza di una trascrizione del testo.
  • file sonoro – Il caricamento del file sonoro lascia a desiderare. Richiede Flash e l’utente non può scegliere di rinunciarvi: viene caricato insieme alla scheda del libro.
  • tabelle e colori – La tabella con brevi spunti per i libri (da ridere, da regalare, ecc.) non è accessibile: un software di sintesi vocale non è in grado di distinguere tra voci selezionate (con sfondo arancione) e non selezionate.

Navigazione con titoli emblematici: arcipelago, immersioni, porto di mare
File sonoro senza trascrizione
Tabella non accessibile con sfondo arancione

Come costruire un sito accessibile

La costruzione di un sito accessibile ne interessa l’intero cicla di vita, dalla progettazione alla manutenzione. Vediamo in breve cosa va tenuto in considerazione in ogni fase.

Information Architecture

In questa fase vengono realizzati gli schizzi, i percorsi di navigazione, la nomenclatura per i menu e le etichette. Siamo in un momento in cui l’accessibilità va a braccetto con l’usabilità. L’information architect deve assicurarsi di:

  • scegliere una nomenclatura non ambigua, chiara e semplice da ricordare
  • realizzare un percorso di navigazione efficiente
  • prevedere una struttura di pagina modulare, con spazi tra le sezioni e ampia rilevanza data al contenuto “utile”

Visual Design

Visual designer è chi parte dagli “schizzi” preparatori e realizza i template grafici necessari per la costruzione dell’Html. In questa fase accessibilità significa:

  • scegliere colori con sufficiente contrasto tra sfondo e contenuto
  • non lasciare che il colore da solo porti con sé un carico informativo, come l’evidenziazione di una sezione o l’obbligatorietà di un campo in una form
  • privilegiare dove possibile il testo alle etichette grafiche
  • prevedere soluzioni “ridondanti” per soddisfare il maggior numero di utenti:
    • grafica unita al testo (soprattutto per le image map)
    • descrizione di testo per grafici ed elementi complessi
    • spazio per trascrizioni di filmati ed audio
  • realizzare una guida di stile che spieghi come è stato realizzato il design e gli standard impiegati e consegnarla a chi si occuperà della manutenzione del sito una volta avviato

Product Design

È il lavoro “dell’htmlista”: tradurre i template grafici nella struttura Html.

È la fase in cui le politiche di accessibilità entrano prepotentemente. Qui sono usati i tag e gli attributi che consentono di migliorare l’accessibilità di un sito:

  • completare immagini e image maps con il testo alternativo
  • creare form con ordine di tabulazione corretto e tasti di scelta rapida
  • creare tabelle arricchite di contenuto per i sintetizzatori vocali
  • creare pagine conformi agli standard (X)Html
  • verificare la conformità agli standard con software di controllo
  • sforzarsi di usare i Css per tutte le esigenze di layout della pagina. Se questo non è proprio possibile, utilizzare i Css almeno per i font e gli sfondi
  • usare tipi di misura per i font che consentano all’utente di dimensionare i caratteri (FucinaWeb usa “small“, “medium“, “large“, ecc.
  • sforzarsi di creare pagine visualizzabili in tutti i browser, senza però pretendere che il risultato sia perfetto per ogni piattaforma
  • permettere all’utente di saltare gli elementi della navigazione premendo un link
  • realizzare una guida di stile relativa alle soluzioni adottate da consegnare a chi si occuperà della manutenzione del sito

Programmazione

È la parte di “ingegnerizzazione” del sito. Dove necessario, vengono prese le pagine realizzate nella fase di “Product Design” e rese dinamiche attraverso la comunicazione con database o sistemi di “Content Management“. È opportuno:

  • privilegiare soluzioni server side rispetto a soluzioni client side. Con una soluzione a livello server (Asp, Php, Jsp) è possibile inviare una pagina (X)Html al client. Utilizzando degli script lato client si rischia invece che il contenuto non sia accessibile (ad esempio perché un sintetizzatore vocale non è in grado di leggere quanto presentato sulla pagina)
  • applet e plug-in realizzati devono anch’essi essere dotati di un’interfaccia accessibile

Contenuti

Anche chi si preoccupa di fornire il materiale del sito deve avere le politiche di accessibilità ben chiare in testa:

  • cambiare lo stile di scrittura: paragrafi succinti, divisione in punti dei concetti, per prime le informazioni più importanti
  • evidenziare con attributi opportuni (lang) le parole straniere
  • scegliere efficacemente le etichette per i link
  • informare se un link si apre in nuova finestra
  • sottotitolare i filmati e rendere disponibili trascrizioni delle tracce audio
  • produrre contenuti alternativi per la grafica ed arricchire le tabelle per aiutare i software di sintesi vocale
  • creare una guida di stile per le parole da usare, le forme verbali, la suddivisione dei capitoli

Test

È fondamentale provare in situazioni diverse il sito per verificarne l’accessibilità:

  • con più browser (anche di testo)
  • senza Css
  • dimensionando i caratteri
  • con software di sintesi vocale
  • usando software che misurano l’accessibilità, come Bobby e A-prompt
  • provando a “linearizzare” le tabelle

Manutenzione

L’accessibilità non è un rimedio, ma un processo che continua anche durante la produzione di nuovi contenuti e la modifica del sito esistente. Tutto quanto è stato detto per le fasi precedenti si applica anche alla fase di manutenzione del sito, dopo cioè il suo rilascio.

Come migliorare l’accessibilità di un sito esistente

Ne abbiamo già parlato: non sempre siete nella fortunata ipotesi di creare un sito da zero e di progettarlo con soluzioni accessibili. Molte volte interverrete su un sito già avviato. Cerchiamo di vedere quali sono i punti di intervento realisticamente possibili, fermo restando che ogni sito si sottoporrà più o meno a questi interventi.

Modifiche a basso impatto sul sito esistente

  • contenuto alternativo per immagini, image maps e tabelle
  • inserire i tasti di scelta rapida (shortcut) nelle voci di menu
  • stile editoriale consono per i nuovi contenuti (con descrizioni efficaci dei link)
  • realizzazione di trascrizioni e sottotitoli per i nuovi contenuti (costoso)
  • rendere accessibili le form inserendo dove necessario l’ordine di tabulazione e i tasti di scelta rapida

Modifiche a medio impatto sul sito esistente

  • aumento del contrasto di colore dove necessario
  • modifica dei caratteri nei fogli stile per aumentare la leggibilità e consentire il dimensionamento
  • stile editoriale consono per tutti contenuti
  • realizzazione di trascrizioni e sottotitoli per tutti i contenuti
  • possibilità di saltare la navigazione persistente

Modifiche ad alto impatto sul sito esistente

  • sostituzione degli script lato client con programmi lato server
  • realizzazione di una navigazione intuitiva ed efficace
  • uso relativo delle tabelle di layout o sostituzione con Css

Il difficile compromesso tra accessibilità e compatibilità

Nel realizzare un sito accessibile, dovete operare delle scelte. È inevitabile che non riusciate nello stesso tempo a costruire un sito accessibile e garantire a tutti i browser una visualizzazione ottimale dei contenuti. A prima vista sembra un controsenso, ma basta un esempio per rendersene conto.

Per realizzare un sito accessibile dovreste abbracciare i Css per la realizzazione degli elementi di layout e sostituirli in questo alle tabelle. Così facendo, però, penalizzate gli utenti che non dispongono delle ultime versioni dei browser. In altre parole: aumentate l’accessibilità per una parte del vostro pubblico, penalizzandone un’altra.

Nel medio periodo, con l’adozione massiccia degli standard, questa situazione si andrà risolvendo. All’oggi siamo però ancora nella fase del dubbio. È certamente possibile, utilizzando tecnologia lato server, creare diverse versioni del sito in base al browser dell’utente, ma quasi sempre, a meno di siti con poche pagine, si tratta di una soluzione complessa e dai costi elevati.

All’oggi vale probabilmente ancora la pena di utilizzare le tabelle con il layout, tenendo però questo tipo di tabelle il più possibile fuori dalla parte di contenuti del sito. Domani, quando potrete dare sfogo all’uso dei Css, cambierete la navigazione e l’intelaiatura della pagina, ma interverrete in modo minimo sui contenuti.

Usare soluzioni ad interim

Il supporto dei tag accessibili da parte dei browser e dei software di riconoscimento vocale è solo parziale. Attributi come longdesc sono al momento ignorati, altri come acronym sono visualizzati efficacemente solo da Netscape e Mozilla. Non basta quindi utilizzare tag accessibili, ma inserire espliciti riferimenti che aumentino l’accessibilità.

Fino a quando il browser non aiuterà il lettore, è anche necessario arricchire il testo per avvertirlo quando un link si apre in una nuova finestra, completare i campi delle form con del contenuto fittizio (perché alcuni software di sintesi vocale non considerano un campo quando è vuoto), separare link adiacenti (non solo con spazi).

Nelle puntate pratiche del corso, vedremo anche questo.