divitis, tagitis, classitis e altre malattie del Web design: come prevenirle?

divitis, classitis e tagitisDa dove vengono queste malattie, e perché si propagano in modo virulento? Uno dei motivi è senza dubbio il tentativo di replicare layout grafici anche molto elaborati con gli strumenti disponibili sul Web, ovvero markup e CSS.

Il designer crea il suo progetto, con Photoshop, Fireworks o lo strumento grafico disponibile, e poi lo riporta in HTML per pubblicarlo sul Web. Una volta, tanti anni fa in un’epoca remota, l’immagine sarebbe stata ritagliata in tante fettine da porre in una bella tabella di layout per riassemblarle. Ora questa tecnica non è più di moda, e si replica il layout sostituendo le celle delle tabelle con tanti bei div, ognuno dotato di una classe CSS che con tanto tira e molla viene posizionato opportunamente.

Completare il puzzle è un bel pasticcio, sembra che quando un div va a posto gli altri impazziscono e si spostano a tradimento. E via a colpi di margin, padding, posizionamenti di qualsiasi tipo, float e altre amenità. Poi, provi in un paio di browser e ti accorgi che si disfa tutto. A questo punto il designer, esausto, comincia a consultare San Google o qualche amico più esperto per risolvere uno o più degli innumerevoli bug dei browser.

Dopo un po’, aggiungi qualche altro div di qui e di là, sposta tira e spingi, fiuuu, regge.

Non penso di essere tanto lontano dalla realtà, anche se sembra buffo.

Perché succede tutto questo? Un problema è rappresentato dal mancato completo supporto di CSS da parte dei browser, però questo aspetto per fortuna con il passare del tempo e gli aggiornamenti si è attenuato.

Credo però che una delle cause più sottovalutate di queste difficoltà sia rappresentata da quello che viene chiamato il foglio di stile di default. Secondo CSS 2.1, i browser dovrebbero utilizzare come regole di base quelle contenute nel “Default style sheet for HTML 4“, in modo che anche in assenza di un foglio di stile creato dall’autore della pagina gli elementi vengano presentati nel browser secondo certi criteri.

Però, come al solito, i produttori di browser hanno dotato i propri browser di regole non completamente standard e piuttosto personalizzate, ed ecco spiegato perché, per esempio, per sistemare un elenco puntato o numerato bisogna fare i salti mortali e il browser sembra agire per moto proprio invece che seguire le regole così faticosamente scritte dall’autore. Che succede? Basta dare un’occhiata ai fogli di stile predefiniti dei browser.

Per Firefox, date un’occhiata nella cartella res del programma: troverete diversi CSS, osservate html.css e form.css: queste sono le regole di visualizzazione predefinite per Firefox. Per Safari, il foglio di stile di default è quello di Webkit. Per Explorer, non si sa, è compilato in qualche libreria. Per un’analisi approfondita, leggete “User Agent Style Sheets: Basics and Samples” di Jens Meiert, che si è divertito (?) in uno studio interessante.

Dopo aver passato un po’ di tempo a vedere le differenze (sì, differenze) fra i vari fogli di stile di default, saranno molto più chiari i motivi per i quali i layout sembrano comportarsi in modo bizzarro, e perché tutti quei div, span e liti con margin, padding e float alla fin fine potevano essere evitati.

Basta usare un “Reset CSS”, per esempio quello proposto da Eric Meyer, per riportare a una condizione di partenza pulita qualsiasi browser (però, approfondite anche pro e contro). Già che ci siete, provate a usare anche il Diagnostic CSS. Tenete a portata di mano la legenda e osservate le vostre pagine[1. Basta caricare il CSS come foglio di stile utente: intorno agli elementi compariranno i box colorati definiti nel Diagnostic CSS per evidenziare gli errori più comuni.].

Sono certo che dopo un bel reset tutto sarà più pulito e chiaro, e ne basteranno molti di meno di quei div… (grazie a MetalSho per lo spunto). O almeno, quelli che ci sono forse avranno un motivo di esserci.
Un’altra spiegazione per la divitis potrebbe essere il non aver compreso il posizionamento con CSS, il cosidetto CSS-P. Lo sapete, vero, che non c’è bisogno di div per posizionare un elemento e che le stesse regole applicate al div funzionano pari pari anche se applicate direttamente all’elemento che avete racchiuso in quell’inutile, prolisso div? Qualche volta mi viene il dubbio.

Annunci

Epidemia nel Web: tagitis, divitis e classitis

