L'Accessibilità dell'iperuranio. A quando quella reale?

Colgo la occasione di un divertente articolo di Marco Bertoni per affrontare alcuni temi a me cari riguardanti la 'Legge Stanca' e il problema della Accessibilitá così come si é andato configurando.
Bertoni, nell'articolo citato, parafrasa i punti salienti della Accessibilitá e mi permetterá l'uso delle sue parafrasi per apporre loro alcune note a margine alla 'Legge Stanca' indirizzate.

Come esergo vorrei dire che concordo con la intenzione di Marco Bertoni ma avrei preferito una chiara prefazione alle 'regole' in grado di chiarire che ciò di cui si discorre è necessario analizzarlo caso per caso e, su tutto, non perfettamente applicabile a tutti gli ambiti del Web UI Design ma solo al campo preso di mira maggiormente dalla 'Legge Stanca' e nel quale maggiormente lavora l'autore dell'articolo, cioè le Pubbliche Amministrazioni che, per fortuna, non sono l'intero web.

Questo requisito ti chiede di scrivere codice pulito, senza errori sintattici e semanticamente corretto. Che significa? Significa che bisogna finirla con il codice spazzatura ;).

Il primo requisito è un non requisito dato che scrivere codice senza errori sintattici fa parte delle best practices. E' come dire ad un dottore che deve visitare un paziente prima di prescrivere un qualsivoglia farmaco. É norma deontologica che non abbisogna di essere ribadita. Il fatto che accada il contrario non toglie la validità formale e logicamente antecedente della norma. In poche parole, la norma enuncia non un requisito ma una requisitoria. Un atto di accusa verso coloro, tanti, che hanno una formazione non al passo coi tempi.
In questo ultimo caso, si sta parlando al vento in quanto chi non cura la sua formazione sua sponte o per esigenze di mercato non coglierà a maggior ragione nemmeno questo invito dall'alto imposto. In breve, a chi si rivolge questa requisitoria?

Ma, ed è questo il punto che svilupperò più approfonditamente in altro post, non è sempre colpa del coder il risultato che vediamo. Spesso, molto spesso, viene ordinato di riusare porzioni di codice per ottimizzare sul tempo e quindi sul margine di guadagno. Il problema é quindi non di chi scrive il codice ma delle sezioni commerciali che obbligano a tempistiche strettissime promettendo mari e monti nei canonici 7 giorni della Creazione. Solo quando si sarà parlato non ai coders ma ai 'Commerciali' si riuscirà ad ottenere qualcosa. Ma, si sa, il 'Commerciale' conosce solo una lingua. La domanda è quindi, quale vantaggio economico può portare migrare consistenti blocchi di codice verso la accessibilità?
In breve, il punto in questione è un falso problema che non individua precisamente il suo target. Da rifare.

Questo requisito ti proibisce di utilizzare i frame.

Diciamolo: i frame sono brutti. Fanno tanto web anni novanta. E rompono le scatole agli screen reader. Roba vecchia e dannosa insomma. E cosa dire dei frame in linea (gli iframe)?...

Gmail usa un mare di iframe. Perchè? Perchè sono necessari al funzionamento della web application e constribuiscono a diminuire i tempi di attesa aumentando, conseguentemente, la usabilità globale della stessa. Aderire, senza residuo, alla norma porterebbe una usabilità minore e a funzionalità problematiche da implementare e fornire.
Certo, possiamo ben usare noi il DOM traversal+Ajax e ottenere quanto é da ottenere con divs ma, nondimeno, non mi sentirei di escludere apriori gli iframes quando possono dare una mano a gestire dei servizi risolvendo problematiche di HTTP request.
Se per aderire ad una regola frettolosa devo rinunciare ad offrire una piena usabilità della web application mi sa che occorre fermarsi a riflettere.

Se elimini la sottolineatura per i collegamenti e li differenzi dal testo normale solo grazie al colore, puoi creare notevoli problemi a chi è affetto da cecità ai colori, che non sarà in grado di distinguerli. Questo è un esempio per chiarire che non devi usare solo il colore per assegnare significato all’informazione.

L'informazione è data, in un layout, dalla differenziazione all'interno della griglia. In altre parole, il posizionamento fornisce informazione sulla funzionalità. Basta osservare una qualsiasi GUI su windows o Mac o Linux o Symbian o... per rendersi conto che gli strumenti sono suddivisi e posizionati in modo consistente per fornire una differenziazione percettiva immediata in base alla loro localizzazione. La stessa consistenza che occorre raggiungere, al livello di usabilità, anche sul web. Quindi sarebbe più opportuno dire di non giocherellare con il posizionamento degli elementi della User Interface e seguire le convenzioni come prima regola. Il resto viene come ridondanza. Una pagina piena di links ove il menu si confonda con il contenuto della pagina, anche se fosse pieno zeppo di underline non verrebbe immediatamente percepito nella sua funzione primaria. Con buona pace delle buone intenzioni.

