mobile-touch

Nuova intervista a Elena Brescacin, sviluppatrice non vedente

Una nuova intervista ad Elena Brescacin: accessibilità della rete, app mobile e Internet of Things per un mondo migliore.

Era il 2009 quando decisi di condividere una delle interviste più interessanti mai pubblicate su questo sito: una bella chiacchierata con Elena Brescacin, sviluppatrice web non vedente che lasciò una testimonianza preziosa sull’accessibilità della rete e sulla sua esperienza con il mondo web.

Dopo diversi anni è giunto il momento di parlare di nuovo con Elena, che nel frattempo è cresciuta professionalmente e mi ha offerto molti nuovi spunti di discussione.

Si parla non solo di sviluppo web, ma di nuovi ambiti dove l’accessibilità è fondamentale: applicazioni mobile e internet of things.

Intervista ad Elena Brescacin

Ciao Elena, sono passati più di 7 anni dalla nostra prima intervista, puoi raccontare brevemente chi sei e cosa è successo di nuovo nella tua vita professionale in questi anni?

Come è evoluta la tecnologia, è evoluta anche la mia professione. Se nel 2008 lavoravo quasi solo con HTML scritto manualmente, adesso per fortuna la situazione è cambiata.

Per gestire i contenuti web mi avvalgo anch’io di Content Management System, preferibilmente Drupal, che allo stato attuale (2016) risulta quello più attento all’accessibilità lato back-end, perché il front-end dipende tutto dai temi; come qualsiasi CMS basato su template, l’accessibilità del sito web dipenderà da quanta attenzione chi sviluppa il template avrà nei confronti delle linee guida per l’accessibilità.

Ciò che è importante in questo caso è che tramite una struttura basata su Drupal, anche una persona con disabilità visiva come me può tranquillamente gestire il pannello di amministrazione del CMS in tutte le sue forme.

Ma il web non è più la parte integrante del mio lavoro; con l’avvento di smartphone, tablet e dispositivi indossabili, l’obiettivo si è
spostato anche verso altri orizzonti.

Ora mi occupo non solo di test sull’accessibilità del web, ma anche di quello che riguarda applicazioni mobile, test di hardware e software mainstream, ovviamente indirizzandomi verso l’accessibilità e usabilità per persone disabili e non.

Come è cambiato il tuo modo di utilizzare la rete e la tecnologia in questi anni? Trovi ancora gli stessi problemi di 7 anni fa parlando di accessibilità?

La rete è evoluta, così come il mio lavoro e svago.
All’epoca della mia prima intervista avevo pochissima tecnologia, mi limitavo a un uso di computer Windows e un telefonino con funzioni abbastanza limitate. Ora ci sono blog, siti web, social network ma soprattutto app mobile e accessori interfacciabili con smartphone e tablet che facilitano molto la vita.

Se prima la tecnologia era passiva, adesso è assolutamente interattiva; grazie ai social network è possibile interfacciarsi più o
meno direttamente con chi produce hardware e software, e almeno nelle intenzioni l’accessibilità sembra non essere più un argomento di nicchia, infatti molte aziende di elettronica di consumo — Apple molto più di altri — stanno cercando di rendere i propri sistemi operativi e dispositivi fissi o mobili più accessibili possibili.

Il problema grande è che in molti casi rimangono solo intenzioni: per esempio la troppa frammentazione di sistemi a sorgente aperto, come Linux e come Android su smartphone, impedisce di creare un vero e proprio standard, per cui soprattutto per chi non vede, che per interfacciarsi con la macchina ha bisogno di specifici accorgimenti, risulta più difficile.

A differenza di 8 anni fa, le linee guida sull’accessibilità per il web sono state aggiornate, aggiungendo anche delle specifiche nuove, le ARIA, specificamente studiate per tutte quelle applicazioni web con funzioni avanzate (Rich Internet Application), ma occorre una massiccia sensibilizzazione sull’argomento.

Per quanto in modo più o meno marcato i grandi produttori di tecnologia di consumo cerchino di muovere un passo avanti verso l’accessibilità, se lo sviluppatore — specie nelle app mobile — non conosce le regole che ogni piattaforma adotta per rendere le proprie app accessibili, il cosiddetto “design for all”, progettazione universale, è solo un discorso fatto a vuoto.

