Innanzitutto una premessa.
Fallibilità del precedente post si riferiva ad uno dei concetti fondamentali della Scienza del XX° secolo. Mi scuso se ho presupposto un background culturale comune che, con tutta evidenza, é assente.
Il titolo del precedente post non solo quindi é consistente con le argomentazioni ma anche, a giudicare dalle risposte, con il problema in oggetto.
Nella risposta andrò a ritroso in quanto mi preme, in conclusione di questa discussione in open space, tirare le fila di quanto si é perso per strada.
Io sono uno terra terra. Per me l’importante è che il designer Flash si preoccupi una volta tanto dell’accessibilità dei suoi prodotti. Quello che desidero è che il designer sviluppi animazioni Flash applicando tutti i criteri e le tecniche di accessibilità che la sua piattaforma gli consente. Il resto verrà col tempo.
E, dato che la 'piattaforma' non esiste come un tutto unico ma ha diverse funzionalità a seconda dell'OS si cui gira, dovremmo parlare non più di Flash in modo generico ma di Flash Player su Windows (su Mac, su Linux) e chiarire questa differenza.
Ciò non é discussione oziosa ma impatta sul lavoro quotidiano e sull'output. Inutile dare il via libera ai Devs (e qui parlo da Project Manager) sull'uso di una tecnologia sicuri della sua aderenza agli standards della accessibilità se poi, a conti fatti, è accessibile solo su di un OS. Sarebbe come dare il via libera sull'uso delle specifiche del CSS 3 che sono disponibili solo su Safari. Bello, certo. Peccato che solo gli utenti su Safari potrebbero vedere il tutto. Il resto? Si fottano.
Quindi, si é ritornati, come avvertivo, al vecchio e caro IE Required sotto nuova forma. Flash Player 9 for Windows required. Bella accessibilità, davvero.
Stiamo parlando di standards o mi sono perso qualche cosa? Che standard é qualcosa che funziona solo su di un OS?
Personalmente non ho dato né darò, stando così le cose, l'assenso all'uso di tale tecnologia andando a raccontare al Cliente la balla della accessibilità garantita. Questione di onestà professionale.
E’ vero che il tiro al Bill Gates è sempre stato, e spesso a ragione, lo sport nazionale. Ma non si dovrebbe dimenticare che Microsoft, in materia di accessibilità delle applicazioni, si è mossa per prima e che solo recentemente Apple e Mozilla hanno migliorato i loro prodotti nel senso dell’accessibilità (consentendo, per esempio, agli screen reader Jaws e Window-Eyes di utilizzare Firefox). Quindi i rimproveri, se ci sono, andrebbero indirizzati ai competitors di Microsoft.
Ma vi peritate di usare tutti i sistemi operativi di cui pure discorrete oppure questo vezzo é solo a carico dei GUI designers?
VoiceOver é presente su Mac OS X da Tiger, id est dal 2005 (non proprio 'recentemente' quindi). Già che siete sul quella pagina date una occhiata a tutto ciò che OS X offre in materia di accessibilità.
VoiceOver fu sviluppato in House di gran carriera proprio per sopperire all'abbandono del mercato Mac da parte dell'unico screen reader dedicato allora disponibile. Nel Giugno 2003 ALVA Access Group annunciò la sua volontà di abbandono del software in questione. Nel Novembre 2003 Apple si mise in moto assumendo ingegneri specializzati per la costruzione di una soluzione in house.
Panther (OS X 10.3) era appena stato lanciato sul mercato (Fine Ottobre 2003).
In altre parole, la versione immediatamente successiva, Tiger appunto, aveva VoiceOver e tutto il resto nel sistema integrato.
Se ci si peritasse di documentarsi su piattaforme diverse dalla propria staremmo tutti un pò meglio, informaticamente parlando.
La posizione di Bertoni circa la accessibilità su Mac é palesemente non informata dei fatti.
Ma, oltre quanto sopra affermato, vi é poi un altro bel problema. L'assunto che dovrebbe essere il Sistema Operativo a consentire
..., per esempio, agli screen reader Jaws e Window-Eyes di utilizzare Firefox
é quantomeno peregrino.
Un OS espone delle API sulle quali i produttori di SW/HW si basano per costruire le loro applicazioni. Le API di OS X sono a disposizione di chiunque dato che la iscrizione alla Apple Developer Connection é gratuita. Apple non ha da permettere alcunché dato che é tutto a disposizione.
Ogni software per OS X può accedere a VoiceOver per il semplice fatto che VoiceOver é un servizio di sistema sempre attivo nel menu 'Servizi'.
Manca all'appello solo la volontà di Devs terze parti. Dove sono quelli di Jaws?
Jaws for Windows (il suo nome completo. Da non dimenticare). Jaws non funziona su Mac se non attraverso ambiente di virtualizzazione (80€ di software di virtualizzazione + Licenza Windows XP + 1GB RAM aggiuntiva per far funzionare in modo fluido la macchina di virtualizzazione. Somma: 240€). Perché Jaws tratta i diversamente abili su Mac come cittadini di infima categoria? Forse perché non investono in una piattaforma con il 12% di market share ritenendola, giustamente, non profittevole? Si sta forse dicendo che i diversamente abili devono essere considerati cittadini a tutti gli effetti ma solo se usano Windows? Insomma, tutti sono uguali ma alcuni sono più uguali degli altri.
(nota: il web site Jaws é quanto di più inusabile possa capitare sul web)
Il fatto che tu continui ad affermare che “Un pixel di differenziazione basta ed avanza” mi fa pensare, non te la prendere, che tu non abbia grandi esperienze concrete con persone con disabilità motorie. Anche se affermi il contrario, continui a dimenticare l’oggetto dell’accessibilità: il disabile. Ti propongo un esperimento: prova ad attivare un normale pulsante di un form (posto ad un pixel di distanza da un altro) con l’emulatore di mouse, le mani dietro la schiena e usando la bocca (con una matita o una bacchetta qualsiasi) per interagire con la tastiera. Non dico che non ci riuscirai, ma forse ti sarà più chiaro il perché le associazioni di disabili motori hanno chiesto di incrementare queste distanze.
Prima, due concetti due dell'ABC del GUI Design.
Hotspot: La porzione del cursore che deve essere posizionata su di un screen object prima che il click del mouse abbia un qualche effetto, a prescindere dal trigger (onMouseOver, onClick a così via) dell'evento.
Hot Zone: Gli screen objects hanno delle hot zones che sono le aree nelle quali l'hot spost del cursore deve entrare per poter ottenere una registrazione di un evento sulla GUI.
la prima immagine mostra una mini navbar con due bottoni così come viene visualizzata dall'utente. 1 solo px divide visivamente i bottoni.
La seconda immagine mostra le hot zones pronte a catturare gli onMouse Events. Ogni button ha i suoi margini sull'asse orizzontale settati a 10px. L'effetto é semplice da realizzare con un pò di CSS padding e margin sul tag a della ul.
Abbiamo ben 20 pixels di spazio di errore in orizzontale. L'esempio mostra come anche lo scostamento diagonale, tipico del non pieno controllo degli arti motori, sia preso in considerazione. Infatti il padding sul tag a si spinge a coprire l'intero ingombro verticale del button invece di accontentarsi di circondare con padding regolare su tutti i lati del rettangolo il link.
La terza immagine é la stessa mini navbar come verrebbe visualizzata se seguissimo le tavole delle leggi da Bertoni indicate.
Le differenze sono sostanziali. In questo ultimo caso abbiamo una perdita di consistenza della UI con autostrade a separare i buttons e conseguente griglia irrimediabilmente persa.
Ciò detto vale anche, ad esempio, per l'ergonomia di uno strumento che usiamo ogni giorno al comupter. La tastiera.
Ciò che più ci preme, in tutto questo, é che la UI rimane usabilissima e consistente (oltre che gradevole alla percezione) per entrambe le tipologie di utenti. Non si sacrifica alcuno sull'altare dell'altro. Questa é al mio paese, diverso a quanto pare da altri, uguaglianza di trattamento. Troppo facile distruggere la usabilità di una tipologia di Utenti per favorirne un'altra. Soluzione sommaria e per nulla aderente ai principi base del buon UI Design.
Se ti fa male un braccio, taglia anche l'altro! Pare dirci questa attitudine.
Che ne direste di usare direttamente Lynx?
Per inciso. Avevo contestato la affermazione riguardo i collegamenti della regola 4. Bertoni cambia le carte e propone come esempio un form button che non é un collegamento.
Il form button deve avere padding maggiore di un tool in quanto é usato in contesti dove si richiede all'Utente una scelta precisa foriera di risultati non recuperabili. Il tipico esempio é la finestra di dialogo della installazione di un software. Sono due contesti di interazione Uomo-Macchina diversi che prevedono diversi approcci all'UI Design.
Sarà certamente che io manchi di esperienza pratica con persone con disabilità motoria ma dall'altra parte non é che si stia meglio in UI Design. Sia detto senza offesa. Ad ognuno il suo campo, per carità!
Torniamo, finalmente!, alla questione fondamentale e alle domande da me poste.
Le risposte date hanno, c.v.d., dimostrato, come se ce ne fosse bisogno, che le norme sulla accessibilità sono state pensate ad uso e consumo delle PA e, in ultima istanza, non devono essere prese in considerazione dal settore business perché le norme non prendono in considerazione quest'ultimo come fattore.
Ma, e questo é il punto, non si va raccontando e sbandierando la necessità di considerare i diversamente abili come cittadini di prima classe al pari degli altri? E, domando, i cittadini di prima classe vanno in giro solo per i siti delle pubbliche amministrazioni? Non avranno anche essi altri desideri, curiosità, insomma necessità simili a quelle degli altri utenti? Oppure si immagina la loro vita relegata tra casa e PA?
Dietro la retorica del terziario avanzato si cela, come spesso accade, un giro di parole che, almeno a me, pare più offensivo del silenzio in materia.
Considerali come uguali, con le opportune specificità, non significa considerare il flusso reale della loro vita in rete e non quella da laboratorio?
La mia domanda mirava appunto a rendere reale la applicazione delle norme sulla accessibilità. Per far questo vi é però bisogno di partire da due esigenze:
- Le esigenze reali degli utenti diversamente abili in rete
- Le esigenze del business in rete
Trovare un punto di incontro tra le due. Questo richiedevo, inutilmente purtroppo.
Modificare le norme e renderle meno fondamentaliste tenendo conto di entrambi i fattori non invoglierebbe quei Project Managers di cui abbiamo discorso (se non i commerciali) a portare i blocchi di codice su standards accessibili? Ora come ora essere accessibile significa morire commercialmente per una web application che fa del business la sua raison d'etre. Tra un 'inutile pensare alla accessibilità tanto questo prodotto non sarà mai accessibile a meno di aderire a norme draconiane' a 'facciamolo! costerà fatica ma immagina consegnare un prodotto business oriented che sia anche accessibile!' mi sa che passa una bella differenza. Almeno ai miei occhi.
Questo e solo questo ho richiesto.
Compreso che si é interessati solo alla propria parrocchia (che fornisce il pane ed il companatico e quindi da difendere, per entrambi) e che i miei presupposti sono, purtroppo, esatti, torno ai miei sollazzi personali.
ps. delle ventidue regole comunque sono baggianate quelle in questa sede dimostrate tali. Sarebbe onesto riscriverle cambiando, già che ci siamo, il titolo del post originale.