Ecologia dei siti web.net

7 novembre 05

Il fantasma del codice valido

Nella lista di discussione del gruppo di lavoro che sta preparando le wcag 2.0 si è riacceso il dibattito su come dovrebbe essere considerata la validità del codice nelle nascenti linee guida.

Il wai ha sospeso la stesura della linea guida 4.1 per approfondire la questione, attraverso il lavoro di un sotto-gruppo che deve raccogliere le istanze pro e contro. Lo stato della discussione è riassunto nel documento Validity and accessibility.

Affrontare tutti gli argomenti sarebbe lungo, ma ci sono alcune posizioni che meritano di essere riportate.

Premessa: la validità è preferibile

Anzitutto, precisiamo che avere pagine valide è cosa buona e giusta, per ragioni già riportate nel mio libro. Tuttavia, qui la questione non è se tentare di fare pagine valide (certo che sì), ma se considerare la validità come un requisito fondamentale e addirittura preliminare dell’accessibilità.

E dunque, se inserirlo al livello 1 di priorità delle Wcag 2.0 (nelle wcag 1.0 era al livello 2), o addirittura se inserirlo come requisito fondante dell’accessibilità nelle singole leggi nazionali, come ha fatto la nostra legge Stanca, inserendolo addirittura come primo dei 22 requisiti tecnici.

Validità come prerequisito dell’accessibilità?

In altre parole, la domanda è: può esistere accessibilità anche in assenza di codice valido, oppure se il codice non è valido, per qualunque motivo, anche per il più banale, allora di per sé la pagina presenta problemi di accessibilità?

Per rispondere a questa domanda sarebbe sufficiente creare una pagina non valida che tuttavia non abbia problemi di accessibilità. Ed è per questo che ho creato a suo tempo questo esempio di pagina non valida, e tuttavia senza evidenti problemi di accessibilità (se ce ne fossero segnalateli).

Non solo: a mio parere esistono versioni valide della stessa pagina che possono essere meno accessibili della corrispondente non valida, anche se ovviamente il caso migliore di tutti è quello in cui la pagina sia contemporaneamente valida e accessibile, con codice ben strutturato e semanticamente significativo.

Dal punto di vista logico la questione sembrerebbe risolta: seppure importante e desiderabile, la validità del codice non è requisito indispensabile dell’accessibilità, nel senso che non è vero che ogni volta che una pagina non è valida allora essa è anche inaccessibile. Eppure le discussioni continuano senza sosta, con animosità degna di miglior causa.

Qual è l’origine dell’equivoco? Probabilmente sono molte.

Autorizzare le violazioni?

Anzitutto, qualcuno ha l’idea che omettere la prescrizione di validità come prerequisito in un documento ufficiale del w3c significhi sconfessare il lavoro di chi ha scritto le DTD, e “autorizzi” di fatto le violazioni.

L’argomento è fallace, perché un’omissione non è un’autorizzazione. Ma soprattutto perché non è compito delle wcag rilasciare patenti di legittimità: le wcag dovrebbero occuparsi esclusivamente di abbattere le barriere all’accessibilità dei contenuti. Se la validità è una barriera, allora dovrebbero indicarla. Altrimenti no.

L’errore logico più comune che si vede compiere è però un altro. Per alcuni, il fatto stesso che talora problemi legati alla validità si traducano in problemi di accessibilità (ad esempio con l’omissione degli attributi alt, o con tabelle mal strutturate, ecc.) dimostrerebbe che la validità è indispensabile all’accessibilità, e che le wcag 2.0 non potrebbero farne a meno.

Cause, effetti, covariazioni

Questo è un evidente errore di attribuzione causale. Non è infatti la mancata validità a causare problemi di accessibilità: è la mancata presenza di attributi alt, o la cattiva strutturazione delle tabelle (per restare ai due esempi fatti) che provoca entrambi i problemi!

Insomma, ciò che crea problemi di accessibilità in quei casi provoca anche un problema di validità.