In teoria le cose potrebbero cambiare: su piattaforma Apple le linee guida sull’accessibilità delle app sono incluse nelle
documentazioni per sviluppatori e senza costi aggiuntivi rispetto al normale protocollo developer; sviluppando usando gli standard della piattaforma si riesce a costruire progetti accessibili. Ma se non vengono usati framework standard siamo agli stessi livelli di 8 anni fa.

Per cui, sì, le tecnologie ci sono, ma lato sensibilizzazione va fatto ancora molto lavoro.

Che strumenti utilizzi in ambito professionale? Hai delle preferenze sui software?

Come già detto, utilizzo dei CMS — specialmente Drupal — per il lavoro su web, mentre gli strumenti TestFlight e TestFairy per testare le applicazioni, più i vari editor testuali per tradurre, quando il mio compito è quello di fare traduzioni inglese-italiano o viceversa, perché molte volte trovo dei progetti interessanti che sono solo in inglese e mi offro per portarli in italiano.

Apple è per il momento la piattaforma che lato utente ha la maggiore attenzione verso l’accessibilità.

Per una persona che non vede, avere in mano una macchina Apple significa essere autonomo già dalla prima accensione.

Per questo collaboro con altre 5 persone ipo e non vedenti, a un progetto chiamato www.nvapple.it che si occupa di divulgazione dell’accessibilità a tutto tondo e dell’utilità che questi dispositivi hanno per chi non vede.

Sono particolarmente interessato al mondo IoT: che possibilità ci sono oggi per un non vedente, rispetto a qualche anno fa?

Internet delle cose. E’ una realtà che spaventa molti, soprattutto chi non è molto amante della tecnologia; ma in realtà, l’IoT potrebbe essere la chiave di volta definitiva per rendere accessibile ogni ambito della vita quotidiana: dalla salute, alla gestione della casa e dell’ufficio.

Il condizionale è d’obbligo, perché questo è un fenomeno in espansione e che non ha ancora avuto il suo momento più forte, ma l’abbattimento delle barriere percettive potrebbe davvero essere finito.

Un elettrodomestico o apparecchio medicale moderno infatti attualmente è per il 90% provvisto di display, con pulsanti o controlli touch, per cui uno che non vede è costretto per forza di cose a farsi spiegare, oppure ad adottare dispositivi parlanti, che molte volte costano anche molto di più rispetto a quelli mainstream, proprio perché “di nicchia”.

L’IoT abbatte la barriera fin dalla base, qualora le funzioni attribuite al display siano gestibili tramite smartphone.

Per questo è importante mettere più sviluppatori possibili a conoscenza delle regole di accessibilità presenti nelle piattaforme mobile, così che possano realizzare delle applicazioni accessibili già dalla base: nel momento in cui il mio smartphone già parla, io non ho alcun bisogno di usufruire di altri dispositivi parlanti.

Al momento possiedo una bilancia, un misura pressione, un anello indossabile per gestire l’attività fisica, e a momenti mi dovrebbe
arrivare uno scalda/raffredda bevande. Molti pensano che i dispositivi medici basati su smartphone siano inutili (ad esempio per “condividere la misura della febbre via social”), ma queste persone non conoscono le potenzialità di uno strumento del quale la
condivisione sui social potrebbe anche non esistere, ma che per chi non vede, fa molto di più.

I dati sulla salute possono essere inviati direttamente al medico di base per esempio, senza aver bisogno di foglietti e appunti.

Spero che l’evoluzione continui.

Quali sono i problemi principali con cui ti scontri navigando su internet? I captcha sono ancora al primo posto?

Purtroppo sì. I captcha sono ancora all’ordine del giorno, poche sono le realtà che usano i captcha audio; ultimamente mi è capitato di dover resettare la password sul sito Amazon Italia. C’era il captcha senza audio. Provo a contattarli per dirglielo e… anche lì, captcha senza audio.

Perché devo esser costretta a telefonare quando gli altri possono fare tutto online?