Questa norma fomenta la lettura delle regole come mero elenco da spuntare di cui ho già scritto in precedenza. La verità è che il buon vecchio Web Designer deve essere innanzitutto un designer e conoscere a menadito le regole del buon design che non è cazzeggiare col Photoshop (o Fireworks o altro) ma studio degli spazi, analisi comunicativa, ridondanza accorta, canale di trasmissione, percezione, semiotica etc. Solo quando i 'web designers' si attrezzeranno con le competenze che ogni designer da per scontato varrà insistere su queste minuzie, ma allora sarà inutile perchè il problema non sussisterà .
Prima la struttura poi il dettaglio. Il dettaglio senza struttura informativa è sempre rumore. Rumore sottolineato ma pur sempre rumore.

Se ti piacciono le gif animate e le scritte lampeggianti… beh… ecco… contento tu… Ma stai molto attento alla frequenza di lampeggiamento, altrimenti rischi di danneggiare seriamente chi soffre di epilessia fotosensibile. Oltre ad infastidire tutti noi.

E il pane a coloro che lavorano per la web application chi lo paga senza la pubblicità?
Insomma, questa è una delle regole da prendere cum grano salis. Si adatta benissimo ad alcune tipologie di web site (modello 'si ma chi siamo, si ma quanti ne siamo, si ma poi che facciamo? Ci scrivi una letterina?') ma di certo non a tutte. Potrebbe andar bene in un mondo ideale ma nel mondo reale il business primario è la Pubblicità. Piaccia o meno è così. Amen.

Norma quindi da scartare se non in presenza di Siti Istituzionali, Portfolio Web Site e siti personali. Il resto continuerà ad ignorarla per il semplice motivo di cui sopra. Se i propugnatori della Legge Stanca firmassero assegno mensile a carico di questi ultimi a compenso delle perdite economiche subite dalla eliminazione dei banners potremmo vedere qualche risultato. Per ora l'unica speranza di vedere diminuire le animazioncelle nei banners è data dalla constatazione che gli utenti sono diventati ad-blinds. Se vedremo quindi un tendenza contraria sarà dovuta non al rispetto delle regole della accessibilità ma alla sostituzione dei banners con qualcosa di più efficace in termini di raggiungimento degli obiettivi economici.

Devi fare in modo che il testo possa essere ridimensionato (ingrandito). Anche con Internet Explorer 6 e precedenti (menu Visualizza > Carattere).
Quando il carattere è ingrandito non deve esserci sovrapposizione tra le diverse parti della pagina. Anche ridimensionando la finestra.
Devi usare un layout liquido (elastico).

Alla requisitoria contro il fixed layout rispondo con tre obiezioni:

• Problemi tecnici (per chi non lo conoscesse, il Visual Design Lead di Google).


• Controllo del Layout da parte del Designer.


• Problemi di leggibilità della informazione

Le norme sulla Accessibilità dovrebbero essere studiate in base alla situazione reale e non al mondo dell'iperuranio. Perchè il legislatore non mette un pò del suo zelo nello scrivere una lettera ufficiale a Microsoft invitandola a rispettare gli standards invece di legiferare a vuoto in direzione sbagliata?

Un liquid layout non è ipso facto accessibile (perchè mai dovrebbe esserlo?) e spesso si preferisce, per le tre obiezioni di cui sopra, optare per una soluzione fixed che è vantaggiosa in termini strettamente economici e di controllo del layout. Affermare che il fixed layout è da scartare a priori è quanto meno affrettata come proposizione (voglio esser buono e non pensar male circa le competenze nel campo del supporto browser agli standards dei consulenti interpellati in vista della Legge).
Per inciso, lo stesso ALA usa un fixed layout e nemmeno centrato. Se Zeldman in persona opta per questa via qualche dubbio da parte del 'legislatore' ce lo possiamo attendere. O no?

Immaginiamo poi un bel caso di un layout liquido a due colonne ove le colonne di testo della content area si estenderanno per il 90% della viewport. Dobbiamo ricordare l'abc della usabilità circa il numero di caratteri massimo su di una riga visualizzabile a video dall'occhio umano?
Immaginate lo stesso caso su di un monitor a risoluzione 1600px orizzontali.
Una catastrofe della usabilità

Un bel po’ di gente naviga con gli script disabilitati. Devi fartene una ragione. Quindi devi garantire che le tue pagine siano utilizzabili anche da chi ha disabilitato gli script, gli applet o altra robaccia 2.0.