Virus del Web: tagitis, divitis, classitis e derivati

Divitis

Man mano che il tempo passa, mi sembra che le cose per il Web vadano peggiorando invece di migliorare. Oppure sono più attento io, non so.

Comunque, ho appena visto un vero mostro: un sito dove non è presente nemmeno un tag, soltanto div. No, non è esattamente così: ci sono anche alcuni link con a e un p nel footer, sarà un errore, e un elenco puntato.

Tutti gli altri elementi di HTML, niente, non ce n’è traccia. Non c’è un titolo, non c’è un paragrafo di testo, niente. Ma la divitis sembra una malattia diffusissima, un’epidemia: non è che il codice di Facebook sia fatto un granché meglio, per esempio.

Provate a installare X-Ray nel vostro Firefox e buttate l’occhio. Sconfortante, vero?

Niente, sembra proprio che la semantica del markup sia stata definitivamente abbandonata. Div a raffica, e andare. Chi se ne frega se la pagina non ha alcuna struttura, tanto a monitor si vede…

Classitis

Insieme alla divitis uno si becca pure la classitis, vanno a braccetto, e la cura diventa sempre più complessa. È orrendo: pur di non fare un sito a tabelle, che non è trendy, mischio ottomila div e duecento classi così ho fatto il sito “tableless”, che è fico.

Nel sito che dicevo prima, c’è un blocco di codice così:

<div id="calendar_box">
<div id="calendar" class="box">
<div class="box_border">
<div class="box_border_corner box_border_corner_nw"></div>
<div class="box_border_pattern box_border_pattern_n box_pattern_250"></div>
<div class="box_border_corner box_border_corner_ne"></div>
</div>

Io non riesco proprio a capire a cosa serva. Cos’è ‘sto mostro? Ma è solo per fare un esempio. È questo il risultato delle guerre degli standard? Per non fare un sito a tabelle mi invento un groviglio di div e class per fare un layout?

Tagitis

Della anemia da tag abbiamo già detto, questa è la situazione opposta: l’abuso di tag. Questa malattia è quasi scontata nei siti affetti da divitis e classitis, probabilmente è il ceppo principale dell’epidemia. Per esempio, invece di scrivere

<label for="tel">Telefono</label>
<input type="text" name="tel" id="tel" tabindex="5" />

ci piazzo un bel

<div><label for="telefono">Telefono: </label></div>
<div id="form_tel_input" class="label_input">
<input type="text" id="telefono" name="telefono" size="25" value=""/>
</div></div>
<br/><br/>

Massì, anche due bei br che non ci stanno mai male, e qualche div in più fa sempre bene.

Oppure, da Wikipedia (non stiamo parlando di vette irraggiungibili, ma del minimo indispensabile per un Web qualcosa…):

<div class="menu">
<span>Main page</span>
<span>Contents</span>
<span>Help</span>
</div>

al posto di

<ul class="menu">
<li>Main page</li>
<li>Contents</li>
<li>Help</li>
</ul>

Ma che succede al Web? Invece di progredire regredisce? Si stava meglio quando si stava peggio, ecc ecc.

E intanto QuirksMode rilancia, To Hell With Bad Browsers — the sequel. Sì, siamo ancora lì. La cosa tragica è che prima si dava la colpa ai browser, ora che questi sono diventati quasi standard-compliant, sono spariti gli sviluppatori. In questa situazione, che senso hanno HTML5, XHTML2 e i loro successori nei secoli a venire? Facciamo una DTD con solo div, span e a e fine.

Forse l’iniziativa di Andy Clarke, For a Beautiful Web, non è così peregrina: il sito ha un eccellente design, tanta grafica e il markup è quello che serve, né più né meno. Tutti a fare il corso di Meaningful markup for designers. Possibile che a nessuno in Italia venga in mente di proporre qualcosa di analogo? Dove sono i nostri “guri”?

Oltre CSS Zen Garden, si diceva… (grazie dello spunto a Engelium).

Editoria scolastica accessibile

E tira e molla, e spingi e insisti… Devo dirlo: ieri e oggi per la mia personale storia con l’accessibilità sono state due giornate memorabili.

Ieri, per motivi che forse racconterò. Oggi, per la Circolare n.16 del 10 febbraio 2009 del Ministero della Pubblica Istruzione.

Oggetto: Adozione dei libri di testo per l’anno scolastico 2009/2010

