Standard, CSS, usabilità, accessibilità. Se dovessimo condensare in pochi termini le principali tendenze del webdesign negli ultimi tre anni non potremmo fare a meno di considerare anche queste. Che dibattiti serrati e sperimentazioni di valore non siano stati sempre accompagnati da molte applicazioni 'reali', è un altro discorso e non è questa la sede per affrontare un tema così spinoso. È fuori di dubbio, comunque, che a livello di consapevolezza i passi fatti siano stati enormi. La strada verso quello che, con felice espressione, Maurizio Boscarol definisce web ecologico è oggi, sicuramente, meno irta di ostacoli.
Pur trattandosi di ambiti diversi e che coinvolgono competenze specifiche (ma spesso trasversali), l'attenzione ad aspetti come il rispetto degli standard, la separazione tra stile e struttura attuata con i CSS, l'accessibilità dei siti, hanno ridato finalmente importanza al codice e alla sua correttezza formale e logica. Una sorta di stop alla 'sbornia visualÈ inaugurata dall'avvento degli editor alla Dreamweaver o alla Front Page. Due tendenze ci paiono significative.
Da una parte i tool visuali si sono 'adeguati' alla tendenza. Pensiamo a Dreamweaver. Il programma di Macromedia è oggi in grado di produrre pagine standard (HTML e XHTML), di convalidarle, di assistere lo sviluppatore (anche con wizard) nel miglioramento dell'accessibilità. Su quest'ultimo aspetto si può vedere l'l'articoloL'accessibilità con Dreamweaver MX di Marcello Cerruti pubblicato sulle pagine di PRO.HTML.it.
Da un'altra parte, è cresciuta l'attenzione per la fase di verifica delle pagine. Ecco, dunque, la comparsa rapida di un gran numero di strumenti automatici in grado di effettuare un controllo sul codice al fine di valutarne la validità o il rispetto dei requisiti minimi di accessibilità. Si tratta in genere di tool online, con un funzionamento molto semplice. Si inserisce in una casella di testo la URL della pagina e si avvia la verifica. Il risultato sarà sempre un rapporto più o meno analitico contenente la segnalazione degli errori.
Molto si è discusso sulla reale efficacia di tali strumenti. L'errore maggiore è di considerarli giudici assoluti o dispensatori di certificazioni in ambiti in cui non possono esserlo. La verifica dell'usabilità o dell'accessibilità di un sito è infatti operazione complessa, che va ben al di là di una pura e semplice analisi del codice. Detto questo, è altrettanto indubbia la loro utilità. Questi i compiti importanti che possono svolgere:
- Sono utili nella fase di verifica preliminare del sito. Consentono infatti di analizzare il codice e rintracciare gli eventuali errori commessi.
- Sono l'unico strumento possibile per lavori a basso budget o per siti personali.
- Fanno aumentare la consapevolezza su questioni altrimenti poco valutate.
La proposta del W3C
Anche il W3C ha in qualche modo sancito l'importanza di questi tool. Nel documento Evaluating Web Sites for Accessibility propone una sorta di vademecum che accompagna lo sviluppatore nelle fasi di verifica preliminare e controllo di conformità dell'accessibilità di un sito.
Per prima cosa suggerisce di testare le pagine con i comuni browser grafici e in differenti condizioni d'uso (risoluzione, disabilitazione di immagini e fogli di stile, visualizzazione in scala di grigi, gestione del dimensionamento del testo, navigazione senza mouse). A questo argomento (il browser come strumento di test) abbiamo dedicato un Un browser a misura di sviluppatori di PRO su Mozilla, ma non va dimenticata la validità di un programma come Opera 7, che tante opzioni mette a disposizione degli sviluppatori. Nel documento si invita poi a controllare le pagine almeno con un browser vocale e uno testuale e si sottolinea l'importanza di effettuare un controllo con almeno due tool di verifica automatica.
Lo stesso W3C mantiene un documento che elenca la maggior parte di questi strumenti. Ad esso vi rimandiamo per link e brevi presentazioni. Qui ci interessa solo richiamare due delle tre categorie in cui essi sono organizzati:
- Strumenti di validazione: effettuano una verifica sul codice, segnalano gli errori in un rapporto finale e stabiliscono il grado di conformità alle norme di accesibilità (il classico bollino).
- Strumenti di verifica e riparazione: oltre al controllo consentono anche di correggere automaticamente gli errori presenti nel codice.
A questo punto possiamo passare ad una breve panoramica di alcuni di questi tool.
Validatore HTML del W3C
Un primo passo verso un sito accessibile consiste nell'avere pagine valide rispetto agli standard del W3C. Pertanto, il primo controllo da effettuare è quello con il validatore HTML. Ricordiamo che il prerequisito fondamentale per verificare il codice con questo tool è la presenza di un DOCTYPE all'inizio del documento. È con il DOCTYPE che indichiamo al validatore il linguaggio e il livello al quale vogliamo conformarci. La validazione è possibile su tutte le versioni di HTML (dalla 2.0 alla 4.01) e di XHTML.
Il rapporto finale (figura 1) inizia con l'esplicitazione del risultato, ovvero la promozione o la bocciatura del nostro codice. Se il documento risulta non valido, vengono indicati tutti gli errori e la riga in cui sono stati riscontrati. Il numero di riga è sempre un collegamento ipertestuale alla porzione del codice corrispondente, codice che viene riportato subito dopo la parte di segnalazione degli errori. Se non è chiaro il motivo della segnalazione, si ha a disposizione il link Explain, che rimanda sempre ad una spiegazione dettagliata dell'errore.
Bobby
Bobby è per certi versi il capostipite e il modello di questa categoria di tool. Attualmente è distribuito in due forme. La versione 5.0 è un coroposo programma per desktop venduto al prezzo di $299.00. La versione 4.0 (meno raffinata e precisa nei dettagli e nella valutazione del codice) sopravvive, invece, come base del servizio gratuito online, su cui è possibile testare solo una pagina al minuto.
È possibile verificare la conformità di un documento in base alle due principali fonti di riferimento in tema di accessibilità: le Web Content Accessibility Guidelines 1.0 stilate dal gruppo della WAI e le norme contenute nella Sezione 508 del Rehabilitation Act Amendments, norme che regolano il libero accesso all'informazione da parte delle persone disabili. Questo fatto è della massima importanza e ci aiuta a comprendere meglio il rapporto finale restituito da tool come Bobby.
Basta una rapida occhiata alle enunciazioni di base contenute nelle WCAG 1.0 per capire che molti dei punti da sottoporre a verifica richiedono un controllo attento da parte dello sviluppatore, non potendo essere valutate direttamente da una macchina. Bobby può certamente verificare la presenza o l'assenza del testo alternativo per le immagini, ma non potrà mai, ad esempio, valutare se il linguaggio usato è chiaro e semplice.
Diamo quindi uno sguardo ad una schermata (figura 2) di una sessione di valutazione di Bobby per comprendere meglio questo punto. Ci viene innanzitutto restituito il layout del documento con il testo. Ciò che salta subito all'occhio sono i due possibili simboli che ritroviamo in punti particolari della pagina. Sono il punto interrogativo e l'elmetto con la carrozzina. Quest'ultimo segnala sempre un errore che impedisce la conformità con uno dei tre livelli di accesibilità definiti nelle WCAG 1.0 (ricordiamo che i livelli sono tre, indicati con A, AA, AAA). Cliccando sull'elmetto ci sposteremo nella porzione della pagina (figura 3) in cui viene spiegato l'errore commesso. Cliccando sulla descrizione breve si ha l'opportunità di accedere ad una descrizione dettagliata del punto in esame (figura 4).
Il punto interrogativo, invece, segnala cose che devono essere valutate dall'autore. Non sono errori in sé, ma inviti a controllare. Anche in questo caso, il click sul simbolo ci consente di avere un quadro sintetico delle occorrenze con link alla spiegazione dettagliata.
LIFT
Di natura commerciale sono anche i tool e i servizi offerti da UsableNet, tutti raccolti sotto la denominazione di L'accessibilità con Lift per Dreamweaver. Si tratta di add-on per Dreamweaver o FrontPage e di un servizio online che effettuano verifiche, come Bobby, in base alle WCAG 1.0 e alla Sezione 508. Rimane comunque la possibilità di effettuare un test gratuito online su cinque pagine del proprio sito che il tool sceglie a partire da quella indicata nel form di immissione della URL. Il funzionamento è diverso da Bobby. Innanzitutto il risultato non è restituito immediatamente. Anche per il fatto che testa cinque pagine bisogna attendere 5/10 minuti prima di visualizzarlo. Ciò che LIFT restituisce subito è pertanto solo la URL della pagina con il rapporto.
Esso si presenta (figura 5) come un elenco dei vari checkpoint verificati e di ciascuno elenca le occorrenze (colonna Issues). Cliccando sulla descrizione del checkpoint si ha una scheda analitica con l'indicazione delle parti di codice interessate e una sintetica spiegazione. Anche qui attenzione ai simboli. Il punto interrogativo indica punti da controllare, il segnale di pericolo gli errori riscontrati. Il report rimane online per cinque giorni, ma può essere anche scaricato in formato PDF.
Delorie Lynx viewer
Un altro test che è opportuno fare è quello sulla resa della pagina in un browser testuale. Così facendo si ha l'opportunità di valutare la fruibilità del contenuto anche in assenza di ausilii grafici e di un layout che orienta la consultazione del documento. È interessante, ad esempio, notare come vengono resi i testi alternativi per le immagini, i menu di navigazione, il testo eventualmente racchiuso in tabelle. Il più comune tra i browser testuali è Lynx. Se ne può scaricare ovviamente una copia, ma grazie ad un emulatore di Delorie possiamo testare direttamente da una pagina web del loro sito. Il risultato sulla home page di PRO.HTML.it è questo (figura 6).
Torquemada
Torquemada è un tool in italiano che sta costantemente migliorando la sua qualità. Si presenta come uno strumento che "offre a chi sviluppa siti web una metodologia completa di analisi dell’accessibilità tramite uno strumento di controllo delle pagine che permette di capire velocemente quali sono le zone della pagina interessate dall’errore e il codice HTML corrispondente".
Il rapporto finale, se si sceglie quello grafico, si presenta con una finestra a tre frame. In quelli inferiori troveremo la nostra pagina e il suo codice, in quello superiore la lista dei problemi riscontrati o da controllare con l'indicazione della riga del codice. Le spiegazioni rimandano alle pagine delle WCAG 1.0 (figura 7).
A-Prompt
L'ultimo tool di cui parliamo nasce da un progetto realizzato dalle università del Wisconsin e di Toronto. È l'unico disponibile solo in versione desktop e lo abbiamo scelto come esempio di tool di analisi e riparazione. Una volta installato, A-Prompt consente di testare le pagine in base alle solite WCAG 1.0 e Section 508, ma a differenza dei programmi già visti, può essere predisposto a riparare automaticamente gli errori riscontrati. I vecchi file vengono rinominati e sostituiti da copie corrette. Il consiglio è comunque quello di non affidarsi esclusivamente a questo tipo di opzione, ma di valutare sempre, intervenendo con le proprie scelte. Sulle pagine del sito sono disponibili molti screenshots che spiegano bene funzionalità e caratteristiche del programma.