Ma il legislatore non è folle. Se per motivi religiosi ('grassetto nostro) non puoi fare a meno dei tuoi script inaccessibili, allora dai una spiegazione testuale della funzionalità (che il 15% degli utenti si perderà ) e, come impone il requisito Tre, fornisci un’alternativa testuale equivalente.

Hai voluto lo script? E ora pedala.

Gli script però non sono il demonio. Basta leggere PPK per capire che con un po’ di competenza si può fare tutto ciò che si vuole.

Di certo gli 'script' (ma poi che vuol dire 'script'? Anche php, ruby, python sono scripts e necessitano di stare dove stanno. Nel corpo del DOM) non sono il demonio. Altrettanto certo è che questo è un problema da affrontare con molta attenzione e parsimonia di giudizi sommari da caccia alle streghe visto il vettore che sta portando le web applications (o RIA che dir si voglia) ad essere papabili sostituti delle Desktop Applications. Il libello citato è importante (non il migliore in materia) e pieno di indicazioni utili ma in applicazioni complesse (tipo Yahoo Mail) vi è poco da accusare di religiosità fondamentalista in modo aprioristico e generico. Il codice JavaScript è in line perchè ha da essere inline. Se a questo punto le strade tra usabilitá ed accessibilitá divergono occorre affrontare il problema con occhio attento al rispetto di entrambe le necessitá e non sacrificare la usabilità sull'altare della accessibilità.

Devi garantire che le funzionalità (per esempio un menu) e le informazioni (il testo) presenti negli script, negli applet, nelle animazioni Flash siano direttamente accessibili alle tecnologie assistive.

Questo significa che devi installare uno screen reader e provare a navigare all’interno della tua animazione Flash. Se qualche “esperto” ti ha detto che Flash non puà essere accessibile, mandalo al diavolo e digli di leggersi la letteratura in merito e questi articoli.

Ironia della sorte, il famigerato articolo linkato è in Flash e non supporta il mouse scroll risultando quindi non usabile dagli utenti 'normali'. Vi è poi scritto a chiare lettere che Accessibilità con Flash è sinonimo di accessibilità con Flash su Windows.

All accessible Flash content must be tested on the Microsoft Windows platform.
While there have been recent improvements to the Apple Macintosh OS 10.4
release (Tiger), includinga built in screen reader called VoiceOver, the Flash
Player does not support this screen reader.

In altre parole, su Mac e Linux ce lo si prende in saccoccia. Ora, una tecnologia si dice aderente agli standards quando aderisce, in tutti gli ambiti in cui si usa, a questi ultimi. Flash può, con molto lavoro, essere accessibile ma solo su Windows per cui non può definirsi accessibile tout court a meno di non tornare al vecchio 'IE Required' sotto mentite spoglie. Un rispetto dell'utente un attimino di parte e, cosa che non guasta, sulla piattaforma che più ignora volutamente e bellamente gli standards che non siano i suoi. Meglio JavaScript inline compatibile su tutte le piattaforme che Flash solo su Windows. Checchè ne dicano gli 'esperti'.

Ah. Questo ਠil mio preferito. Ho pure contribuito a correggere un errore presente nella prima versione dell’enunciato.

Devi sempre considerare il fatto che per chi ha difficoltà nel controllo dei dispositivi di puntamento ਠmolto difficile selezionare il collegamento o il pulsante giusto se sono troppo ravvicinati. Immagina la frustrazione quando dopo uno sforzo enorme ti scappa il clic sul pulsante sbagliato. Quando ti fischiano le orecchie, pensa alle maledizioni che ti mandano gli utenti per questa mania di appiccicare tutto. Saranno per caso carenze affettive?

La soluzione ਠsemplice: distanziare in modo adeguato pulsanti dei moduli, campi dei moduli, liste di collegamenti e, in generale, tutti gli oggetti attivi all’interno della pagina.

Io aggiungo che anche un’interlinea superiore a quella predefinita ਠmeglio. Ma so che non tutti sono d’accordo: evidentemente c’ਠchi ama i muri di testo che si vedono cosà spesso negli orribili portali di molte aziende e pubbliche amministrazioni italiane.

Differenziazione percettiva e non allargare gli spazi all'infinito. Qui é il problema.



Se analizziamo la GUI del Finder di Mac OS X, come esempio illustre, vedremo che tra una icona ed un'altra della toolbar vi è 1px di spazio ma il tutto é visivamente ben differenziato. Non occorre una spazio che costringa l'utente a fare viaggi con il mouse per spostarsi da un tool ad un altro con il risultato di diminuire la sua produttività e sminuire la usabilità del tutto, occorre invece una rimarcata differenziazione.
Amazon, dal canto suo, usa un 1px solid border con una freccia a fare da ridondanza.



Esempi classici per mostrare quanto le regole siano distanti da una effettiva presa sul reale.

É in questa attitudine al bignami frettoloso che la Legge Stanca rappresenta che dobbiamo poi ricercare le cause della accessibilità come mero bollino e elenco di comandamenti da osservare.

Mi ripeto invitando ad un mutamento di forma mentis che, solo, può assicurare un proficuo avanzamento negli studi in questo settore tanto controverso. Collaborazione e dialogo da parte di tutti i professionisti interessati e non la torre di avorio degli 'specialisti'.
Non decaloghi ma discussioni.