Se questo è vero, le wcag 2.0 non dovrebbero proprio porsi il problema del rispetto o meno della validità, ma semplicemente di identificare tutti i problemi che riguardano l’accessibilità (quello è il loro vero compito): è a questo che dovrebbero servire tutte le linee guida messe assieme.

Alcuni di questi problemi, poi, causano anche problemi di validità: ma altri no. Eliminare così ogni confusione concettuale fra validità e accessibilità aiuterebbe a concentrarsi solo sui problemi rilevanti.

Per capirci, il fatto che manchi un attributo alt il più delle volte viola già la linea guida 1.1 – a meno che l’equivalente testuale non sia meglio espresso in qualche altra forma.

Così una tabella mal strutturata rende illeggibili i dati perché la struttura dei dati non è chiaramente definita (violando anche la linea guida 1.3) e i contenuti risultano poco leggibili (linea guida 3.1).

Non serve affatto soffermarsi sulla validità, se le linee guida sono scritte bene e identificano tutti i problemi di accessibilità!

Un tipico problema di correlazione

Il problema assomiglia molto ai tipici problemi di correlazione nelle metodologie della ricerca. Quando si nota che due fenomeni, A e B, covariano, spesso è difficile dire se è A a causare B, o B a causare A. Può essere vera anche una terza ipotesi, e cioè che ci sia un terzo fenomeno, C, che non abbiamo preso in considerazione e che determina sia A che B.

In questo, caso, A e B sono validità e accessibilità. Sappiamo che talvolta covariano: nel senso almeno che la mancata validità a volte si accompagna a problemi di accessibilità.

Il problema è che quando covariano, lo fanno perché a influenzare entrambe è un terzo problema (o una serie di problemi): ad esempio, la mancanza di un equivalente testuale (che è un requisito di entrambe). O la buona strutturazione di dati tabellari (requisito di entrambe).

In altri casi ancora, ci sono errori che influenzano solo uno fra A e B. Ad esempio, la mancata chiusura di un tag META, o un carattere non legale, o un attributo border nelle immagini con una DTD strict, il più delle volte non provoca automaticamente problemi di accessibilità.

Ciò che dovrebbe preoccupare dunque gli estensori delle wcag 2.0 è che le altre linee guida identifichino davvero tutti i possibili problemi di accessibilità, sia che il codice sia valido, sia che non lo sia. Alcuni di questi saranno correlati a problemi di validità, altri no. Ma non c’è ovviamente alcuna ragione per inserire la validità come tale come prerequisito di accessibilità. Anzi, da un certo punto di vista è persino un errore, perché non è la validità, ma gli specifici problemi di accessibilità, che contano¹!

E la legge?

Per gli stessi motivi dovrebbe essere chiaro che è un errore (concettuale, prima ancora che metodologico) inserire l’obbligo di codice valido fra i requisiti tecnici dell’accessibilità, perché equivale a fare un’affermazione falsa: è infatti come dire “se la tua pagina non è valida, stai sicuro che non sarà accessibile”.

E’ corretto invece consigliare la validazione come metodologia di verifica rapida dell’accessibilità in fase di sviluppo, considerando che esiste una certa correlazione fra i due fenomeni.

Ma usare una certa misura come stima non dovrebbe portare all’errore concettuale di considerare quella misura ciò che non è: un prerequisito dell’accessibilità.

La legge italiana e il problema dei CMS

Il problema è ovviamente tanto più grande quanto più consideriamo che, in nome di un errore concettuale, la legge assegna ai prodotti di gestione dei siti (come i CMS o taluni framework di sviluppo) che producono codice valido un enorme vantaggio di mercato rispetto ad altri che hanno minori controlli su questo punto, ma magari hanno altri pregi sotto altri punti di vista.

Intendiamoci: l’ideale sarebbe che, in un prossimo futuro, tutti gli strumenti di gestione dei siti avessero le stesse capacità di produrre e garantire codice valido, senza che questo fosse un obbligo di legge. Ma intanto alcuni prodotti hanno vantaggi su altri per effetto di un errore concettuale riportato nei requisiti tecnici.

