Archivio > Accessibilità, Scripting e Programmazione > Singolo: I sommari dinamici non sono accessibili

I sommari dinamici non sono accessibili

Spesso sui blog troviamo archivi e liste di articoli (generate automaticamente dai CMS più noti e attualmente in circolazione) dove il testo dell'articolo viene brutalmente spogliato e svestito dei suoi tag, ed infine "castrato" dopo un determinato numero di caratteri. In una sola parola, vengono creati i cosiddetti excerpts.

Mi trovavo a riflettere in questi termini dopo aver emulato un comportamento simile in uno dei tanti progetti a cui sto lavorando (per ora non vi anticipo nulla, spiacente :-P): dopo un primo effimero momento di soddisfazione, mi sono accorto dell'errore in cui ero inconsciamente caduto.

L'assioma di oggi è:

Usare sommari generati dinamicamente comporta una perdita di profondità nelle informazioni dovuta alla mancanza di contenuto semantico e quindi accessibile.

L'esempio più banale è quello dell'utente e dello screen reader. Il lettore di schermi infatti legge l'articolo nella sua rozza forma, e lì termina il suo compito. L'utente, intanto, non capisce una sola frase e giustamente si spazientisce.

Prendiamo ad esempio il mio articolo sulle tappe più importanti dell'Acid2 test. Attraverso una semplice funzione in PHP (che casualmente ho chiamato devastaTesto), ho fatto in modo che l'articolo venisse ripulito dei tags HTML e spezzato dopo 350 parole. Risultato? Guardate con i vostri occhi:

13 Aprile 2005 Viene ufficialmente segnalato l'Acid2 Test sul portale ufficiale del WaSP. Molti sviluppatori avevano già iniziato i lavori prima dell'annuncio, tanto che Konqueror aveva già superato il test (vedi Konqueror su Wikipedia) nel lontano 6 Aprile, grazie all'aiuto di alcune patch scritte per Safari allo stesso scopo. 27 Aprile [...]

La stessa porzione di testo, mantenuta allo stato originale, rende così:

  1. 13 Aprile 2005

    Viene ufficialmente segnalato l'Acid2 Test sul portale ufficiale del WaSP.
    Molti sviluppatori avevano già iniziato i lavori prima dell'annuncio, tanto che Konqueror aveva già superato il test (vedi Konqueror su Wikipedia) nel lontano 6 Aprile, grazie all'aiuto di alcune patch scritte per Safari allo stesso scopo.

  2. 27 Aprile 2005

    Safari è il primo browser a superare il test, pubblicando le patch necessarie a migliorare il motore di rendering del browser.

Si vede una netta differenza rispetto all'output originario. Il risultato è squisitamente orrendo, manca di immediatezza, e io stesso fatico a capirci qualcosa. Se poi anche l'udito vuole la sua parte per punteggiatura e pause, allora la difficoltà di comprensione aumenta considerevolmente.

In fondo, penso che questi sommari dinamici non abbiano molto senso per noi e per il nostro pubblico: un riassunto va concepito con criterio, e soprattutto non da uno script, ma da una mente umana che sia capace di costruire frasi di senso compiuto.

Lasciare che un blocco di istruzioni di programmazione faccia il lavoro sporco per noi implica inevitabilmente un risultato più scadente del normale, specialmente agli occhi dell'utente finale. L'unico modo per tentare di capire qualcosa sull'argomento trattato senza dover esclusivamente lavorare di fantasia consiste quindi nel leggere titolo assegnato all'articolo (sperando a quel punto che l'autore sia stato capace di sceglierne uno chiaro e preciso, senza perdersi in assurde ambiguità).

Al contrario uno o più paragrafi riassuntivi studiati con logica permettono ai nostri visitatori di assimilare immediatamente le informazioni principali di ogni articolo, facilitando la consultazione dei testi che ritengono più vicini ai loro interessi. Il vantaggio si ritorce fortunatamente anche su noi autori.

Insomma, un solo paragrafo studiato ad hoc riscuote sempre e comunque maggior successo di ogni altra soluzione dinamica, incapace di comunicare ad un umano ciò che può invece sembrare evidente ad una macchina.

La categoria di riassunti-sommari che abbiamo esaminato, quindi, è destinata a sopperire (o meglio, spero che lo sia) di fronte ad una semplice evidenza: non può svolgere il ruolo di overview su un testo.

Meglio perdere cinque minuti in più a scrivere due o tre righe riassuntive, piuttosto che far perdere il doppio del tempo a chi con pia innocenza cerca di consultare i nostri scritti.

Approfondimenti

L'articolo è stato di tuo gradimento? Puoi controllare che vi sia altro di tuo interesse nelle categorie e , oppure iscriverti al notiziario RSS e seguirmi su per restare sempre aggiornato sulle ultime pubblicazioni.

Pubblicato sabato 20 gennaio 2007.

Discussione [3]

  1. Simone Onofri aggiunge:

    [Immagine] Segue l'intervento di Simone Onofri

    Quello che dici è vero. Ti do qualche riferimento. Consideriamo il lavoro delle WCAG 1.0, nello specifico la Linea guida 14: Assicurarsi che i documenti siano chiari e semplici.

    La lingua in generale, e i sommari possono essere un esempio, è molto importante. Non solo in fatto di accessibilità ma anche per chiarezza e semplice comunicazione. Dunque deve essere ben curata e chiara sempre, e gli strumenti automatici non sempre ci possono garantire la chiarezza nel testo.

  2. eKoeS aggiunge:

    [Immagine] Segue l'intervento di eKoeS

    Ciao Simone, grazie per il commento. :) L'articolo si ispira proprio alle linee guide WCAG 1.0, anche se come dici te la questione entra anche nel campo della semplice comunicazione.

    La cosa abbastanza grave (e su questo rimando all'articolo "Cosa vorrei da un CMS") è che lo stesso tema di default proposto in Wordpress (si chiama Kubrik se non ricordo male) propone per gli archivi questa pessima soluzione, dando un cattivo esempio e diffondendo blog tutti col medesimo problema.

  3. Roberto aggiunge:

    [Immagine] Segue l'intervento di Roberto

    Ottimo articolo.

    Lo sai che non ci avevo fatto caso ai mini-sommari degli archivi di Wordpress? Altra modifica da fare al template, ma devo metterla in coda con tutte le altre...

Discuti

Il blog è in sola lettura.