Accessibilità e usabilità nel Web

Quando si parla di argomenti come accessibilità e usabilità, ultimamente sembra di seguire un po' una moda, ed il più delle volte si abusa di questi termini. Conosciamone il vero significato e soprattutto gli scopi


Accessibilità e usabilità sono ormai
argomenti troppo importanti per essere ignorati da chi lavora con le pagine Web. Per capirne il significato è quanto mai doveroso fare un piccolo salto
indietro, di qualche anno, e recuperare un po’ di memoria storica. In seguito si vedrà un esempio pratico e qualche raccomandazione per i webmaster.

Internet è nato come mezzo di scambio di informazione tra persone con
interessi, lavori, passioni comuni. Ogni singolo protocollo, ogni singolo
linguaggio di programmazione, ogni singolo nuovo concetto di comunicazione via
rete è stato creato pensando a come dovesse essere facile accedere ai documenti
via Internet (web, usenet, mail).

Il nome di Tim Berners Lee è forse sconosciuto ai più, ma è uno tra gli
uomini che ha maggiormente contribuito a creare ieri quello che per noi oggi è
il mezzo più potente per lavorare, studiare, viaggiare, divertirsi.

Il buon caro vecchio zio Tim inventò un linguaggio ad ipertesti che ancora
oggi porta il nome di HTML (HyperText Markup Language) e che è il fondamento di
tutti i progetti online. Il motivo della sua nascita? Rendere facile, universale, veloce e compatibile lo scambio di documenti e
informazioni da qualsiasi punto del mondo a qualsiasi altro punto dello stesso.

Questo era l’obiettivo di Internet com’è stato concepito e tutt’oggi
rimane l’obiettivo di chi nella rete c’è nato e la sta vivendo ogni giorno.
Purtroppo, la concezione distorta dei grandi magnati del marketing e della
comunicazione tradizionale, ha portato ad un proliferare di progetti Internet di
scarsissima qualità, orientati ad una filosofia aliena alla “vita”
online e al suo equilibrio. Questo “virus” oggi genera non poca
confusione nel processo educativo che viene rivolto ai nuovi utenti, ai nuovi
sviluppatori o consulenti che hanno deciso di intraprendere l’attività online.

Per questo motivo, seppur con aria di novità, rientrano in campo vecchi
schemi e filosofie di lavoro, visibili sul sito ufficiale della W3C-WAI (Web Accessibility Initiative) e a breve uscita anche su
Bazzmann.com , oltre che su altre risorse come
Web
Usabile
o Usabile.it .

Parlare di accessibilità significa prendersi cura di chi accede al proprio sito web ed è
afflitto da difficoltà motorie, visive o di altra natura, persone
che quindi adottano strumenti alternativi come lettori vocali, braille o
“estensioni” speciali. Chi parla di eccezioni (davvero possiamo
parlare di persone come di “eccezioni”?), probabilmente non ha
compreso ancora la vastità dei progetti online e della natura stessa della
rete, non a caso un documento scritto da Vanderheiden
(intitolato appunto: “Thirty-Something (Million): Should They Be Exceptions?”),
descrive come la quantità di persone disabili sia decisamente alta, nella sola
realtà statunitense.

Insomma, 30 milioni (il dato è del ’90, ma l’ho tenuto apposta per dare idea
di quanto vecchia sia l’esigenza) di persone non possono essere ignorate.

L’accessibilità quindi si rivolge agli sviluppatori come una tecnica da
adottare nei propri progetti, per poter rendere così più “vicine” le
proprie pagine a questa fascia di persone, rendendo di fatto il proprio sito
accessibile a tutti, o almeno alla maggioranza di essi.

L’usabilità è un tema simile, ma diverso. Sebbene l’usabilità contribuisca
a rendere accessibile e di facile fruizione un sito web, non è nel dettaglio
tecnico puro che ha sede il suo concetto, beansi nella concettualizzazione e nella
progettazione dell’interfaccia utente, che comprende testo, grafica, applicativi
e organizzazione della stessa struttura del sito.

L’usabilità è applicata ai siti web, ma anche ai programmi di uso comune. 

E’ importante capire che questi due temi non fanno parte di una moda: essi
sono la vita stessa di un buon sito web, di un buon programma, di una buona
interfaccia.