Esistono una estensione Firefox, Webvisum, e una per Safari, Rumola, che potrebbero leggere i captcha, ma il loro funzionamento non è sempre garantito. Potrebbero funzionare un mese, un anno, poi aggiornano il browser, le estensioni non si aggiornano perché non sono certificate… e si perde la funzionalità.

L’unica è l’eventualità di usare servizi di volontariato a distanza, come BeMyEyes o BeSpecular, ma anche là significa coinvolgere terze persone per farsi aiutare a risolvere un problema che dovrebbe essere risolto da chi sviluppa i siti.

Oltre ai captcha si sono aggiunte molte applicazioni cosiddette “ricche”, provviste di elementi trascinabili tramite drag & drop o
similari, che non fanno uso delle specifiche ARIA (Accessible Rich Internet Applications) rendendo impossibile la fruizione di interi
servizi.

In passato avevi criticato i siti di news di essere poco accessibili: esiste ancora questo problema?

Ci sono alcuni siti di notizie che sono leggibili, ma con l’avvento degli abbonamenti digitali usufruire di informazioni on line e di
qualità non è sempre facile, per uno che non vede.

Primo, perché la pubblicità è aumentata in modo esponenziale, e non sempre installare un adblocker risolve il problema. Gli ad blocker per una persona che non vede sono una manna dal cielo, dato che i servizi di pubblicità on line dell’accessibilità non si curano proprio, ma usare un ad blocker può risultare scorretto nei confronti del sito che pubblica notizie.

Secondo, perché spesso e volentieri nella fruizione della parte gratuita nei siti delle testate giornalistiche aumenta il fenomeno
del clickbaiting, ovvero attirare gli utenti con dei titoli ad effetto sotto i quali però ci sono delle notizie di qualità discutibile.

Per quanto riguarda gli abbonamenti digitali non avrei nessun problema a pagare per una testata giornalistica, peccato però che non ci siano giornali accessibili a pagamento!

Molte associazioni di ciechi hanno stipulato degli accordi con alcune testate per poter avere i contenuti on line gratuitamente e
facilmente, ma affidarsi a un’associazione per potersi informare significa non essere liberi. Significa poter leggere solo quello che
l’associazione vuole che io legga, solo quello con cui ha stretto accordi. E il resto? Non chiederei la gratuità, chiederei di pagare
come tutti ma con le dovute garanzie di un servizio fruibile.

In conclusione, vuoi aggiungere qualcosa?

In questi anni ho avuto modo di crescere, insieme alla rete internet.

Ho anche dovuto fare i conti con la realtà dell’internet addiction, una situazione di abuso delle chat, in un momento particolarmente fragile che mi stava portando fuori strada. Per fortuna grazie alla vicinanza di familiari e amici ho avuto modo di rimettermi in piedi, e di ridare alla rete il valore che ha.

A chi ha paura delle nuove tecnologie, soprattutto quelle mobili e indossabili, dico che si ha paura di quello che non si conosce, o che comunque si subisce.

Non è lo smartphone o il tablet che causa la dipendenza, ma l’approccio mentale che noi abbiamo verso le macchine.

La tecnologia mi ha restituito una gran percentuale di autonomia personale che non avrei mai pensato di raggiungere, per esempio poter sfruttare la fotocamera dello smartphone tramite intelligenza artificiale (applicazione TapTapSee) oppure tramite videoconferenza (BeMyEyes) oppure facendo vedere delle foto a delle persone vedenti a distanza (BeSpecular), oltre all’accesso a
tanti servizi professionali e di svago che prima potevo solo immaginare.

Per non parlare di domotica e IoT, un futuro che si prospetta interessante ma di cui attualmente sto godendo solo una piccola parte.

La rete ha abbattuto le distanze: adesso lavoro con colleghi in tutta Italia, oltre a far parte della redazione del portale www.nvapple.it
gestito insieme ad altre cinque persone sparse per l’Italia, con le quali si comunica via social, mail, whatsapp, includendo il progetto della web radio NvRadio, nella quale mettiamo musica e svolgiamo eventi in diretta, senza bisogno di studio di registrazione.