Tutto bello e interessante, ma quando ho letto a pag 4, capoverso 2, Le tipologie dei libri di testo,

Per gli studenti con disabilità sono previsti libri di testo e strumenti rispondenti alle specifiche esigenze, sia sotto forma di testi trascritti in Braille per allievi non vedenti o con caratteri ingranditi per allievi ipovedenti, sia in forma digitale con prodotti che rispettino i requisiti previsti dalla normativa vigente ed in particolare il DPCM 30 aprile 2008 (pubblicato sulla Gazzetta Ufficiale del 12 giugno 2008), concernente le “Regole tecniche disciplinanti l’accessibilità agli strumenti didattici e formativi a favore degli alunni disabili”.

Ecco, mi son commosso, c’è anche del mio lì :-). Era il 28 luglio 2007, e faceva molto caldo…

bimbi nelle zucche

PDF accessibili con applicazioni Open Source?

Antefatto: chi decide se un PDF è accessibile o meno, e come dovrebbe essere fatto? Nel caso della Pubblica Amministrazione, se si tratta di libri di testo le caratteristiche che il documento deve rispettare sono elencate nel D.M. 30 aprile 2008, Allegato A. Se si tratta di documenti destinati al pubblico o distribuiti via Web, lo spiega il Bertoni. Per il resto del mondo lo decide Adobe nelle sue linee guida. Fine antefatto, e una possibile soluzione è al punto sei delle conclusioni, ma prima leggete il resto.

Un recente post di Semplicemente apre dichiarando:

PDF accessibili con applicazioni Open Source
Chi desidera pubblicare documenti PDF accessibili spesso si scontra con l’ostacolo del costo di Adobe Acrobat. Acrobat resta l’applicazione principe per l’accessibilità dei PDF, e l’unica che consente di verificarla, ma per chi non ha il denaro per acquistare questo software, esistono alcune soluzioni Open.

Seguono le mie rimostranze nei commenti del post. Non mi sembra di essere riuscito a spiegare il perché delle mie lamentele, e comunque è un argomento interessante e lo riprendo.

La mia prima rimostranza, e la più grossa, riguarda il titolo: a oggi non è possibile sapere e dichiarare se un PDF sia accessibile o meno, che venga creato con applicazioni Open Source o commerciali, senza utilizzare Acrobat Pro per verificare e correggere gli eventuali errori presenti.

Per esempio, nessuna applicazione (Word, OpenOffice, Indesign, chi più ne ha più ne metta) dispone nativamente di strumenti veramente efficaci e completi per rendere accessibili le tabelle o i moduli nei PDF. Impostare i cambi di lingua è un terno al lotto, e di solito gli elenchi puntati producono errori Unicode. L’unico strumento disponibile per creare, testare e modificare PDF accessibili è Acrobat Pro.

Tutto quello che si può fare, sia con applicativi commerciali sia Open Source, è salvare nel formato chiamato PDF con tag, che certo è un passo avanti per niente disprezzabile rispetto al nulla, ma sicuramente non è una condizione sufficiente per poter dichiarare che il PDF generato sia accessibile.

In realtà, quello che si fa è creare un documento .doc, .odf o altri formati utilizzando gli strumenti per l’accessibilità resi disponibili dal programma in uso. In linea di massima tutti i programmi che normalmente utilizziamo devono rispondere alla Section 508, e quindi sono in grado di generare file accessibili rispetto ai requisiti di questa normativa. Quindi si dovrebbe dire “creare documenti elettronici accessibili con Word, con Open Office” e così via. Creato il documento, decido di salvarlo in PDF.

Qui si notano comportamenti diversi. Chi dispone di Office e Acrobat, può sfruttare le opzioni del PDF Writer per preservare nel PDF il lavoro fatto sull’accessibilità del documento (e sulla sua qualità), poiché sarà possibile creare un PDF non soltanto strutturato, ma anche dotato di testi alternativi per le immagini, titoli per i link, sommari navigabili.

Con altri programmi, come Open Office o Indesign nelle versioni più recenti, questa possibilità è disponibile anche in assenza di Acrobat, mentre per Office è necessario disporre della versione 2007 e di un apposito plugin.

