Accessibilità e Markup: Miti
a cura di William Ghelfi <w.ghelfi@agiletec.it>
versione 0.1
ultima revisione 2007/03/18
Scopo del Documento
Scopo del presente documento è fornire una rapida e sintetica panoramica di alcuni miti riguardanti i fantomatici e temuti "vincoli dell'Accessibiltà".
L'intero documento è scritto pensando ad un pubblico di lettori "amici & camerati", senza quindi preoccuparsi troppo di apparire in alcune espressioni magari un po' troppo pungenti.
Speranza del presente documento è chiarire alcuni punti che possono essere cristallini per alcuni ma giocoforza un po' oscuri per i meno interessati a specializzarsi nella scrittura di markup.
Mito I
Usare XHTML 1.x (Strict) e CSS è un vincolo di accessibilità.
FALSOXHTML + CSS sono la coppia di strumenti più potente esistente al momento per scrivere layout e contenuti di qualità.
Consentono letteralmente bizzeffe di feature, non ultima la multicanalità.
Multicanalità nativa, non ottenuta a prezzo di sacrifici umani e patti col demonio.
Con lo stesso documento XHTML e variando il foglio di stile di può ottenere nativamente il supporto per:
all. Il CSS si applica a tutti i dispositivi di visualizzazione.
screen. Valore usato per la resa sui normali browser web.
print. Il CSS viene applicato in fase di stampa del documento.
projection. Usato per presentazioni e proiezioni a tutto schermo.
aural. Da usare per dispositivi come browser a sintesi vocale.
braille. Il CSS viene usato per supporti basati sull'uso del braille.
embossed. Per stampanti braille.
handheld. Palmari e simili.
tty. Dispositivi a carattere fisso.
tv.Web-tv.
Inoltre un sito scritto in XHTML 1.1 + CSS è immensamente più facile da manutenere di un sito scritto in HTML 4.01.
Mito II
Un layout scalabile è un vincolo di accessibilità.
FALSOUn layout scalabile è nella pratica, semplificando, un layout scritto con le "colonne" in percentuale e i caratteri in em.
Un layout può essere definito scalabile, empiricamente (ingegneristicamente, se preferite) parlando, se si comporta discretamente bene e senza "esplodere" da risoluzioni di 800x600 fino a 1600x1200.
Questa viene in gergo definita "robustezza" di un layout.
Un layout robusto serve ad essere comodi con la propria pagina o applicazione web, a prescindere dal luogo in cui ci si trova e dal monitor con cui si ha a che fare, e a prescindere da quante finestre non massimizzate teniamo aperte ed affiancate nel nostro desktop.
Serve inoltre, quando si va a cena col Presidente della propria Corporation nel suo chalet a Cortina, e l'unico monitor disponibile è un 14" full-optional che racchiude GPS, telefono satellitare, lettore DVD, playstation, e terminale per rimanere in contatto con gli affari, a non fare una figura barbina perché il layout della Intranet per fortuna che l'abbiamo fatto scalabile.
Mito III
Un sito che funziona anche senza javascript è un vincolo di accessibilità
FALSOUn sito che funziona a prescindere dal supporto per javascript, è un sito che funziona e ci permette di continuare a lavorare anche quando:
nel mezzo di una presentazione gli aggiornamenti automatici di Windows installano l'ennesima patch di sicurezza che ci disattiva da Internet Explorer il supporto per gli script
ho la batteria del laptop agli sgoccioli e avvio Linux in modalità solo testo per controllare la posta aziendale via web tramite il mio browser testuale
l'ultima volta che ho tenuto attivato javascript, il sito vagamente illegale che ho "visitato per caso" mi ha formattato il pc
Poi, se il sito funziona a prescindere dal supporto per javascript, ci monto sopra un po' di javascript per fare gazzosa e insaporire ulteriormente la pietanza.
Mito IV
Un sito che se ne sbatte dei 3 miti precedenti è molto più veloce e facile da realizzare e manutenere
FALSOUn sito che se ne sbatte dei 3 miti precedenti è un'accozzaglia inutile di righe di markup, difficile e lentissimo da realizzare, e impossibile da manutenere perché privo di qualsivoglia progettazione o applicazione di pattern.
E' un sito che deve essere riscritto interamente ogni volta che il cliente richiede una piccola misera modifica.
Mito V
Scrivere un sito a norma Stanca è vincolante e difficile quanto scrivere un sito Accessibile e basta.
FALSOUn sito a norma Stanca è un sito che rispetta 22 Requisiti per la maggior parte scritti male e di dubbia interpretazione.
Ci sono sottointesi che non sono scritti nero su bianco ma derivano come dirette conseguente dall'applicazione di due o più Requisiti insieme.
Ci sono frasi contraddittorie anche all'interno di uno stesso Requisito.
Un sito Accessibile e basta è invece un sito "comodo" per un generico disabile, è un sito privo di barriere inutili.
Barriere che non si è dovuto rimuovere perché non c'era neanche bisogno di metterle.
Mito VI
Un sito di qualità, agile, manutenibile, scalabile, è Accessibile
VEROAlla prova dei fatti, se nella progettazione e nell'implementazione non si tiene assolutamente conto dei "vincoli dell'Accessibilità", ma ci si concentra esclusivamente nel fare un lavoro di qualità, agile, manutenibile, scalabile, integrabile... il risultato finale sarà senza il minimo sforzo aggiuntivo anche comodo per un generico disabile, e quindi in buona percentuale Accessibile.
Mito VII
Esiste una via di mezzo tra un sito "Mito VI" e un sito scritto col Dreamweaver
FALSOPoche spiegazioni, non esiste una via di mezzo.
O si fanno le cose bene e pensando a prepararsi a mantenere la qualità anche quando sarà il momento di fare modifiche, oppure ci si tappa il naso e ci si affida totalmente agli automatismi invasivi del Dreamweaver. Senza. Mai più. Minimamente. Poter tornare indietro. Di un mezzo passo.
MITO VIII
Chiedere a un cliente se gli interessano i "vincoli dell'Accessibilià" ed esultare quando risponde schifato "no" è un autogol
VEROPer i fatti di cui al Mito VI, esultare per una cosa del genere significa da una parte non aver capito cos'è la qualità dell'area "markup" del nostro lavoro, e dall'altra dare una sprangata sulle palle al morale di chi quella qualità cerca di mettercela in ogni cosa che fa perché tiene all'azienda.