Internet è uno strumento che se saputo usare può davvero rendere il mondo migliore e la disabilità solo un piccolo dettaglio.

In conclusione

Grazie a Elena, che ancora una volta ha contribuito a lasciare una testimonianza preziosa della sua esperienza, condividendo le sue conoscenze e buona parte di quello che ha vissuto sulla propria pelle in questi anni.

Tengo particolarmente a chiudere questa intervista con un video di un suo intervento al TEDxAssisi: Share to fight prejudice.

Buona visione.

HTML5 diventa W3C Recommendation

HTML5Il 28 Ottobre 2014 HTML5 è passato allo stato di W3C Recommendation.

La notizia non può passare inosservata ed è destinata a cambiare anche in Italia l’approccio alla realizzazione di siti web accessibili.

Le parole riportate sul blog di The Paciello Group sono perfette per capire i vantaggi di HTML5:

HTML5 is a great leap forward for an accessible web. In HTML5, accessibility is a core design principle. For the first time the semantics of HTML have been mapped, and implementation requirements defined in terms of the way HTML semantics are conveyed to people using assistive technologies.

The addition of new interactive controls, native video and captioning and new structural elements in HTML5, make it easier than ever for developers to create HTML interfaces that are usable by everyone. The inclusion of WAI-ARIA in HTML5 also provides developers with the tools and information to create accessible custom content and controls that extend the core features of HTML.

Continua a leggere HTML5 diventa W3C Recommendation »

Accessibilità? Sì, grazie

Il mondo sta diventando sempre più accessibile: il web non può rimanere indietro.

voiceover

È ormai da diverso tempo che non parlo di accessibilità su questo blog, ma questo non significa che l’argomento sia ormai da dimenticare. Al contrario il tema è più che mai vivo senza che sia necessariamente legato alla parola “accessibile”, anche in contesti diversi dal web.

Qualche esempio?

Continua a leggere Accessibilità? Sì, grazie »

Il web design è morto?

Essere un esperto di HTML e CSS ormai non è sufficiente: è tempo di specializzarsi.

Con l’inizio del 2014 è tornata alla ribalta una discussione non del tutto nuova: conoscere HTML e CSS è sufficiente per potersi considerare dei web designer professionisti?

La risposta è no.

È iniziato tutto dal post di Jeff Croft: Web Standards killed the HTML star.
Abbiamo attraversato un periodo in cui lavorare con IE6 ci provocava incubi ogni giorno: essere un web designer significava saper risolvere in pochi secondi i problemi più assurdi.

È stata dura battersi per il riconoscimento degli standard web e per un comportamento coerente tra tutti i browser, ma alla fine i risultati sono arrivati. Gli standard erano importanti proprio perchè i browser si comportavano in maniera diversa, con un grande caos per tutti.

Continua a leggere Il web design è morto? »

Form accessibili: come usare le label

Guida all’uso delle label nei form HTML, per un sito più accessibile.

Esistono due metodi HTML per contrassegnare un campo di un form con un’etichetta.

Il primo è usare l’attributo “for” sulla label, con un valore corrispondente all’id dell’elemento associato:

<label for="email">email:</label>
<input type="text" id="email" />

Il secondo è inserire il campo del form all’interno della label:

<label>email: <input type="text" /></label>

Personalmente preferisco il primo metodo, ma il secondo è comunque valido e riconosciuto come corretto.

Continua a leggere Form accessibili: come usare le label »

Quando usare gli access key?

Usare gli access key non è un requisito fondamentale per un sito accessibile: in molte occasioni sono inutili e creano confusione.

Per molto tempo l’utilizzo degli access key è stato considerato un requisito fondamentale per un sito accessibile. Fornire delle scorciatoie da tastiera potrebbe a prima vista sembrare una soluzione intelligente, ma nella realtà dei fatti non è sempre così.

Come funzionano gli access key?

Associando ad un elemento di tipo a, area, button, input, label, legend e textarea l’attributo accesskey=”…” , è possibile indicare al browser una scorciatoia per raggiungere quell’elemento. Generalmente per utilizzare l’access key è necessario premere alt in combinazione con il tasto indicato.