Chiunque utilizzi programmi visuali come Dreamweaver, FrontPage o GoLive!,
sarà a conoscenza della facilità e velocità con cui si possono costruire le
pagine web HTML, ma anche pagine più avanzate contenenti tecnologie come ASP
o linguaggi come PHP. Il codice generato, però, è abbastanza limitato alle funzioni che
normalmente vengono applicate in un sito web, come l’impaginazione, la
definizione dei colori, la grandezza dei font e così via. Dunque, per iniziare
a creare pagine accessibili, si deve
operare direttamente sul codice; anche se ormai tutti i maggiori produttori
stanno inserendo le opportune modifiche, la maggiore efficacia e correttezza si
ottiene ancora oggi editando "a mano" le parti più specifiche.

Lo strumento che principalmente mi sento di consigliare è Allaire
Homesite
, possiede degli ottimi
strumenti di editing, cerca & sostituisci, parsing, ma soprattutto include
già dei wizard ben fatti per l’accessibilità dei siti web e con l’aiuto degli
"snippets" il lavoro aumenta anche in produttività.

Macromedia Dreamweaver è
di per sé il programma principe per i webdesigner, ma può essere utilizzato
anche come strumento di testing per le proprie pagine scaricando delle estensioni che
includono dei controlli in linea che seguono la 508 Section
americana, facilmente installabili e utilizzabili. L’estensione è accessibile
alla pagina di Macromedia Exchange .
Per un uso professionale e "attivo", però, consiglierei la coppia
Dreamweaver/Homesite.

Tra i prodotti free che possono essere utili troviamo il sempre valido 1st
Page 2000
che non include opzioni rilevanti
di accessibilità, ma può risultare un ottimo strumento per l’editing di
codice; HTML Kit è un altro ottimo prodotto
free, forse un po’ alta la curva di apprendimento vista la sua complessità, ma
sicuramente completo; Amaya è forse il programma
più adatto, visto che tra "le altre cose" è il prodotto sviluppato
direttamente dal W3C, ma forse è quello più "restrittivo" in fatto
di programmazione al di fuori degli elementi supportati.

In realtà il panorama di prodotti free è ormai molto vasto, ma tra quelli
presenti, credo che questi possano far fronte un po’ a tutte le esigenze, senza
aspettarsi funzionalità troppo avanzate.


Prima abbiamo parlato di accessibilità e usabilità come di due concetti
diversi: il primo è più tecnico, il secondo più "organizzativo" e
relativo al design. In effetti è così, ma anche l’accessibilità ha delle
linee guide da adottare.

Prendiamo per esempio un normale codice di un’immagine che funziona come link:


<A HREF="http://www.ilmiosito.it">

<IMG SRC="../IMG/logo_miosito.gif" WIDTH="200" HEIGHT="64"
ALT="logo" BORDER="0">

</A>

E ora cerchiamo di renderlo più accessibile:


<A HREF="http://www.ilmiosito.it" TITLE="[Immagine - Link]
Logo del mio sito con link alla prima pagina">

<IMG SRC="../IMG/logo_miosito.gif" WIDTH="200" HEIGHT="64"
ALT="[Immagine - Link] Logo del mio sito con link alla prima pagina"
NAME="Mio_sito_logo" BORDER="0">

</A>


Nel primo caso, i tag usati sono limitati alla semplice funzione che ne
implica il loro uso: un link attivo all’indirizzo "www.ilmiosito.it"
ed un’immagine che descrive visivamente questo collegamento. La descrizione
alternativa ci spiega che è un logo, ma di cosa?

Nel secondo caso, oltre a nuovi valori impostati all’interno degli stessi tag "IMG" (immagine) e "A" (àncora — il link –), anche
lo stesso testo alternativo (ALT) è cambiato. Si è cercato di spiegare al
meglio cosa contiene e cosa significa l’elemento utilizzato.

Mentre sul link è stato aggiunto l’elemento "TITLE", che ne
descrive il tipo di collegamento e la destinazione, nell’immagine è stato
introdotto anche "NAME" per darle un nome, utile anche ai fini di una
possibile programmazione più avanzata (ad esempio usando il DHTML con
Javascript), oltre ad una nuova descrizione più completa all’interno del testo
alternativo.