E se la validità fosse il vero obiettivo?

Se invece l’obiettivo è la validità in quanto tale, usare come alibi l’accessibilità è fondamentalmente errato. Se l’obiettivo è avere in futuro solo codice valido (ad esempio per favorire il web semantico) è molto più importante fare pressioni sui produttori di CMS o di framework di sviluppo perché migliorino la capacità di garantire automaticamente codice valido, piuttosto che obbligare i gestori di siti della PA a produrre solo codice valido in assenza di un numero sufficiente di prodotti per tutte le esigenze in grado di garantirlo!

Si sta insomma verificando in Italia quello che avevo paventato in tempi non sospetti (correva il gennaio 2004…): che gli unici a trarre sicuro vantaggio dalla legge potrebbero essere proprio i produttori di CMS accessibili. Buon per loro. Ma se consideriamo che alcuni di questi hanno attivamente collaborato alla scrittura della legge, be’, la cosa non può che lasciarci perplessi – al di là dell’indubbia competenza di costoro e della certa qualità dei loro prodotti.

Le prospettive

Nel gruppo di lavoro delle wcag 2.0 la discussione è ancora in corso, e assume talvolta (come è capitato anche qui in Italia) i toni di una vera e propria guerra di religione, dove si commettono errori logici, dove si tende a considerare solo ciò che conferma le proprie ipotesi, e dove si omette di rispondere a domande anche piuttosto semplici.

Le decisioni del working-group, naturalmente, verranno prese in considerazione della rilevanza dei fatti a supporto dell’una o dell’altra tesi, e non certamente del numero dei loro sostenitori, o dall’insistenza con cui certi argomenti vengono affrontati. Da parte nostra non ci rimane che rimarcare i nostri argomenti, che ci paiono sufficienti a convincere chi non ha interessi da difendere ed è sufficientemente distaccato sull’argomento. Il tempo dirà se quella che è solo una correlazione parziale porterà ad un errore di attribuzione causale autorizzato anche da documenti ufficiali.

¹ Tranne nel caso che si usi il mime-type application/xhtml+xml, ma questo è un caso particolare legato alla specifica tecnologia, e come tale va segnalato nei documenti tecnici; di questo parleremo in un successivo articolo.

Sezione: blog - Argomenti: accessibilità, (x)html |

Commenti:

— sofia 7 11 2005 - 15:49 # Da un lato concordo con le tue considerazioni. Dall’altro noto che ormai, in Italia, accessibilità e codice valido stanno diventando sinonimi.
Almeno tra chi ha un approccio amatoriale alla questione, gli altri 21 requisiti vengono considerati quasi opzionali, mentre l’unico che conta sembra essere lo strict validato (mi raccomando senza tabelle!).

In più, che si tratti di tag soup o di un name dal sen sfuggito, pare non faccia nessuna differenza…

Che dire: bravo… a me questo argomento di discussione mi ha esaurito perché vedo che non c’è modo di farsi capire… se tu ce la fai oltreoceano, bravo due volte.
— Maurizio 7 11 2005 - 23:43 # Quanto dici dimostra una volta di più l’importanza di non confondere validità con accessibilità. Sono cose diverse che hanno delle determinanti in comune.

All’estero non è che lo capiscano meglio che qui, e non credo di convincere nessuno. Confido solo che chi prenderà le decisioni abbia il chiaro quadro del problema.
— Peppe 8 11 2005 - 00:34 # Maurizio, sai bene che condivido il tuo punto di vista ma, come dice Sofia, ormai si parla di standard e di validità del codice dandogli il nome di accessibilità.
E sembra proprio che ormai questo sia lo stato delle cose…così è deciso, punto e basta.

