Archivi tag: interfaccia

10 manuali di web design e usability

Pubblicato il da

I libri recensiti da FucinaWeb.com:

Information Architecture For The World Wide Web, Second Edition – Louis Rosenfeld, Peter Morville

Ma come? L’Information Architecture non è il web design!

Vero. Collochiamo in questa rassegna anche un libro che fa riferimento a quella parte della User Experience che ha a che fare con “l’Information Architecture“, la disciplina che si occupa tra le altre cose di raggruppare e disporre gli elementi del sito perché un utente li possa fruire in modo efficace. È la nuova edizione del testo scritto nel 1998 e per la verità mai superato. Imparerete quali sono i diversi tipi di navigazione, come raggruppare le informazioni, come scegliere i nomi delle voci di menu e molto altro ancora.

FucinaWeb.com ha realizzato un recensione completa del testo ed ha intervistato i due autori.

È l’unico libro che non dovrebbe mancare nella vostra biblioteca.

L'orso polare della copertina

Information Architecture for the World Wide Web – Second Edition ¤ di Louis Rosenfeld e Peter Morville ¤ lingua inglese ¤ 460 pagine ¤ prezzo 45.60 euro ¤ edito da O’Reilly

Sito del manuale [nuova finestra] (scheda, errata, capitolo gratuito)

Top

Web Design Arte e Scienza – Jeffrey Veen

In questo manuale troverete consigli ed esempi di codice da usare per realizzare siti accattivanti superando i limiti (e i bug) dei browser.

Tra gli argomenti presentati:

  • Consistenza dell’interfaccia (dove sono, dov’è quello che cerco, dove sto andando, i tipi di navigazione)
  • Struttura (come organizzare le informazioni, Xml per descrivere contenuto e significato dei dati)
  • Design cross-browser (il design “liquido”, quali tipi di carattere scegliere, usare e forzare i Css)
  • I browser (capire i limiti, quali browser considerare, riconoscere il browser lato client)
  • La velocità (come velocizzare il download delle pagine con un accorto uso di Css, e di scelte di design)
  • La pubblicità (i banner peggiori, come registrare gli utenti)

Le scelte di Jeffrey Venn sono a volte ardite e ne sono la dimostrazione gli esempi, che è sempre interessante analizzare a fondo. La soluzione migliore è forse di realizzare siti frutto di un mix tra il design dell’autore e le regole di usabilità di Steve Krug.

Web Design Arte e Scienza (titolo originale The Art and Science of Web Design) ¤ Autore Jeffrey Veen ¤ lingua italiana ¤ Edito da Apogeo (editore originale New Riders) ¤ Prezzo 35.64 euro ¤ 250 pagine

Sito del manuale [nuova finestra] (scheda)

Top

Dalla Carta al Web – Jeffrey Zeldman

Un manuale rivolto, almeno nelle intenzioni, al designer tradizionale che sbarca nel web. In realtà i suggerimenti dell’autore di AListApart [nuova finestra] sono validi anche per chi è web designer da tempo. Secondo Zeldman è il momento di abbandonare lo sviluppo di siti conformi ai browser della versione 4 e di abbracciare appieno lo standard Css anche riguardo al posizionamento degli elementi.