I problemi degli access key

Il problema fondamentale è che non è mai stato definito uno standard su quali elementi di un sito debbano essere raggiungibili tramite access key. Considerando poi che non esiste nemmeno una regola su quali lettere utilizzare, il risultato è decisamente caotico.

Non solo un utente dovrebbe imparare per ogni sito degli access key diversi, ma potrebbe anche trovare dei conflitti con altre scorciatoie già definite dal sistema. Ogni browser infatti ha delle abbreviazioni predefinite per accedere ai menu (File, Modifica, ecc…), ed ognuno di loro si comporta in maniera diversa: in certi casi gli access key hanno la precedenza, in altri no.

Un altro fattore da considerare è che gli utenti utilizzatori di screen reader utilizzano molte altre scorciatoie, anche queste da aggiungere alla lista.

Inserire degli access key in una pagina non assicura quindi la possibilità di raggiungere velocemente determinati link, ma potrebbe aumentare la confusione. Se siete interessati ad approfondire il discorso, vi consiglio di leggere parte del capitolo 14 del libro “Accessibilità: guida completa” di Michele Diodati, dove questi problemi vengono descritti ampiamente. Il testo è di qualche anno fa ed alcuni esempi non sono aggiornati, ma è ancora oggi utilissimo.

Come fornire delle scorciatoie?

E’ comunque importante fornire dei metodi per muoversi all’interno di una pagina anche senza mouse. La soluzione migliore, ormai largamente diffusa, è quella di inserire degli skip link per saltare al contenuto principale di una pagina o al menu di navigazione. Solitamente queste scorciatoie sono posizionate ad inizio pagina, nascoste via CSS, e permettono a chiunque di andare immediatamente al contenuto desiderato.

Una soluzione di questo tipo è inserita anche nelle tecniche consigliate per adempiere al punto 2.4.1 delle WCAG 2.0.

La possibilità di utilizzare gli access key rimane, ma da requisito è passata a suggerimento: considerando i possibili problemi il mio consiglio è di trovare soluzioni alternative e non utilizzarli. Su questo sito ad esempio è presente uno skip link per saltare al contenuto, visibile anche premendo il tasto tab dopo il caricamento della pagina.

[foto di alcomm]

L’utopia del codice HTML valido

Uno spunto di riflessione sulla realizzazione di progetti con codice HTML valido.

Perchè esistono gli standard HTML? La risposta è semplice: deve esserci una base comune su cui poter sviluppare, e questa base deve essere capita e condivisa da tutti, per evitare incomprensioni e incompatibilità.

I problemi

In questo scenario, esistono numerose società che sviluppano applicazioni e tecnologie basate su un linguaggio come l’HTML: il loro nemico più grande è il codice non valido. Basti pensare a come sarebbe molto più semplice lavorare sempre su pagine validate, prive di errori e warning, anche semplicemente durante lo sviluppo di un sito web. Se però iniziano ad essere presenti errori e codici non standard, ecco che una gran parte del tempo verrà impiegato per correggere questi problemi. Se si parla poi di progetti come la creazione di un nuovo motore di rendering o di un browser, il tempo perso in questa direzione sarà ancora maggiore.

A questo proposito è illuminante un post di Rebuilding the Web riguardo al linguaggio HTML ed all’importanza della sua validità. L’autore dell’articolo racconta la sua esperienza in una piccola azienda che progettava la realizzazione di un browser standard-compliant: era impossibile pensare di gestire tutte le eccezioni generate dal codice non valido con un piccolo team di lavoro. Per questo i motori di rendering sul mercato restano sempre gli stessi, a meno che qualche soggetto importante non decida di investire, potendoselo permettere. Anche Apple e Google hanno deciso di puntare su Webkit (open-source) per Safari e Chrome piuttosto che realizzare un proprio rendering engine: la spesa sarebbe stata troppo elevata.

Meno del 10% del web ha codice valido

La colpa di tutto questo è proprio da ricercare nella diffusione del codice HTML non valido: se l’intero web non avesse errori non ci sarebbero problemi, ma è chiaro che questa rimarrà un’utopia. In passato ci sono state anche delle discussioni sul comportamento dei browser: c’era chi proponeva di visualizzare solo le pagine con codice valido, ma questo significherebbe impedire l’accesso a più del 90% dei siti web.