Basta questo per dichiarare accessibile il PDF? No. Un PDF accessibile deve rispondere a tutte le linee guida per l’accessibilità dei PDF di Adobe, che vanno anche oltre la Section 508. Per esempio, deve essere possibile visualizzare i contenuti anche quando linearizzati. Cosa significa? Provate ad aprire un PDF, sottoponetelo a ingrandimento e premete i tasti ctrl+4. Ora il documento è linearizzato, ovvero le informazioni presenti vengono renderizzate una di seguito all’altra, in un flusso consecutivo. Il documento è ancora fruibile? Se no, torna alla partenza. È comparsa la barra di scorrimento orizzontale? Se sì, ecco che sono presenti problemi di accessibilità. Del PDF, non del documento originale. Il PDF non è accessibile. Quindi non si può affermare “creare PDF accessibili con…”. Il problema non è open source o meno, il problema è con Acrobat o meno.

Nel post vengono presentate due procedure, una per creare PDF con tag con OpenOffice o a partire da file Word (nel caso, aprendo nel Writer di OpenOffice un eventuale documento Word e salvandolo come PDF con tag da OpenOffice, e fin qui nulla da dire, verrà creato un PDF con tag anche a partire da un documento creato con versioni di Word precedenti alla 2007, ben venga). Ovvio che il documento in entrambi i casi deve essere stato realizzato come si deve, in caso contrario non si produrrà nulla di utile. E se non lo fate vi scateno Cheope.

È da alcune versioni che Open Office ha questa opzione, e certo è una buona idea approfittarne. Ma vorrei sottolineare ancora una volta: è “soltanto” un PDF con tag, niente altro.

La seconda soluzione riguarda l’editing dei file PDF, dimenticando però che il problema vero con i PDF e tutti gli strumenti che permettono di creare file PDF, che siano open source o meno è uguale, consiste nella verifica dell’accessibilità dei file ed eventualmente nella correzione degli errori, cosa ad oggi inspiegabilmente possibile soltanto con Acrobat Pro, nonostante il formato PDF sia pubblico.

Il post di Antonio presenta come soluzione un plugin per Open Office, la Sun PDF Import Extension. Questa extension permette di aprire un file PDF e di eseguire sul file alcune operazioni di editing, fra cui assegnare agli elementi degli stili. Poi, basterà salvare il file in PDF con tag ed ecco fatto, è stato creato un PDF accessibile. Col cavolo…

Questo plugin apre sì i file PDF nel Draw di Open Office, ma poi che si riesca a farci qualcosa è del tutto opinabile: il testo viene diviso in righe singole, e quindi per assegnare un qualche stile ai blocchi di testo è necessario selezionarli riga per riga.

Se il documento ha più di trenta righe, magari con un layout a colonne, da spararsi. Certo, se ci si accontenta e si ha tanto tempo a disposizione…

interfaccia di Draw. Selezione riga per riga

Ma peggio del peggio, il plugin non riconosce come stili i tag eventualmente presenti nel PDF.

Come ci si può aspettare, selezionando gli stili predefiniti di Draw vengono applicate le formattazioni di default di Draw, non quelle presenti nel PDF. Per ottenere un PDF graficamente uguale, o almeno simile, a quello di partenza bisognerà ridefinire anche le specifiche di tutti gli stili. O perlomeno, selezionare un elemento, selezionare Nuovo stile dalla selezione, assegnare un nuovo nome allo stile… a me sembra già una cosa da matti.

Fin qui, stiamo parlando di semplice testo. Mi è stato fornito un file di esempio, quello nelle immagini, che dovrebbe rappresentare una prova dell’accessibilità dei PDF creati con Open Office e i plugin. Bene, una delle tabelle presenti non ha una riga di intestazione, allo scopo di evidenziare la differenza con l’altra tabella presente nel file, che la possiede.

Ora vorrei correggere questo errore con la “soluzione open source”. Dopo aver definito riga per riga gli stili, eccomi alla tabella. E ora? Come faccio a correggere la tabella se non ci sono gli strumenti per poterlo fare? Magari da qualche parte ci sono, ma io non sono riuscito a trovare qualche comando per assegnare alla cella di intestazione il tag opportuno (nel caso specifico, <th>).

Interfaccia di Draw. Dove sono gli strumenti?

E, domanda da mille punti: come caspita faccio a sapere che nel PDF c’è questo errore se non ho Acrobat per verificare il file? Penso che non lo saprò mai.

La cosa che più mi deprime è che nei commenti mi viene risposto “Un’altra considerazione e concludo. L’articolo che ho scritto è frutto di un seminario tenuto nella scorsa edizione di Handimatica intitolato “Generare PDF accessibili in modo accessibile” (una soluzione open source a portata di tutti). Il seminario era tenuto da un non vedente che utilizzava, ovviamente, le tecnologie che conosciamo tutti. Se un file PDF generato così è accessibile per lui, allora lo è anche per me”.