In entrambi i casi, ho scelto di provare la formula più concisa e completa
(ma possono anche essere utilizzate tecniche diverse), precedendo la descrizione
vera e propria da una mini descrizione che spiega l’elemento usato e la sua
funzione.

Ora il nostro codice dovrebbe essere letto con maggior facilità.

Certamente, ogni metodo di lettura alternativo ha le sue peculiarità, le sue
necessità, le sue specifiche ed è necessario poter testare man mano il proprio
sito con tali strumenti per poter applicare le modifiche e gli
"assestamenti" più opportuni.

L’accessibilità di fatto viene vissuta come elemento "nascosto",
relegando la maggior parte del proprio lavoro al codice, ma non solo. In
effetti, oltre alla tecnica pratica di lavoro, dovremmo adottare un vero e
proprio schema mentale, da applicare al nostro lavoro o progetto. Infatti molte cose, come la nazionalità, l’età, la professione potranno
incidere nelle scelte della tecnica che poi adotteremo quando andremo ad
affrontare lo sviluppo di un progetto online.

Accessibilità: gli elementi da tenere in considerazione.

Come abbiamo visto nell’esempio appena incontrato, operare in maniera
accessibile significa completare le informazioni HTML a nostra disposizione con
informazioni più dettagliate e argomentate, relative sempre e comunque al
contenuto del sito web, ma anche al funzionamento degli elementi contenuti.

Nel progetto WAI sono state fissate tre priorità di controllo :

Priority 1 : potrebbe essere considerato lo "strict" dell’HTML
4.0, ovvero quello che si deve fare per ottenere una pagina con un livello
totale di accessibilità. La priorità sicuramente più impegnativa, sia a
livello di progettazione che a livello di realizzo.

La conformità a questo punto di controllo costituisce un requisito base
affinché alcune categorie di utenti siano in grado di utilizzare documenti Web.

La Priority 1 richiede che lo standard WAI sia applicato a:

– sito generale 

– tabelle 

– immagini e immagini mappa 

– frame 

– applet e script 

– elementi multimediali 

– form

Priority 2 : potrebbe essere considerato come il "transitional"
dell’HTML 4.0, ovvero quello che si dovrebbe fare per abbattere le principali
barriere di accessibilità nei propri progetti online. E’ una priorità
intermedia con cui si può arrivare ad un compromesso tra necessità aziendali e
necessità di accessibilità.

La conformità a questo punto consente di rimuovere barriere significative
per l’accesso a documenti Web.

La Priority 2 indica che lo standard WAI sia applicato a:

– sito generale 

– tabelle 

– immagini e immagini mappa 

– frame – 

– applet e script 

– form

Priority 3 : questo punto indica quello che si potrebbe fare per abbattere
le principali barriere di accessibilità nei propri progetti online. La
conformità a questo punto migliora l’accesso ai documenti Web.

La Priority 3 indica che lo standard WAI sia applicato a:

– sito generale 

– tabelle 

– immagini e immagini mappa 

– form

In ogni caso, uno sviluppatore web che non ha praticità con le tecniche di
realizzo, dovrebbe tenere in considerazione che (riporto dal documento ufficiale
del WAI) alcuni utenti potrebbero visualizzare il documento diversamente da noi:

– possono non essere in grado di vedere, ascoltare o muoversi o possono non
essere in grado di trattare alcuni tipi di informazioni facilmente o del
tutto 

– possono avere difficoltà nella lettura o nella comprensione del testo o 

– possono non avere o non essere in grado di usare una tastiera o un mouse

– possono avere uno schermo solo testuale, un piccolo schermo o una connessione Internet
molto lenta 

– possono non parlare e capire fluentemente la lingua in
cui il documento è scritto 

– possono trovarsi in una situazione in cui i loro
occhi, orecchie o mani sono occupati o impediti (ad es., stanno guidando,
lavorano in un ambiente rumoroso, ecc.) 

– possono avere la versione precedente
di un browser, un browser completamente diverso, un browser basato su
dispositivi di sintesi vocale o un diverso sistema operativo.

Marco Trevisan

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

Chiudi i commenti