I dati che si trovano sulla rete sono impressionanti:

  • una ricerca del 2001 di Dagfinn Parnas, analizzando i siti indicizzati su dmoz.org, ha rivelato che solo lo 0.71% aveva codice HTML valido.
  • nel 2006 Rene Saarsoo ha ripetuto lo studio, ed i siti validi erano diventati il 2.58%.
  • un progetto di ricerca di Opera del 2008, chiamato MAMA, ha analizzato 3 milioni e mezzo di pagine e quelle valide erano il 4.13%.

Fortunatamente la tendenza è in aumento, ma i numeri restano ridicoli ed per ora ben poco influenti.

L’utopia di un web migliore

Con un quadro di questo genere, è facile comprendere come le conseguenze del codice HTML non valido riguardino tutti. Se utilizzate un qualsiasi browser, o a maggior ragione uno screen reader, un editor WYSIWYG o un motore di ricerca state pagando la presenza di milioni di pagine web errate. Enormi risorse continuano ad essere investite per gestire gli errori contenuti in queste pagine, ed in futuro lo scenario non sarà molto diverso.

Non esiste una soluzione immediata al problema, ma se una pagina web può essere validata senza grande sforzo, perchè non impegnarsi a raggiungere questo obiettivo? Anche questi sono costi di sviluppo da considerare, ma esistono anche dei vantaggi: una pagina valida non ha problemi ad essere visualizzata in tutti i browser e viene indicizzata senza problemi dai motori di ricerca.

Nel vostro prossimo progetto pensate seriamente alla validità del codice HTML, con un minimo di attenzione in più darete il vostro contributo per un web migliore.

[foto: Heberger Site]

I problemi di validazione con i CSS3

Utilizzare i CSS3 significa spesso avere fogli di stile non validi. Come affrontare il problema?

Uno dei problemi principali nell’utilizzo dei CSS3 è la creazione di fogli di stile con codice valido. I CSS2 sono ormai uno standard, ma non è così per le nuove specifiche.

Escludendo qualche rara eccezione, la maggior parte delle proprietà hanno nomi diversi e sono supportate in maniera differente a seconda del browser: questo non semplifica il lavoro degli sviluppatori. Basti pensare ad una proprietà ormai diffusa su tutti i browser (escludendo il solito Internet Explorer): border-radius. Su Firefox è necessario utilizzare il prefisso “moz-“, su Safari e Chrome bisogna anteporre “webkit-“ , ed ognuna di queste forme ovviamente non è riconosciuta dal W3C.

Il risultato è che se si desidera utilizzare i CSS3 per dare ad una parte dei propri utenti una migliore esperienza di navigazione, non sarà possibile validare il foglio di stile.

Come comportarsi in questo caso? L’unica soluzione è trovare un compromesso. Su questo sito ad esempio l’unica proprietà particolare che ho utilizzato è text-shadow, ben supportata nella sua forma standard. Ho invece trascurato proprio border-radius e altre proprietà simili, che però utilizzo su altri progetti come il mio blog personale, dove sono meno rigido per quanto riguarda la validazione dei CSS.

La colpa di questa situazione è da attribuire soprattutto alla lentezza del W3C, perchè i produttori di browser stanno dimostrando una grande attenzione alle novità. Supportare certe funzionalità è comunque motivo di vanto sulla concorrenza. Non è possibile però chiedere ai produttori di utilizzare fin da subito la forma standard delle proprietà: le specifiche potrebbero cambiare prima del raggiungimento della loro forma standard.

Proprio sull’uso dei CSS3 sarei curioso di conoscere anche il vostro punto di vista: li utilizzate? Vi preoccupate della validazione del foglio di stile?

Uno dei migliori suggerimenti sull’argomento, segnalato su CSS3.info, riguarda una possibile modifica al validatore del W3C. La soluzione ideale infatti sarebbe vedere segnalate come “experimental” o “warning” le proprietà dei CSS3 ancora sperimentali, consentendone l’uso senza problemi. Gli errori sparirebbero per la felicità di tutti, ma è una speranza probabilmente troppo ottimista.