È completamente sbagliato. Uno: l’accessibilità non è “siccome uno screen reader legge il documento allora questo è accessibile”. Due: l’accessibilità non è un argomento riservato ai ciechi, che diventano i testimonial dell’accessibilità. Fra tutti i problemi coinvolti nell’accessibilità, quelli dei ciechi sono i minori. Sembra terribile dirlo, ma è così: è molto più facile che un documento elettronico possa essere letto da un cieco che da un ipovedente.  Tre: meglio evitare i seminari di Handimatica, spero che lascino proprio perdere questi argomenti. Quattro: quel seminario evidentemente era molto approssimativo, e il titolo è una bugia. Cinque: ma quando la comunità Open Source produrrà uno strumento in grado di fare le stesse cose che fa Acrobat Pro? Perchè, di equivalente ad Acrobat sia open source sia commerciale non c’è proprio niente.

Sei, molto importante: il nocciolo della questione è la possibilità di verifica ed intervento. Se non dispongo di Acrobat come faccio? Non posso?

Certo che si può. La possibilità viene dal formato ODF. ODF è un formato XML standard ISO, ed in quanto tale dispone di strumenti di validazione sia del codice, con l’ODF Validator, sia, e questo è fondamentale, dell’accessibilità con l‘Open Document Format (ODF) Accessibility Evaluator. Questo da solo dovrebbe rappresentare un motivo per adottare il formato ODF, qualsiasi sia il programma utilizzato per creare i propri documenti. Né doc né rtf dispongono di questi strumenti di verifica.

E non farebbe una bella figura il solito link al PDF etichettato però “PDF creato a partire da un file ODF accessibile“? Ricordandosi, mi raccomando, di attivare la casella di controllo Crea PDF con tag, sennò è inutile. Come conseguenza, molto probabilmente il file PDF generato a partire da un file nativo così verificato risulterà accessibile anche quando sottoposto ai test del validatore di Acrobat Pro.

Capisciammè. Spero di essermi spiegato 🙂

Linea Amica, dai che ce la facciamo!

Aggiornamento dal post precedente, Linea amica di chi. Colonna sonora: Je suis désolé, Mark Knopfler.

Sul sito di Innovazione P.A. è disponibile il report delle attività della prima settimana di funzionamento del portale. Da ieri, il backoffice di Linea Amica prende in carico e risponde in 48 ore a tutte le richieste-segnalazioni che pervengono attraverso il portale. Così annuncia Adnkronos. L’articolo presenta molti numeri e l’insediamento di un “comitato di regia”, e fra le altre notizie mi colpisce particolarmente questa: “Sui servizi specifici alle persone con difficoltà, conclude la nota, sono stati avviati gruppi di lavoro congiunti tra il Ministero per la Pubblica Amministrazione e l’Innovazione e le federazioni maggiormente rappresentative dei disabili. Dal 1 marzo entrerà in funzione un gruppo di 20 ricercatori Formez/Federazioni Disabili che costituirà lo strumento di ‘Linea Amica’ in questo settore”.

Bè, forse era preferibile pensarci prima, e prima di pubblicare dichiarazioni fasulle di accessibilità (che è ancora lì, preferiscono fare test ogni 24 ore invece di toglierla) ma… vediamo che succede intanto sul sito.

Uau! Ora i label hanno anche gli attributi for! Quasi quasi tento il colpo grosso, tentiamo un’analisi dell’accessibilità almeno del form.

Disattivati gli stili CSS, per ora il form di contatto si presenta così:

form di contatto di Linea Amica senza CSS

Un form piuttosto semplice insomma: alcuni campi di testo, una casella di controllo, un elenco a discesa.

Per delineare quel form è stato usato questo codice:

<div id="page_center">
<h2>Contattaci (servizio in fase di sperimentazione)</h2>
<p style="color:red; text-align:center;" ><strong></strong></p>
<form id="form" action="invio" method="post">
<div><div class="label">* Campo obbligatorio</div>
<div><br /><br /></div>
<div class="form_input_large">
<div id="form_email" class="label">
<label for="email">E-mail</label><span class="asterisco">*</span>:
</div>
<div id="form_email_input" class="label_input">
<input type="text" id="email" name="email" size="25" value=""/>
</div></div>
<br/><br/>
<div class="form_input"> <div id="form_nome" class="label">
<label for="nome">Nome: </label></div>
<div id="form_nome_input" class="label_input">
<input type="text" id="nome" name="nome" size="25" value=""/>
</div></div>
<div class="form_input_right">
<div id="form_cognome" class="label">
<label for="cognome">Cognome: </label></div>
<div id="form_cognome_input" class="label_input">
<input type="text" id="cognome" name="cognome" size="25" value=""/>
</div></div><br/><br/>
<div class="form_input">
<div id="form_citta" class="label">
<label for="citta">Città:</label></div>
<div id="form_citta_input" class="label_input">
<input type="text" id="citta" name="citta" size="25" value=""/>
</div></div>
<div class="form_input_right">
<div id="form_tel" class="label">
<label for="telefono">Telefono: </label></div>
<div id="form_tel_input" class="label_input">
<input type="text" id="telefono" name="telefono" size="25" value=""/>
</div></div>
<br/><br/>
<div id="form_disp" class="label">
<label for="disp2">Disponibilità ad essere ricontattati: </label></div>
<div id="form_disp_input" class="label">
<input type="checkbox" id="disp2" name="disp" />
</div>
<br/>

<br/>
<div id="form_tipo" class="label"> <label>Tipologia della richiesta a Linea Amica: </label>    </div>
<div id="form_tipo_input" class="label">
<select name="tipologiaRichiesta">
<option value="0">Seleziona tipologia richiesta</option>
<option value="Informazioni generiche">Informazioni generiche</option>
<option value="Segnalazione negativa">Segnalazione negativa</option>
<option value="Segnalazione positiva">Segnalazione positiva</option>
</select>
</div>
<br/><br/><br/>
<div >Inserisci una domanda (max 3000 caratteri).</div>
<br/>
<div id="form_domanda_cont">
<div id="form_domanda" class="label">
<label>Testo della richiesta: </label></div>
<div id="form_domanda_input" class="label">
<textarea name="domanda" cols="54" rows="4"></textarea>
</div></div>
<div id="form_invia" class="label"> <input type="submit" name="Invia" value="Invia" /></div></div></form>        </div> <!-- /#page_center -->

Se una cosa così la facesse un mio amico, gli chiederei ci sei o ci fai. In questo caso, mi limito a chiedere “Perché lo fai?”… Non dico sviluppate una soluzione, almeno leggete un tutorial, fate qualcosa.

Ma a che servono tutti quei div? Provate a usare fieldset e legend per condurre passo passo il cittadino, farlo sentire a casa propria. Una esagerazione? Accessible Form Step Wizard, del nostrano Diego La Monica.

Ma anche senza arrivare a tanto, almeno usate i tag corretti. Un cieco che utilizza Jaws o un qualsiasi screen reader li potrà sfruttare a pieno, se vengono usati. Serve uno spunto? Ecco un esempio. Basta leggere il sorgente e cercare di replicarlo con un minimo di perizia, niente di più.

Un po’ di CSS? Certo, anche l’occhio vuole la sua parte, ed ecco The Man in Blue.

Io spero che nel gruppo dei magnifici “20 ricercatori Formez/Federazioni Disabili” (20? ma non è un po’ esagerato?) ci sia almeno uno che si preoccupa di standard e accessibilità, che conosca almeno una manciata di best pratice dello sviluppo Web, non dico un esperto ma almeno a conoscenza dei fatti, che abbia un’idea di cosa sono i tag di HTML, che capisca la parola semantica…

Je suis désolé, diceva Mark Knopfler. Ne verremo a capo? Forza ricercatori, e auguri! Dai che ce la facciamo.

Qualcuno potrebbe anche dire sì, d’accordo, ma tu come avresti fatto?

Una soluzione senza pretese e riflessioni, di getto, ma completa di fieldset, legend e correggendo le mancanze presenti nell’originale potrebbe essere la seguente. Più accessibile, più usabile, 50% del codice originale. Non ho aggiunto tutti i tabindex, perché mi son stufato. È certamente possibile fare anche meglio.