Gli argomenti presentati:

  • Capire il medium (le dimensioni delle pagine, i limiti dell’Html, tecniche cross-browser, la navigazione e l’interfaccia,
  • Il ruolo del designer nel web
  • Come fare (codice Html e Xhtml, i formati grafici, come usare i fogli di stile, cosa può fare il codice Javascript)

Dalla Carta al Web – Istruzioni per l’uso per designer di talento (titolo originale Taking Your Talent to the Web – A Guide for the Transitioning Designer) ¤ di Jeffrey Zeldman ¤ lingua italiana ¤ Edito da Hops (editore originale New Riders) ¤ prezzo 35.12 euro ¤ 420 pagine

Sito del manuale [nuova finestra] (scheda)

Top

Web Navigation – Jennifer Flaming

Questo manuale si concentra principalmente sulla navigazione del sito, di cui analizza diversi aspetti:

  • Navigazione in siti commerciali
  • Navigazione in siti di comunità
  • Navigazione in siti di intrattenimento
  • Navigazione in siti d’identità (corporate)
  • Navigazione in siti per l’apprendimento
  • Navigazione in siti d’informazione

Ciascun capitolo evidenzia le necessità di ciascun tipo di sito, le aspettative degli utenti, alcuni casi studio e di esempi da seguire.

Il manuale si apre con alcune linee guida rigurdanti la struttura della navigazione che dovreste fotocopiare e appendere in ufficio

Web Navigation – Il design delle interfacce web (titolo originale Web Navigation: Designing the User Experience) ¤ di Jennifer Flaming ¤ lingua italiana ¤ Edito da Hops (editore originale O’Reilly) ¤ Prezzo 25.31 euro ¤ 330 pagine

Sito del manuale [nuova finestra] (scheda, capitoli gratuiti)

Top

Web Style Guide Second Edition – Patrick Lynch, Sarah Horton

Lynch e Horton sono i primi autori ad aver capito le reali necessità del web e ad everne parlato con intensità ed intelligenza nel sito web dell’Università di Yale.

Si tratta di una guida di stile: integra al suo interno elementi di design, senza mai dimenticare le necessità dell’usabilità.

Al testo, giunto recentemente alla seconda edizione, abbiamo dedicato una approfondita recensione.

Il manuale è particolarmente adatto per introdurre i concetti di web design e web usability a classi di studenti.

Web Style Guide – Second Edition ¤ di Patrick J. Lynch e Sarah Horton ¤ lingua inglese ¤ pagine 220 ¤ prezzo 18.95 dollari ¤ edito da Yale University Press

Sito del manuale [nuova finestra] (versione online del manuale)

Top

Web Usability – Jakob Nielsen

È il “classico” della web usability. Spesso criticato per le centinaia di linee guida costrittive che produce, Jakob Nielsen rimane comunque tra i maggiori esperti in questo campo e la sua newsletter quindicinale, Alertbox [nuova finestra], non va mai trascurata.

Il manuale copre diversi aspetti dell’usabilità web:

  • il design della pagina
    • come lo spazio va suddiviso tra contenuto, pubblicità e navigazione
    • la necessità di creare siti fruibili a diverse risoluzioni
    • realizzare siti cross-browser
    • come costruire i link
    • riflessioni sull’uso dei frame
  • il design dei contenuti
    • come l’utente legge e come si scrive per il web
    • come pensare i titoli e i sommari
    • uso efficace di immagini, video e suoni
  • il design del sito
    • la home page è diversa dal resto del sito
    • come costruire la navigazione
    • le funzionalità di ricerca
    • costruzione efficace degli Url
  • design per l’intranet
  • accessibilità web

Il libro è piuttosto teorico: non troverete mezza linea di codice Html a corredo delle spiegazioni. Molti sono però i siti presentati di cui sono analizzati i limiti (tanti) e i pregi (quasi nessuno).

Se applicate alla lettera tutto quello che dice Nielsen, finirete per realizzare siti di solo testo. Il vostro scopo è però diverso: dovete essere al corrente di quali sono tutte le regole di usabilità web. In questo modo potrete decidere a quali rinunciare e quali, invece, utilizzare per la costruzione delle pagine.

Web Usability (titolo originale Designing Web Usability) ¤ di Jakob Nielsen ¤ lingua italiana ¤ Edito da Apogeo (editore originale New Riders) ¤ Pagine 480 ¤ Prezzo: 40.28 euro

Sito del manuale [nuova finestra] (scheda)

Top

Usability for the Web – Brinck, Gergle, Wood

È un manuale di cui solitamente non si parla, ma che ha il vantaggio di analizzare l’impatto dell’usabilità durante l’intero processo di realizzazione di un progetto web, dall’analisi dei requisiti sino alla messa in produzione. Visto che l’usabilità è parte di ogni proposta, decisione e realizzazione, gli autori hanno coniato il termine di “pervasive usability“.

Leggendo il testo vestirete i panni del project manager, del web architect, del web designer, dello sviluppatore e infine del tester.

Il manuale (di cui abbiamo apprezzato anche il “design dell’impaginazione”, tanto che ha influenzato la costruzione di FucinaWeb.com) è suddiviso in 7 parti:

  • Pervasive usability (cos’è, come è composto il processo di realizzazione di un sito web, vantaggi e svantaggi dei diversi approcci alla web usability
  • Analisi dei requisiti (capire gli utenti e le loro richieste, intervistarli e realizzare i focus group)
  • Conceptual design (task analysis e information architecture)
  • Realizzazione dei prototipi (come costruirli, come presentarli, come valutarli)
  • Produzione (scrivere contenuti per il web, il design degli elementi della pagina)
  • Lancio del sito (il test di qualità pre e post lancio)
  • Valutazione dell’usabilità

Il manuale è particolarmente consigliato se vi occupate di progetti di medie dimensioni, dove molto probabilmente oltre che web designer potreste ricoprire il ruolo di grafico, editor o sviluppatore di pagine Html. Troverete anche spunti interessanti per argomentare le vostre ragioni durante le riunioni di progetto.

Usability for the Web: Designing Web Sites that Work ¤ di Tom Brinck, Darren Gergle, and Scott D. Wood ¤ lingua inglese ¤ Edito da Morgan Kaufmann ¤ Prezzo 49.95 dollari ¤ 430 pagine ¤ Lingua: inglese

Sito del manuale [nuova finestra] (scheda, materiale)

Top

Don’t make me think – Steve Krug

La caratteristica che colpisce per prima è la dimensione: appena 200 pagine. Non si tratta infatti di un manuale che analizza tutti gli aspetti dell’usabilità web, ma di un’efficace guida che vi presenta cosa è fondamentale considerare nella realizzazione di un sito. Il tono è amabile, a volte addirittura scherzoso: vi sembrerà di leggere un fumetto piuttosto che un manuale. Steve Krug si comporta da psicologo e come tale vi porta a capire come l’utente si comporta di fronte alle vostre pagine, cosa pensa e cosa ricerca. L’utente è il vero protagonista di questo testo.

Gli argomenti affrontati sono:

  • L’utente non ha voglia di pensare troppo
  • Come l’utente usa il web
  • Come scrivere per il web
  • La navigazione efficiente
  • L’Homepage è un caso particolare
  • Come lavorare in team
  • Come svolgere un test di usabilità

L’ultima parte del testo è particolarmente interessante: imparerete come realizzare con poca spesa un test di usabilità e, soprattutto, come valutarne i risultati.

Non fatevi spaventare dal numero esiguo di pagine: c’è gran parte di quello che vi serve.

Don’t make me think – Un approccio di buon senso all’usabilità web (titolo originale: Don’t make me think – A common sense approach to Web Usability) ¤ Di Steve Krug ¤ lingua italiana ¤ Edito da Hops (editore originale New Riders) ¤ Pagine 200 ¤ Prezzo 33,05 euro

Sito del manuale [nuova finestra] (scheda)

Top

Homepage Usability – Jakob Nielsen e Marie Tahir

Questo manuale analizza esclusivamente le Homepage di un sito. Al momento della pubblicazione FucinaWeb.com ne ha realizzato una recensione, a cui vi rimandiamo per approfondimenti. Al di là dei casi studio di 50 Homepage, stimolanti sono le linee guida presentate in apertura al volume.

Homepage Usability – 50 siti web analizzati (titolo originale Homepage Usability – 50 Websites Deconstructed) ¤ di Jakob Nielsen, Marie Tahir ¤ lingua italiana ¤ Edito da Apogeo (editore originale New Riders) ¤ Prezzo 45.00 euro ¤ 330 pagine

Sito del manuale [nuova finestra] (scheda, esempi, errata)

Top

Usability: The Site Speaks for Itself – Braun, Gadney, Haughey, Roselli, Synstelien, Walter, Wertheimer

Un manuale che presenta casi studio da 6 siti web di rilievo (tra cui la Bbc e l’Economisti) come se fossero interviste agli autori che hanno progettato e sviluppato il sito.

Un ottimo riferimento per chi si occupa della costruzione di siti web di un certo rilievo e rivolti ad un vasto pubblico.

Ne abbiamo parlato approfonditamente in una recensione dedicata.

Usability: The Site Speaks for Itself ¤ di Braun, Gadney, Haughey, Roselli, Synstelien, Walter, Wertheimer ¤ pagine 280 ¤ prezzo 49.99 dollari ¤ lingua inglese ¤ edito da Glasshaus

Sito del manuale [nuova finestra] (scheda, esempi, errata)

Top

L’accessibilità web e i browser – L’interfaccia grafica

Pubblicato il da

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

Il browser svolge un ruolo centrale per l’accessibilità web:

  • deve poter essere personalizzato in modo da rendere accessibile il suo contenuto: dimensionamento dei caratteri, sostituzione dei fogli di stile con quelli decisi dall’utente, ecc.
  • deve interpretare correttamente i tag “accessibili” dell’Html , migliorando l’esperienza di tutti gli utenti che lo usano

In questa e nella successiva lezione ci occupiamo di supporto all’accessibilità da parte dei browser in due contesti:

  • personalizzazione – Come è possibile configurare ed estendere l’interfaccia utente del browser per soddisfare specifiche esigenze
  • supporto all’Html accessibile – Quali tag accessibili sono riconosciuti dai browser e in che modo, quando è necessario ricorrere a soluzioni “provvisorie”

In questa puntata ci soffermiano in particolare su alcune caratteristiche dei browser, che possono influenzare il modo di sviluppare le pagine.

Nella prossima lezione vedremo invece come 15 tipi di browser interpretano le specifiche accessibili dell’Html, con un esempio completo e alcune tabelle comparative di riepilogo da tenere sempre a portata di mano.

Caratteri e zoom

È tra gli argomenti più delicati quando si parla di accessibilità: la possibilità di modificare ed ingrandire i caratteri presenti nella pagina.

Internet Explorer consente di alterare le dimensioni dei caratteri di una pagina intervenendo con il menù View. Purtroppo, questa opzione non funziona con tutti i tipi di carattere definiti mediante Css.

Se provate questa “pagina di esempio con caratteri“ [nuova finestra], in cui sono definite alcune classi Css contententi regole su diversi tipi di dimensione, capirete quello che intendiamo:

Tutti i caratteri hanno la stessa dimensione
Internet Explorer: ecco come si presenta la finestra quando le dimensioni dei caratteri selezionate nelle opzioni sono poste a “Medium“
Alcuni caratteri (definiti in px e pt), non sono ridimensionati
Internet Explorer: modificando le opzioni, non tutti i caratteri vengono di conseguenza ridimensionati

Come si vede, non tutti i tipi di carattere sono ridimensionati. In particolare, le classi definite in punti (pt) e pixel (px) non variano la loro dimensione anche modificando le opzioni in Internet Explorer.

Un vero peccato, perché pt e px sono le unità di misura che lo sviluppatore riesce a controllare al meglio e che sono trattate quasi allo stesso modo dalle diverse piattaforme.

Netscape 6+ si comporta in modo diverso e, fortunatamente, ridimensiona tutti i tipi di carattere, indipendentemente da come sono stati definiti.

Netscape ridimensiona tutti i caratteri
Netscape 6+: ridimensionando i caratteri dal menù, la modifica interessa tutte le classi definite nel documento

Opera consente non solo di ridimensionare i caratteri, ma di zoomare nella pagina, così da ingrandire anche immagini e menù. Una funzionalità particolarmente utile e immediata da usare.

Fogli di stile

Internet Explorer dà la possibilità di creare ed utilizzare un foglio Css alternativo rispetto a quelli presenti nella pagina.

Per farlo (nella versione 6) è necessario intervenire dal menù Tool / Internet Options / Accessibility.

Il menù opzioni: ingore colors, font styles, font sizes, user style sheets
Internet Explorer: il menù che contiene le opzioni di accessibilità

È possibile a questo punto creare con un editor di testo un foglio di stile alternativo. Come esempio, abbiamo realizzato un foglio di stile ad alto contrasto per FucinaWeb.com.

Sfortunatamente, non sembra possibile poter utilizzare il nuovo foglio di stile senza selezionare le altre 3 opzioni presenti nella finestra. Sarebbe stato più logico pensare che il foglio di stile avesse la precedenza su quello di default.

Alto contrasto e testo scritto molto grande
FucinaWeb.com: una porzione del sito visualizzata con un Css ad alto contrasto

Sono interessanti le potenzialità offerte da Netscape 6+ e Mozilla.

La stessa pagina può infatti contenere le dichiarazioni di più Css, distinte tra loro dall’attributo title.

FucinaWeb.com contiene, infatti, alcune tipologie di Css, proprio per questo scopo.

Se provare a visualizzare il nostro sito con Netscape 6+ o Mozilla, e andate al menù View / Use Stylesheet, vi accorgerete che compaiono 2 scelte (oltre a “nessun Css”).

2 fogli di stile tra cui selezionare
Netscape 6: possibilità di scegliere tra più fogli di stile

Sono infatti utilizzati diversi fogli di stile. Semplificando, ecco i Css specificati in testa al sorgente Html:

  1 <link rel=”stylesheet” title=”Default” href=”/includes/globale.css” type=”text/css” media=”screen” />
  2 <link rel=”alternate stylesheet” title=”Alto Contrasto” href=”/includes/globale_contrast.css” type=”text/css” media=”screen” />

Come si vede, sono presenti 2 Css e a ognuno è associato un attributo title diverso.

Non solo, ricordatevi che per gli elementi di default il valore dell’attributo rel è “stylesheet“, mentre per gli altri “alternate stylesheet“. State attenti a non dimenticarlo, poichè a quel punto i browser caricano per primo quello che vogliono, a loro discrezione (e, come spesso succede, Netscape e Opera sembrano comportarsi diversamente uno dall’altro).

Questo dà la possibilità allo sviluppatore di realizzare fogli diversi per esigenze diverse, ma anche di provare in modo veloce diverse soluzioni di design.

L’unica nota negativa è che l’opzione non viene mantenuta durante la navigazione tra le pagine dei siti, costringendo ogni volta a riselezionare i Css.

Normalmente, una pagina in FucinaWeb.com ha questo aspetto:

Il colore della sezione è verde scuro

Se però viene scelto il foglio di stile ad alto contrasto, i colori delle sezioni vengono alterati:

Il colore della sezione è verde chiaro

Opera

Il browser Opera merita un discorso a parte, visto che uno dei suoi punti di forza è dato dalle diverse opzioni di configurazione, tanto da farne una delle piattaforme ideali per il testing dell’accessibilità.

Non abbiamo qui la pretesa di analizzarle tutte ma ci limiteremo, come sempre, a quelle di particolare interesse.

Author mode e User mode

Con Opera è possibile definire due personalizzazioni della pagina:

  • una che preservi il look progettato dallo sviluppatore
  • un’altra versione personalizzata per soddisfare le esigenze del lettore

Saltare da una all’altra è semplice e a portata di mouse

Opzioni per ignorare gli style sheet, definirne di personalizzati e utilizzare o meno le tabelle
Opera 6: dal menù File / Preference / Page Style è possibile configurare il comportamento dei due utenti virtuali

Tabelle

Opera rende molto facile l’operazione di “linearizzazione delle tabelle”.

Come vedremo meglio in un’altra lezione, gli screen reader associano un ordine di lettura alle celle di una tabella. Togliendo le tabelle, l’ordine procede dall’alto verso il basso ed è facile capire se il senso della pagina si è alterato.

Mouse gestures

È possibile richiamare le funzioni usate più frequentemente con alcuni movimenti del mouse e la pressione di alcuni tasti.

Barra degli indirizzi (suggerimento di Luca Rosati)

A sinistra della barra degli indirizzi sono presenti alcuni pulsanti che facilitano l’utilizzo delle opzioni normalmente impiegate nel test delle pagine. È possibile:

  • disabilitare il caricamento delle immagini
  • passare dalla modalità Author Mode a quella User Mode
  • visualizzare un’anteprima della pagina così come sarà su carta (molto utile se usate un Css dedicato per la stampa)

Hai notato qualche caratteristica particolarmente utile, ma della quale non abbiamo parlato? Scrivici e condividiamo la tua esperienza!

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.