Il W3C abbandona XHTML, il futuro è HTML 5

La presa di posizione del W3C: stop allo sviluppo di XHTML 2 per portare avanti solo HTML 5.

W3C LogoIl W3C ha chiarito la sua posizione sul futuro della specifica XHTML: con una news pubblicata il 3 Luglio ha chiuso lo sviluppo di XHTML 2, per dedicare tutte le risorse al futuro HTML 5.

Dalle notizie della settimana appena conclusa infatti è possibile leggere:

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML.

Una decisione sicuramente importante per il futuro di chi sviluppa sul web, ma non così sorprendente come potrebbe sembrare. Ammetto di avere sperato in XHTML 2, ma i segnali colti fino ad ora non sono mai stati rassicuranti. Quest’ultima notizia è solo la conferma della strada fortemente voluta e consigliata (in modo più o meno forzato) da Google e dai vari sviluppatori di browser, che da tempo stanno spingendo per la specifica HTML 5.

Alla luce di quanto accaduto la decisione di Dave Shea, sviluppatore americano, che ha deciso di abbandonare XHTML da qualche tempo, non appare così sbagliata. Ne avevo parlato nel post “Abbandonare XHTML?”, ma in ogni caso non c’è alcun motivo di avere fretta di cambiare. Per quanto mi riguarda resto fermo sulla mia posizione: finchè HTML 5 non sarà pienamente supportato, XHTML 1.0 resterà la mia scelta principale; è semplicemente arrivato il momento di approfondire lo studio della nuova specifica per chi non l’avesse ancora presa in considerazione, visto che tra qualche tempo sarà largamente diffusa.

Come punto di partenza vi segnalo le Faq del W3C sul futuro di XHTML, ed il post “HTML 5: approfondimenti ed evoluzioni future”, dove troverete diversi link utili.

A proposito di tempi: quanto ci vorrà per vedere HTML 5 supportato da tutti i principali browser? Sicuramente qualche anno, ma la data potrebbe non essere così lontana. In alcuni casi certe funzionalità sono già ben supportate, e questo indica che gli stessi produttori hanno interesse a seguire la specifica. Non sarà comunque un cambiamento improvviso: c’è tutto il tempo per documentarsi ed approfondire.

Abbandonare XHTML?

E’ logico abbandonare XHTML in attesa di HTML 5? Un approfondimento sulle recenti discussioni in rete.

Tutto è iniziato con un post di Dave Shea su Mezzoblue, che sollevando non poco stupore ha dichiarato:

Back to HTML 4.01 Strict for now, then HTML5 whenever that happens.

Un salto indietro di svariati anni, per tornare a realizzare pagine in semplice HTML, abbandonando una specifica ben più rigorosa come l’XHTML.

Questo cambiamento è da interpretare in proiezione futura, per via del supporto di alcuni browser (Opera soprattutto) e dell’attuale stato delle specifiche. Non è un mistero che XHTML 2 sia ancora indietro, mentre con HTML 5 sia già possibile ottenere dei risultati: ne avevo parlato anche in un articolo sui form.

La discussione per quanto riguarda l’Italia è proseguita su Edit, dove nei commenti del post Bye Bye XHTML si scontrano le due posizioni. Chi difende il web semantico e XHTML ha le sue ragioni, ma non è così incomprensibile appoggiare la semplicità di HTML 5.

E’ veramente ora di abbandonare XHTML?

La risposta a questa domanda va in controtendenza con quanto affermato da Dave Shea.

La specifica XHTML infatti è attualmente la scelta migliore.

Che senso avrebbe tornare a HTML 4? Dal mio punto di vista sarebbe un passo indietro, non giustificabile guardando al futuro. E’ lecito prepararsi a HTML 5, diversi siti lo stanno già facendo, ma il suo supporto è appena agli inizi: qualsiasi cambiamento è ancora prematuro. Ovviamente è un’opinione personale, se la pensate diversamente mi farebbe piacere discuterne nei commenti.