Ho visto in giro dei corsi che trattano principalmente argomenti come xhtml e css; se il mio obiettivo è creare pagine web mi iscrivo a uno di quei corsi e sicuramente imparo tutto quello che c’è sapere. Alla fine del corso sostengo un esame e ho le carte in regola per fare lo sviluppatore xhtml/css.
Ma qui viene il bello, se supero l’esame sarò un esperto di accessibilità e potro spendermi come tale.
Ma che voglio di più?!? :(
— Elisabetta 10 11 2005 - 12:17 # Personalmente concordo con Maurizio su quasi tutto ciò che ha scritto.

Dico “quasi” perchè, in realtà, non sono dell’idea che sia stato uno sbaglio inserire la validazione del codice come requisito della legge.

E’ vero, un rischio evidente c’è (codice valido = accessibilità) ma, allo stesso tempo, vedo anche la possibilità di aumentare la quantità di sviluppatori che, costretti dalla legge, scriveranno codice valido e, forse, continueranno a farlo.

E comunque, se voglio fare un sito accessibile seguendo la Stanca, il primo requisito è solo l’inizio del lavoro.

Purtroppo, nelle liste, ci si è quasi scordati degli altri 21 ed è questo, secondo me, il vero sbaglio: non aver inserito l’obbligo del codice valido ma far “passare” che quello sia il requisito più importante.
— Maurizio Boscarol 10 11 2005 - 13:58 # Non è così semplice. Se ci si è scordati degli altri 21, è anche per l’effetto di polarizzazione di questo primo, che è il più oggettivamente verificabile (sugli altri è meno facile contestare). Dunque il bias è introdotto dalla differente natura dei requisiti.

Inoltre l’argomento del “così obbligo gli sviluppatori a fare codice valido” è esattamente quello che sostengono i fautori del requisito. Ma il punto è che non ha senso: se il mio scopo è obbligare qualcuno a fare qualcosa, faccio un provvedimento apposta. Sennò sto dividendo surrettiziamente il mondo fra buoni e cattivi con il pretesto dell’accessibilità. La legge non deve avere effetto pedagogico sugli sviluppatori, ma produrre siti accessibili nei limiti degli strumenti attuali.

Infatti l’ultimo problema è proprio questo: magari bastasse che gli sviluppatori scrivessero codice valido. In realtà il problema sono gli strumenti di gestione (CMS e framework) che non sono al momento ancora sufficientemente adeguati. Sono quelli che consentono o non consentono di rispettare il req. 1. E chi li ha già in casa con licenze pagate per i prossimi anni che fa?

Se per il futuro si vuole il codice valido, bisogna fare opera di pressione sui suddetti produttori di CMS.

Ma a monte c’è la domanda: perché si vuol essere così rigidi con il codice valido, quando sappiamo benissimo che anche siti con piccoli errori possono essere accessibili? Perché si è stabilita questa correlazione fittizia? Perché il codice valido è stato inserito fin da subito nelle WCAG 1.0, dunque è diventato “sinonimo” di accessibilità. Invece è una correlazione creata ad hoc.

Meglio valido, sia chiaro: e non necessariamente per l’accessibilità. Ma la legge imponendolo crea una situazione di mercato improvvisamente sbilanciata a favore di certi prodotti. Cioè interferisce con il mercato. E sta “ammazzando” provvedimenti e requisiti che per i disabili sono probabilmente più importanti. Il motivo vero ancora non lo vedo: è ideologico, è una specie di “siamo meglio noi che lo facciamo valido, abbasso tutti gli altri”. Ideologia, appunto. Tanto che sono certo che sono tutti in buona fede (be’, quelli che non hanno interessi personali nella faccenda, almeno…).
— Maurizio Boscarol 10 11 2005 - 14:06 # Inoltre aggiungo che un conto è dire “è utile validare il codice mentre si fanno le pagine web”, un altro è dire per legge “le pagine devono assolutamente essere valide”. Nel primo caso dici di usare uno strumento in un processo, nel secondo fai passare dei guai a chi, per un motivo qualunque, ha anche solo un errore di codice.

Anche se la validità è desiderabile, non è un buon motivo per mettere fuori legge le pagine non valide, insomma… E con il pretesto dell’accessibilità, poi. Ma, ovviamente, se usavano il pretesto della “qualità” (che sarebbe stato più appropriato) chi si voltava?
— Michele Ledda 12 11 2005 - 19:47 # Ciao Maurizio,
come te e tutti gli altri qui dentro ho partecipato a numerose discussioni sul tema senza che mai si arrivasse a delle conclusioni che avessero un ampio consenso. Probabilmente perchè il problema è decisamente vasto e complesso da affrontare. Quello che dici tu nell’articolo è condivisibile a patto che come tu stesso accenni sia chiaro in cosa l’invalidità del codice impatta sull’accessibilità. Ricordo che Roberto Scano in una discussione in cui evidenziavo che il codice di un sito pur non essendo valido per motivi futili (br non chiusi, & al posto di ANDamp;) non mi sembrava assolutamente inacessibile; la sua risposta fu “e allora cosa facciamo la lista dei tag buoni e di quelli cattivi?”.
E’ qui il punto chiave di tutto. Dire che il codice deve essere valido punto e basta evita di andare a capire l’impatto reale della sua invalidità sull’accessibilità.
L’invalidità è quanto di più semplice da verificare, l’accessibilità ci devi sbattere il muso in modo decisamente più approfondito solo per poter dire che ci hai capito qualcosa.
E’ vero ora il focus è molto puntato sul codice, cosa serva per andare oltre francamente non lo so. Mi viene solo in mente che sappiamo poco di cosa realmente serva e utilizzino i disabili per navigare minimizzando i problemi che si possono riscontrare.
E’ come se avessimo un’autostrada davanti, ma con molta strada ancora da fare.
— J 16 11 2005 - 12:04 # Mi permetto di dire solo alcune considerazioni, solo una decina di scroll, e giusto per presenzialismo :-)

Sono sempre stato contrario alla validità del codice, perchè concordo che per alcuni sia stato il fine e non il mezzo, e perchè è lontana dal mio obiettivo di sempre: l’accessibilità di fatto, quella reale.

Però mi sono confrontato con persone che stimo, che hanno collaborato a quei requisiti, e la risposta è stata: il primo requisito è il più semplice da rispettare, bastava quello, perchè è tecnico, e basta sistemare certe cose, che il requisito è valido e l’accessibilità viene da sè; tutti gli altri requisiti complicano l’accessibilità.

Qualcunaltro ha sempre segnalato l’esigenza di regole precise, verificabili, bianche o nere, perchè una legge deve dare queste certezze.

Le uniche cose verificabili, bianche o nere che abbiamo, se non sbaglio, sono codice corretto e colori conformi… e sono quelle che contestiamo con più forza… (sarà perchè siamo italiani e ci stiamo stretti?!)

Dopo un anno in una grossa realtà che spicca per la sua attenzione e sensibilità all’accessibilità, mi rendo conto che il primo requisito, qui, sarà duro da far rispettare, ma siamo accesssibili più di tanti altri.

Quella del codice correto, è una battaglia che lotto ogni giorno, ed è buffo perchè non è la mia battaglia (contrappasso?!), ma in sostanza mi rendo conto che è difficile essere validi.

Lo hanno detto in tanti che è difficile, tanti altri hanno risposto “non sei conforme perchè non hai gli strumenti” e altri ribattevano “gli strumenti costano, la migrazione costa, ecc. ecc.”

Oggi quello che faccio è cassare e correggere template non validi, li faccio implementare in un CMS, ricasso e correggo l’implementazione non valida, e poi alla fine di un batti e ribatti, do il mio ok.

E sono consapevole che questo istante di purezza del codice, sarà passeggero.

Forse tra qualche anno quando avremo gli strumenti, durerà per sempre, a patto che valga la pena investirci sopra, cosa in cui non credo.

Cosa succederà al codice poco mi importa, preferisco che i redattori imparino a usare l’html per dare le informazioni, lasciando agli allegati solo un ruolo marginale, preferisco che scrivano dei testi semplici e chiari, preferisco che la strada per l’informazione sia corretta, che ci siano le label giuste, che non ci siano inutili alt in inutili immagini decorative, continuo a preferire cose pratiche, utili.

Passo del gran tempo a smontare i preconcetti dell’accessibilità vecchio stile, ed agli errori nuovi dovuti ad interpretazioni della 4/04

E se devo dire a qualcuno che mi chiede “di essere a norma” con un sito, gli rispondo non perdere tempo a sistemare i < br > sbagliati in tutti i tuoi vecchi contenuti, investilo in qualcosa che serva realmente.

Dopo un paio d’anni nell’accessibilità, non ho ancora cambiato il mio punto di vista, sarò ottuso, ma non ho ancora sentito una ragione valida per cambiare idea, se non che c’è una legge e va rispettata.

E comunque resto dell’idea, che il codice sia come una lingua: se sbaglio un tempo di un verbo italiano, non puoi dirmi che non so parlare italiano, a maggior ragione se poi chiunque mi “ascolta” lo capisce.

... e penso a pagine web non valide, che tutti gli user agent rendono correttamente

e per concludere: Maurizio allarga sta colonna dei Commenti perfavore…
— Maurizio 16 11 2005 - 13:07 # Jacopo, io la allargo, la colonna, ma tu restringiti. Un commento così lungo “nun se po’ vede’”! E’ persino più lungo del mio, il che è tutto dire. :)

Ad ogni modo mi pare di essere d’accordo. C’è un malinteso riguardo l’accessibilità ed è quello che citi. Cioè che bisogna essere “oggettivamente verificabili”. Ebbenne, un modo c’è: sono i test con un campione rappresentativo di utenti disabili.

Obiezione: costa troppo. Vero. Ma allora il punto è che vogliamo uno strumento oggettivo che sia pure economico e magari automatico per misurare qualcosa che probabilmente per sua natura così automaticamente misurabile non lo è. Non ci poniamo affatto il problema di quale attendibilità abbia questo strumento e di quali problemi collaterali comporti il suo utilizzo.

Ovviamente non capisco come possa essere accettabile. Sarebbe come dire che siccome misurare il PIL (il prodotto interno lordo) è complicato e costoso (e lo è), allora per legge lo misuriamo con una media del numero di aziende esistenti in Italia. Magari otteniamo un numero che ha una qualche rozza correlazione con il PIL. Ma quale economista lo prenderebbe sul serio?
— Sebastiano Nutarelli 15 01 2006 - 16:45 # Sono d’accordo con il pensiero che a codice valido non è detto corrisponda un’accessibilità garantita per l’utenza ma, come ho scritto più volte nelle principali liste di discussione, ritengo invece sia stata un’ottima cosa l’inserimento della validità del codice fra i requisiti della Legge 4/2004.
E’ chiaramente solo il primo passo e non determina l’accessibilità, sia chiaro.
Ma si detta uno standard che indica anche agli sviluppatori/programmatori degli strumenti assistivi futuri con che tipo di XHtml si dovranno rapportare.
Codice non uniforme (ergo non valido) su siti, per esempio, della PA può voler dire differente interpretazione da parte dei dispositivi utilizzati dagli utenti disabili in generale, di conseguenza penalizzazione se per qualcuno (se questo, come è facile immaginare, porta alla non interpretazione del codice in alcune sue parti).
Dettare come pre-requisito la validità del codice vuol dire enunciare a tutti che i siti dei soggetti erogatori descritti nell’art.3 della Legge avranno quel codice e non mille codici differenti.
Screen reader, lettori di schermo e vari strumenti assistivi interpreteranno un solo XHtml, avranno un solo output per l’utente.
Questa è parte dell’accessibilità che ne consegue.
Non è cosa da poco.
— Maurizio Boscarol 16 01 2006 - 13:29 # Ciao Sebastiano. Credo di aver già esposto le mie ragioni nell’articolo. Purtroppo la legge non tiene conto dello stato degli strumenti: tutto bene, se ci fossero in giro un tot di CMS, anche di alto livello, in grado di soddisfare senza problemi il requisito. Altrimenti parliamo di un mondo ideale, che non esiste.

Il problema è che la relazione fra accessibilità e validità esiste, ma non è né biunivoca, né necessaria per lo stato dell’arte degli strumenti attuali. Ad esempio, le tecnologie assistive più diffuse reagiscono piuttosto bene anche a codici non validi, com’è ovvio: altrimenti sarebbero inutilizzabili.

Ritengo che altre siano le richieste da fare per un sito accessibile ad un livello di base. Quello della validità può senza dubbio essere un obiettivo di alto livello, o di tutti, ma quando gli strumenti saranno adeguati.

Per ora è solo un processo utile, non un risultato da mettere al primo posto nei requisiti, visto che è da dimostrare quale influenza abbia sull’esperienza degli utenti disabili. Mi pare che su questo non sia mai stata fatta una seria ricerca, e me ne dispiace molto.

Ciao!
— Luca Mascaro 22 01 2006 - 19:46 # La discussione sul codice valido è molto articolata e in questo periodo di transizione non è la cosa più semplice da dibattere perchè non c’è una sola ragione ma mille ragioni diverse.

Però volevo portare solo un piccolo spunto che può o non può essere inteso come accessibilità ma rientra sicuramente sulla discussione del codice valido vale a dire Google che ha dovuto convertire sia IG sia Gmail in XHTML per farlo funzionare sui telefonini.

Infatti Google ha sviluppato sia IG sia Gmail in modo che funzionassero anche senza javascript per farli andare anche in Opera su telefonino ma purtroppo Nokia per motivi (penso) economici ha abbandonato opera e si è sviluppato il suo browser che funziona bene solo con siti sviluppati in XHTML Basic o XHTML Mobile e dal codice valido, pena il crash del browser per esaurimento della memoria.

http://m.gmail.com/
— Maurizio 24 01 2006 - 14:19 # Ciao Luca. Gmail (anche in versione mobile) continua a darmi qualcosa come 76 errori di validazione. Ieri erano 82. Insomma, non mi pare proprio che il passaggio a xhtml equivalga ad un passaggio verso la validità, in questo caso. Anzi… :))
— Marco Pegoraro 18 05 2006 - 12:45 # Ciao a tutti, complimenti per l’articolo e per l’analisi fatta.

Io sono tra quelli che si stanno sforzando di produrre CMS “orientati all’accessibilità”. Dico “orientati” in quanto un programma può dare dei consigli o mettere dei paletti, ma è chi lo usa o chi lo personalizza che ha la possibilità di causare problemi!

Personalmente sento molto forte il problema affrontato in questo articolo. Mi trovo d’accordo sull’utilizzo della validazione come di un primo passo per eliminare i più grossolani problemi di accessibilità (title, alt, liste…).

Vorrei introdurre un bel problema: AJAX.
Attualmente cerco di produrre, cliente permettendo, siti web validati, accessibili e magari anche belli da vedere e, non ultimo, orientati ad una buona indicizzazione nei motori. Bene, per quanto riguarda la parte pubblica di un sito nessun problema… Ma il Pannello di Controllo? Anche chi usa un CMS (oltre a chi fruisce il risultato) deve richiedere l’accessibilità? Il pannello di controllo del mio CMS cerca il più possibile di essere accessibile: – menu come liste, – attributi alt e title sempre presenti.

PERO’: Utilizzo gli attributi alt e title per spiegare all’utente l’azione che andrà a compiere… non è esattamente la versione testuale! Ovviamente utilizzo tabelle che non propongono dati tabulari: liste di documenti… Se devo presentare titolo, gruppo, parametri vari non posso certo utilizzare una lista!
In fine utilizzo pesantemente Javascrit ed in particolare AJAX: questa tecnologia permette di raggiungere livelli elevati di “operabilità” su una pagina… a discapito a volta della sua accessibilità. Vado abbastanza fiero del fatto che le mie pagine, intendo del PA, sono fruibili anche da supporti mobili con o senza css… però tante funzioni AJAX o Javascript non vengono supportate da palmari o cellulari. Questo non è un problema di accessibiltà?

Concludo: forse la diatriba dovrebbe essere “Accessibilità” Vs “Usabilità” Vs “SCOPO DELLA PAGINA”.
Non dimentichiamoci che web = comunicazione. La comunicazione ha un destinatario o un gruppo di destinatari ben preciso. Ritengo sia giusto tenere in considerazione anche questo.

Marco.
— Maurizio 18 05 2006 - 14:43 # Caro Marco, il problema di Ajax è ultimamente molto sentito dalle PA, che lo pongono proprio nei termini in cui lo poni tu: è spesso utile per migliorare l’usabilità, ma pone problemi di accessibilità. Ricordo che però la questione degli script è regolata piuttosto chiaramente nei requisiti tecnici. Il tema è comunque talmente specifico e sentito, che proveremo prossimamente ad affrontarlo in un articolo dedicato. Ciao!
— Marco Pegoraro 25 05 2006 - 11:02 # Continuo a proporre il dilemma AJAX.

In questi giorni sto mettendo in seria discussione il mio cms.. o meglio il PA. Sto mettendo in seria critica l’accessibilità e l’usabilità del PA in particolare.

Dal punto di vista dell’usabilità, presupponendo l’utilizzo di un browser di ultima generazione, sto adottando un largo utilizzo di applicazioni AJAX per operazioni di salvataggio automatico, reperimento informazioni necessarie, interfaccie tabulari ed editor visuali.
Quest accorgimenti vanno ad aumentare sensibilmente la facilità di utilizzo di tutto il software nonchè la velocità di redazione senza appesantire però i tempi di caricamento…

Ovviamente tutto ciò DOVREBBE andare contro ad un concetto di accessibilità.

Bene, quello che sto cercando di fare è mantenere un livello base di operazioni effettuabili anche utilizzando tecnologie meno recenti…

Praticamente effettuo i test con javascript e css disattivati.

Ne consegue che, pur diventando brutto, il pannello di controllo è effettivamente accessibile… certo sarebbe da pazzi pretendere che un ipovedente possa redarre un contenuto formattato con TAG html!

Sto sostenendo che esiste la possibilità di creare applicazioni web che forniscano sia un buon livello di accessibilità sia un buon livello di usabilità avanzata integrando strumenti javascript o interazioni client server AJAX.

L’utilizzo di interfaccie di navigazione tabulari utilizzando ad esempio gli script messi a disposizione da xLibrary costringono semplicemente a creare un menu di link che puntano a dei DIV della pagina che vengono trasformati nei tab corrispondenti via javascript…
Se il browser supporta lo script vedremo una bella interfaccia, se il browser non supporta javascript avremo una mappa di link in più! Questo, a parer mio, va ad incrementare l’accessibilità della pagina!

Bisogna però porre estrema attenzione alla struttura del codice XHTML ed alla struttura di css e jabascript… tutto dovrebbe essere modulare e facilmente disattivabile. Questa considerazione però riguarda solamente chi sviluppa un’applicazione ed in particolar modo chi sviluppa un’applicazione open source che dev’essere facilmente modificabile da chiunque!

Ora come ora queste considerazioni devono ancora essere applicate in pieno al mio cms… L’argomento accessibilità sta acquisendo per me sempre maggiore rilevanza e per questo sto progettando e pianificando un’intera revisione dell’interfaccia utente di tale software in modo da definire delle linee guida ed una solida base per realizzare un qualunque tipo di applicazione web che sia veramente accessibile ma allo stesso tempo veramente usabile, adottando dunque tutti gli stratagemmi css e javascript possibili per rendere possibile un’effettiva usabilità del software…

Dobbiamo sì tenere conto di un’eventuale possibilità di utilizzo da parte di utenti diversamente abili o dotati di tecnologie obsolete, però dobbiamo renderci conto che le tecnologie si evolvono, dobbiamo dunque cercare di realizzare software che utilizzino tutte le ultime tecnologie possibili per facilitare l’utilizzo da parte della stragrande meggioranza degli utenti!

Peg.

I commenti sono chiusi per questo articolo.

Argomenti:

RSS / Atom