
guide
Tutti i linguaggi per diventare uno sviluppatore di app per Android.
Cose da evitare nella gestione di un progetto rivolto alla realizzazione di un sito accessibile
Questa è la traduzione dell’articolo Seven accessibility mistakes (part 1) pubblicato originariamente su Digital Web Magazine il 31 gennaio 2006. La traduzione viene qui presentata con il consenso dell’editore e dell’autore.
Ci sono diversi motivi per cui vengono pubblicati sul web siti non accessibili. Di uno abbiamo discusso in un mio precedente articolo: a molti clienti dell’accessibilità non importa praticamente nulla. Le loro motivazioni hanno un senso se ci si mette nei loro panni. Un’altra ragione è rappresentata dagli errori di noi sviluppatori. Fare errori è naturale, pagarne le conseguenze e imparare da quegli errori è ciò che può renderci migliori, come sviluppatori e come persone.
In questo articolo parlerò di alcuni fra i principali errori che ho dovuto affrontare nel corso della mia attività di sviluppatore web professionista. Se li terremo in considerazione nel futuro, è molto probabale che riusciremo a creare siti belli e accessibili senza tanti problemi, accontendando clienti e visitatori.
Alla fine di ogni sezione, presenterò anche una serie di suggerimenti utili ad evitare simili errori. È possibile che non tutti siano in grado di seguirli, per ragioni di budget, o perché alcuni richiedono un rapporto molto stretto con il cliente, ma tenerli presenti non può certo far male. Nessun passo compiuto nella direzione di un design fatto a vantaggio dell’utente e che tenga conto delle idee del cliente può rappresentare una perdita di tempo.
Molti strumenti di editing, framework o sistemi CMS dichiarano di poter creare
siti standard compliant e conformi al livello WAI tripla-A. Molti di
essi si limitano però a chiudere i tag HTML, a mettere in minuscolo i
nomi degli elementi generati da un editor WYSIWYG e a rispettare le regole relative
all’uso dell’attributo alt
sulle immagini. Non c’è niente
di male in tutto ciò, ma non basta.
Un codice HTML valido non è necessariamente corretto a livello semantico o logico, solo un essere umano è in grado di stabilire se lo è davvero. Non vorrei essere frainteso: ci sono strumenti di editing sicuramente validi, ma sono solo strumenti, macchine che non sono in grado di comprendere le questioni riguardanti l’interazione degli esseri umani con un computer. Le macchine non possono determinare in alcun modo se il risultato finale abbia o meno un senso, per quanto siano sofisticate. Nel bel mezzo di un progetto, poi, uno può scoprire che un certo CMS ha qualche difetto tenuto ben nascosto nei siti dimostrativi che in genere ne accompagnano la distribuzione (mi viene in mente la conformità rispetto alla codifica UTF-8 per i siti internazionali).
Diciamolo. Un sito web non rimarrà mai come era stato concepito nel progetto originale. I siti web hanno la tendenza a crescere in maniera organica, ed è proprio questo che li rende interessanti. Se non si vuole essere l’unica persona responsabile della gestione dei cambiamenti, si dovrà fare in modo che il cliente sia informato su tutti i dettagli del progetto.
Presentarsi al cliente come il supereroe dell’accessibilità che combatte il crimine di notte con il suo bel costumino è il miglior modo per fallire su tutta la linea. La questione non è che il cliente potrebbe non fidarsi di noi – sarà magari felicissimo di liberarsi di questa responsabilità. Il problema è che così facendo, si verrà coinvolti giocoforza nelle dispute interne all’azienda e ci si dovrà assumere per intero la responsabilità.
Ecco uno scenario tipico. Quelli del Marketing arrivano con del testo che è totalmente inaccessibile perché dipende in tutto e per tutto dalle immagini che lo accompagnano (forse prese da una campagna pubblicitaria portata avanti sulla stampa o in TV). Il project manager ti passa quel testo. Tu spieghi che possono esserci dei problemi e lui ti risponde che quelli del Marketing vogliono assolutamente quella cosa, e ti chiede in che modo potrebbe affrontare la questione. Tu glielo spieghi e lui dimentica questo o qualche altro piccolo dettaglio quando riferisce sul probema agli uomini del Marketing. Allora inizia un giochetto snervante, e finisce che tu perdi un sacco di tempo a ripetere cose ovvie senza concludere nulla.
La soluzione logica è di istruire il cliente il prima possibile sui problemi di accessibilità e di accordarsi sul fatto di rimanere entro certi limiti (davvero non strettissimi) quando si tratta di apportare modifiche al sito.
Questo può anche aiutarci a coprirci le spalle nel caso in cui il cliente debba affrontare qualche causa legale. Si dovrebbe sempre dire: “Ti aiutiamo a raggiungere l’accessibilità”, non “Ti facciamo un sito accessibile”.
Può accadere che noi sviluppatori, pieni di altruismo verso le persone disabili, ci dimentichiamo del contesto generale. Ma l’accessibilità è per tutti, a prescindere dalle abilità personali o dal contesto geografico. Molti di noi non avevano probabilmente mai pensato prima a cose come l’accesso da tastiera, il riconoscimento vocale o gli utenti che usano uno screen-reader. A questo punto ci sentiamo in colpa e vorremmo compensare la nostra indifferenza di prima contrastando fieramente tutto ciò che potrebbe impedire l’accesso ad un sito con uno screen-reader.
Ecco un piccolo segreto. Uno screen-reader è uno strumento che ha le sue regole di funzionamento. Molti sviluppatori web sembrano credere in tutta una serie di miti su di essi. Basta invece testarne uno, o chiedere a persone che dipendono da tecnologie assistive come li usano, cosa vorrebbero, di cosa hanno bisogno.
Non esiste, letteralmente, un modo per conoscere in anticipo il livello di abilità, la dotazione hardware e l’esperienza di chi sta dall’altra parte dello schermo. Tentando di identificare una sorte di minimo comun denominatore, non riusciremo a rendere il sito accessibile, usabile e godibile per la maggior parte dei visitatori. Non faremo altro che perpetuare la leggenda secondo cui i siti accessibili devono essere spogli e brutti.
Questi elementi di base devono essere i fondamenti del nostro sito. Se tutto gli elementi extra che inseriamo al di sopra di essi non ne inficiano la funzionalità, siamo sulla strada buona.
Aggiungere un po’ di Javascript per consentire il drag-and-drop o per aggiungere un menu drop-down va bene. Bisogna solo assicurarsi che il Javascript sia applicato soltanto quando lo user agent è in grado di gestirlo. Meglio: presentiamolo come un’opzione oppure offriamo un modo per disabilitarlo a favore di un’interfaccia più semplice.
Nel seguito dell’articolo parlerò di altri quattro errori di accessibilità che ho dovuto affrontare:
Abbiamo già discusso dei primi tre errori dei sette con che ho dovuto affrontare nel corso della mia carriera. Per l’esattezza:
Questa settimana affronteremo altri quattro scenari da evitare e vedremo come evitarli. Se il budget o i rapporti con il cliente sono un limite, queste idee potrebbero almeno suggerirvi dei metodi per guidare il cliente nella direzione di uno sviluppo che tenga al centro di tutto l’utente.
Vogliamo proteggere il nostro sito dallo spam di commenti, dallo spoofing di indirizzi e-mail e dal furto dei contenuti. Ma perché scaricare tutto il peso sui visitatori, costretti magari a dover inserire in un modulo cose che vedono – o non posono vedere – su un’immagine quando tutto ciò non fa davvero niente per proteggerli? Qualunque cosa sia generata da un computer può essere oggetto di hack di vari tipo da parte di un altro computer, basta un po’ di tempo e di impegno. Il discorso vale anche per sistemi che si presumono a prova di hack come i cd. CAPTCHA.
E perché i visitatori del nostro sito dovrebbero affrontare la compilazione di un lungo modulo solo per farci una domanda? Se riceviamo tanto spam, il problema è nostro, non loro. Certo, tutto ciò può far desistere qualche birbante capitato lì per caso e può darci modo di mettere in mostra qualche strumento di supporto del sito come la sezione di FAQ, ma comporta anche, per quanti vogliano davvero contattarci, il dover affrontare un procedimento molto più lungo e complicato del necessario. Quante volte abbiamo attaccato bruscamente il telefono dopo aver ascoltato tutte le opzioni di un sistema di risposta automatico?
È fondamentale offrire ai visitari un modo per riuscire a comunicare con noi: è il segno che prestiamo attenzione alle loro richieste e ai loro problemi. E ci copre le spalle nel caso in cui qualcuno si lamenti per il fatto di non riuscire a contattarci. In alcuni paesi ci sono addirittura leggi che obbligano a inserire su ogni pagina del sito un modo per comunicare con chi lo gestisce. In Germania, ad esempio, ogni sito deve avere un ‘Impressum’, ovvero una lista dei vari modi con cui è possibile contattare un’azienda.
Un’altra preoccupazione di cui ho sentito parlare spesso riguarda la protezione della grafica e dei testi. Appena compaiono sul web, ci sarà di sicuro qualche abile ladro che riuscirà a impossessarsene. Gli script che prevengono il click destro del mouse, le immagini coperte con una GIF trasparente e i filmati Flash messi in loop, non sono davvero misure di sicurezza. Tutto ciò che si ottiene è rendere complicata la vita dei visitatori che potrebbero aver bisogno del click destro o che non hanno il Flash player installato.
È sempre una tentazione usare tecniche di scripting client-side come JavaScript per aggirare i difetti dei browser. Uno strumento di cui si è sempre molto discusso sono i widget che consentono di ridimensionare il testo. Fanno sempre una straordinaria impressione nelle presentazioni ai clienti, i quali non mancheranno di contattarci per farci notare che i loro concorrenti lo usano sui loro siti.
I widget usati per ridimensionare la grandezza dei font sono in genere rappresentati da pulsanti con etichette tipo A, A-, A+ e A++, oppure testo piccolo, testo normale, testo grande. I tipi più bizzarri usano immagini di 10×10 pixel con testo grigio su uno sfondo leggermente più chiaro. Come può trovarli una persona che ha necessità di avere un testo piuttosto grande sulla pagina?
Tutte le soluzioni di questo tipo non fanno altro che emulare funzioni che strumenti esterni al sito dovrebbero svolgere e in effetti svolgono meglio. Avere un testo più grande non è propriamente un requisito del sito. Si tratta di qualcosa che riguarda il sistema operativo del computer ed è pertanto un problema che riguarda i produttori di sistemi operativi e di browser.
Più cerchiamo di trovare hack atti a risolvere i problemi degli user agent, meno gli utenti saranno inclini a sostituirli con strumenti migliori. Un sito web con un testo ragionevolmente grande e non espresso con unità di misura fisse, può essere ridimensionato dal visitatore usando le opzioni del browser. Se tali opzioni sono ben nascoste dietro una porta inaccessibile su cui magari c’è scritto ‘Attento al Leopardo’, allora un visitatore che ha realmente bisogno di un testo più grande non starà usando quel browser oppure ha trovato il modo per risolvere il problema. Se vogliamo davvero aiutare le persone, spieghiamo, nelle pagine dedicate alla nota sull’accessibilità, come possono ridimensionare il testo nei vari browser. Abbiamo già tante cose di cui preoccuparci riguardo al nostro sito; non proviamo a migliorare con esso i prodotti di altri.
Non sono molti i sistemi per migliorare l’accessibilità che modificano drasticamente l’aspetto visuale di un sito, e talvolta di essi non c’è proprio bisogno. Un elemento di miglioramento che potrebbe risultare necessario e che scatena discussioni furiose su forum e mailing list sono i cosiddetti ‘skip links’.
Questi link aiutano il visitatore a saltare le sezioni che si ripetono uguali su ogni pagina – come i trenta link messi sopra la prima riga di contenuto vero e proprio. Sono davvero molto utili per i non vedenti, ma aiutano anche quelli che sono legati alla tastiera per la navigazione o che navigano utilizzando dispositivi con schero piccolo come telefoni cellulari e palmari.
Ma allora che danno fa un link ‘Vai direttamente ai contenuti’ scritto con un font molto piccolo e allineato a destra invece che essere nascosto con i CSS? Molto più che un loghetto di conformità WAI-AAA è il segno che i nostri clienti hanno a cuore i bisogni dei loro visitatori.
Lo stesso si può dire per i fieldset, le label e il bordo di evidenziazione che alcuni browser aggiungono intorno al link corrente. È vero: non sempre sono esteticamente gradevoli, ma hanno una loro ragion d’essere. I fieldset, ad esempio, consentono a tutti gli utenti di capire che i campi che contiene rappresentano un’unità logica.
I link presentano stati differenti, e ha molto senso definire diversi stili di visualizzazione per ciascuno di questi stati. Personalmente mi sono sempre chiesto a cosa servisse lo stato ‘active’, e ho sempre ritenuto che esso fosse visibile per un istante, fino al caricamento della pagina linkata o fino all’esecuzione dell’azione richiamata in uno script. Non sapevo che gli user agent impostano lo stato ‘active’ sull’ultimo link visitato quando si preme il pulsante ‘Indietro’ del browser o si usa l’equivalente scorciatoia da tastiera. Ha o non ha senso?
I tempi dei clienti che non sanno nulla del web e che credono ad ogni cosa diciamo loro, sono, purtroppo, finiti. Anni e anni di produttori di software, riviste, sviluppatori dilettanti o parenti che che dicono ai nostri clienti che fare un sito è facile come cliccare con il mouse, hanno reso molto più complicato il nostro lavoro.
I clienti amano le cose visuali e si faranno conquistare molto più probabilmente da un fantastico menu drop-down che da una mappa del sito ben organizzata con estratti di contenuto che aiutino i visitatori a trovare facilmente e nel più breve tempo possibile ciò che cercano.
Di questi tempi, poi, è probabile che i clienti non siano disposti a spendere molto denaro, e vogliono risultati tangibili da subito. Workshop, formazione, sessioni di architettura dell’informazione, esercizi di card-sorting per l’usabilità e analisi della concorrenza sono tutte cose che fanno diminuire il tempo dedicato allo sviluppo, dal momento che non si mette niente in forma di codice che non sia stato valutato e meditato con estrema attenzione. Purtroppo, queste attività non producono nulla di concreto e sono pertanto difficili da vendere, è dura vedere destinato ad esse un po’ del tempo già ristretto fissato per il progetto. Sembra che la velocità del web dia l’impressione che sviluppare un sito debba essere veloce e rapido quanto usarlo. Alcuni clienti pensano che mettere su una presentazione che è simile ad un’applicazione web, rappresenti la metà del lavoro da fare.
È forte allora la tentazione di lasciar perdere e smussare ogni angolo pur di fare contento il cliente. Se lui usa solo Internet Explorer, perché perdere tempo testando il sito con gli altri browser? Se il budget in termini di tempo e denaro è già tanto ristretto, perché non sbarazzarsi del supporto per gli utenti senza Javascript nella nostra applicazione web? Dopo tutto, lo fanno anche gli altri!
La cosa triste è che tutto ciò funziona. Il cliente è felice, non c’è praticamente feedback negativo da parte degli utenti e si può andare avanti nei limiti imposti dal budget. Un successo finanziario straordinario. Ma chi usa quel prodotto merita di più. Sembra che tutti siano disposti a perdonare tutto, ma quelli che non soddisfatti, non si lamentano: semplicemente vanno via.
Questo è l’errore più insidioso da evitare, e non posso fornire una soluzione semplice. I clienti sono molto più vicini a noi rispetto agli utenti finali. Ciò che ci serve sono esempi di casi in cui una progettazione centrata sui bisogni dell’utente abbia portato molto più denaro e ha fatto crescere un’azienda senza che essa esplodesse alla fine del periodo della bolla speculativa. Se avete storie di successo al riguardo, condividetele!
Se vuoi aggiornamenti su 7 errori in tema di accessibilità inserisci la tua email nel box qui sotto:
Compilando il presente form acconsento a ricevere le informazioni relative ai servizi di cui alla presente pagina ai sensi dell'informativa sulla privacy.
La tua iscrizione è andata a buon fine. Se vuoi ricevere informazioni personalizzate compila anche i seguenti campi opzionali:
Compilando il presente form acconsento a ricevere le informazioni relative ai servizi di cui alla presente pagina ai sensi dell'informativa sulla privacy.
Capire da dove partono i principi Agile è essenziale per capire dove possono portarci e in quale modo. Ancora più […]
Tutti i linguaggi per diventare uno sviluppatore di app per Android.
Come creare applicazioni per il Web con PHP e MySQL per il DBMS.
Tutte le principali tecnologie per diventare uno sviluppatore mobile per iOS.
I fondamentali per lo sviluppo di applicazioni multi piattaforma con Java.
Diventare degli esperti in tema di sicurezza delle applicazioni Java.
Usare Raspberry Pi e Arduino per avvicinarsi al mondo dei Maker e dell’IoT.
Le principali guide di HTML.it per diventare un esperto dei database NoSQL.
Ecco come i professionisti creano applicazioni per il Cloud con PHP.
Lo sviluppo professionale di applicazioni in PHP alla portata di tutti.
Come sviluppare applicazioni Web dinamiche con PHP e JavaScript.
Fare gli e-commerce developer con Magento, Prestashop e WooCommerce.
Realizzare applicazioni per il Web utilizzando i framework PHP.
Creare applicazioni PHP e gestire l’ambiente di sviluppo come un pro.
Percorso base per avvicinarsi al web design con un occhio al mobile.
Realizzare siti Web e Web application con WordPress a livello professionale.
Ai domini di primo livello, finora indici di appartenenza geografica dei siti, o della loro collocazione in alcune categorie piuttosto vaghe, si aggiungono ora i cosiddetti .brand. Cosa significa?
Come applicare le tecniche di refactoring alle variabili per semplificare le espressioni o rimuovere le variabili temporanee inutili
La gestione dei processi in IIS6 e le differenze con le precedenti versioni
Un percorso in 16 lezioni, per entrare nella filosofia del podcast ed esaminare tecniche e strumenti per produrre e distribuire i propri contenuti audio sul Web