<form id="contatti" method="post" action="">
<fieldset><legend>1. Dicci come ricontattarti</legend>
<ol>
<li><label for="Email">E-Mail</label>
<input type="text" name="Email" id="Email" tabindex="1" /></li>
<li><label for="Nome">Nome</label>
<input type="text" name="Nome" id="Nome" tabindex="2" /></li>
<li><label for="cognome">Cognome</label>
<input type="text" name="cognome" id="cognome" tabindex="3" /></li>
<li>
<label for="citta">Città</label>
<input type="text" name="citta" id="citta" tabindex="4" /></li>
<li>
<label for="tel">Telefono</label>
<input type="text" name="tel" id="tel" tabindex="5" />
</li>
<li>
<label for="sino">Disponibilità ad essere contattati</label>
<input type="radio" name="Sino" value="Sì" id="Sino_0" />
<label>Sì</label>
<input type="radio" name="Sino" value="No" id="Sino_1" />
<label>No</label>
</li>
</ol>
</fieldset>
<fieldset>
<legend>2. La tua domanda</legend>
<ol>
<li>
<label for="domanda">Tipologia della richiesta a Linea Amica</label>
<select name="domanda" id="domanda" tabindex="5">
<option>aaa</option>
<option>bbb</option>
<option>ccc</option>
<option>ddd</option>
</select></li>
<li>
<label for="testo">La tua richiesta (max 3.000 caratteri)</label>
<textarea name="testo" id="testo" cols="45" rows="5" tabindex="7"></textarea>
</li>
</ol>
</fieldset>
<fieldset>
<legend>3. Invia il tuo messaggio</legend>
<p>Dichiarazione privacy, blablabla, note e quant'altro</p>
<label for="invia">Invia il tuo messaggio</label>
<input type="submit" name="invia" id="invia" value="Invia" tabindex="9" />
</fieldset>
</form>

Linea Amica di chi?

linea amica? bimba estrefatta

“Il piu’ grande call center italiano che si chiamera’ ‘Linea amica‘ che non lascera’ soli i cittadini italiani in quanto chiunque telefonera’ verra’ preso in carico e supportato fino alla soluzione del suo problema. Parola di Brunetta. L’idea e’ quella di ”rispondere alle persone, ai cittadini-clienti al meglio, smistando le richieste alle p.a. competenti attraverso una intelligenza collettiva che pur nelle specificita’ – ha detto Brunetta – tenga sotto controllo il customer service a livello globale”. Di giorno in giorno tutti i contatti in entrata e in uscita saranno oggetto di report e verranno raccolti in una sorta di ”enciclopedia”.

L’URP degli URP… speriamo che non sia onomatopeico.

Poi è venuto il piano E-gov 2012, con i suoi riferimenti all’accessibilità e alla Stanca.

Bello, andiamo a dare un occhio. Com’è il nome di dominio? Non lo ricordo, vai di Google Linea Amica. Oho. “Siamo tante fantastiche ragazze del gruppo linea amica che. Chiamami sarò la tua amichetta godosa e desiderosa di farti divertire! Linea amicha da telefono…”

Questo il primo link che trovo. Certo che almeno un test prima di attivare il dominio, vabbè. Comunque, con lineaamica si arriva finalmente al sito: http://www.lineaamica.it/. La home ora si chiama “Contattaci (servizio in fase di sperimentazione”, la prima volta che ci sono andato era Contattaci | localhost (sigh).

Premetto che sabato scorso, dopo aver visitato il sito, ho provato a usare il modulo che dovrebbe costituire il cuore del sistema “che non lascerà soli i cittadini”, ovvero il modulo di contatto presente nella home che si chiama Contattaci (bisognerà spiegare ai cittadini che per facilitarli la home non si chiama Home ma appunto, Contattaci…).

Ho compilato il mio bel modulo di contatto con una serie di note, perché il sito mi ha fatto proprio incazzare. Clic sul pulsante Invio, e voilà: il modulo non funziona!

Vabbè. Ho scritto a Brunetta sulla sua bacheca di Facebook, ed ho inviato una e-mail al suo indirizzo presso governo.it.

Perché? Subito detto. Sul sito è stata pubblicata una dichiarazione di conformità alla 04/2004, falsa purtroppo.

Gli errori presenti sono grossolani, facili da rilevare per chiunque si occupi anche soltanto un po’ di accessibilità e standard.  Fra i più evidenti l’assenza di un uso sensato degli elementi <hn>, il form centrale, rudimentale sia come progettazione sia come implementazione, non ha i necessari <label for"">, e altre amenità di questo livello che definirei basico. Insomma, chi ha fatto il sito non ha la minima idea di cosa sia l’accessibilità, e soprattutto che cosa significhi dichiarare che il sito è conforme alla 04/2004.

Eppure, ci hanno schiaffato la loro bella dichiarazione di conformità. Bisogna essere perversi, mi dico. Io scrivo.

Scrivo la mia bella e cortese letterina, e qualcosa succede. Mi risponde addirittura il presidente dell’enorme ente responsabile del sito. Accidenti!

Questa persona, cortesissima, non può fare altro che girarmi le risposte del servizio tecnico. Ai ai.

“Buongiorno,
dopo la segnalazione di sabato abbiamo effettuato qualche ulteriore
controllo e verifica sul sito Linea Amica.
Effettivamente erano stati introdotti con le ultime modifiche delle
piccole incompatibilità non bloccanti rispetto gli standard internazionali
W3C.”

Ai ai ai. Piccole incompatibilità non bloccanti? E cosa sarebbe una piccola incompatibilità non bloccante? E che c’entra con quello che ho segnalato io? Me li vedo: tutto quello che hanno fatto è validare il sito e rilevare gli errori del codice. Capito un cazzo, dicono a Bergamo.

“In realtà, avendo aggiornamenti continui in corso (alcuni servizi sono in sperimentazione sino al 15 febbraio come annunciato in conferenza stampa), effettuiamo ogni 24 ore una nuova verifica di accessibilità.”

Robe da matti. Invece di mettere a posto il sito e POI pubblicare la dichiarazione di conformità faranno verifiche ogni 24 ore.
Ma hanno la minima idea di cosa sia una verifica di conformità della 04/2004?
Rispondo (copio/incollo pari pari omettendo il nome del mio interlocutore, come mi sembra giusto).

“Egregio Dott., sono veramente e gradevolmente sorpreso da questa
sua. Sinceramente, non mi aspettavo un riscontro così tempestivo ed
attento, e ne sono molto lieto.
Quello che dichiara il servizio tecnico lascia un po’ il tempo che
trova. È del tutto legittimo apportare modifiche, pianificare
interventi e svolgere tutte le attività necessarie su un sito appena
messo online.
Quello che non funziona è pubblicare sullo stesso attestazioni di
conformità a una legge delicata come la 04/2004 che affronta una
tematica particolare come l’accessibilità (lo confesso, sono un
accanito sostenitore della causa, come forse si è intuito).
Trovo sia particolarmente offensivo verso chi di quella accessibilità
si potrebbe giovare, oltre che forse illegale (si tratta di una falsa
dichiarazione di conformità a una legge).
È la stessa cosa che dire a un cieco vieni che ti aiuto ad
attraversare la strada e poi lasciarlo lì in mezzo.
Non è preferibile mettere a posto il sito e poi dichiararne
l’accessibilità una volta raggiunta?
Nello specifico:
>> Effettivamente erano stati introdotti con le ultime modifiche delle
>> piccole incompatibilità non bloccanti rispetto gli standard internazionali
>> W3C.
Non esistono “piccole incompatibilità non bloccanti” quando si
aderisce a uno standard, è una condizione sì/no.
Non so come e quando il sito verrà completato, in questo momento mi
sembra che siamo ancora lontani e per chiunque si occupi un po’ di Web
e accessibilità sono presenti errori gravi piuttosto evidenti,
soprattutto per un sito basato su Drupal.
In ogni caso, ancora grazie della Sua risposta e a disposizione per
qualsiasi ulteriore informazione ritenesse necessaria e utile.

Buona giornata
Livio Mondini

Oggi vado a rivedere il sito, ed ho la clamorosa conferma. Non sono proprio capaci… Invito chiunque a guardare il codice del form, il cuore del sistema.
Hanno aggiunto <label>, ma senza attributo for.
Ma a che serve? Inoltre, la gerarchia dei titoli è rimasta invariata, con un bel h1 vuoto in mezzo alla pagina e il resto sparpagliato a caso. E via così, non voglio tediare nessuno con i dettagli tecnici.
Il rispetto della semantica degli elementi HTML che costituiscono la pagina non provo nemmeno a parlargliene. Per quelli che sono gli aspetti relativi alla privacy, tracciatura dei quesiti dei cittadini, trasparenza rimando al post di Scano.

Ora nella pagina di dichiarazione di conformità, invece di cancellarla, hanno aggiunto pure gli accesskey, che chiunque eviterebbe come la peste.

Che dire, mò riscrivo… fatelo anche voi per favore, se l’accessibilità, gli standard e il Web vi stanno a cuore.

Questo è il biglietto da visita di E-Gov 2012? Speriamo di no, sono sicuro che non è questo quello che il Ministro Brunetta vorrebbe.