Continuiamo nella nostra traduzione delle interviste di Chris Heilmann ai personaggi notevoli del mondo HTML5: la chiacchierata di oggi è con John Foliot (@johnfoliot su Twitter), co-presidente della sottocommissione per l'accessibilità di elementi multimediali in HTML5 e un grande lottatore per rendere più accessibile questo pazzo pazzo web.

John è stato in giro per il web, mailing list e incontri W3C più di quanto abbia voglia di ricordare ed è sempre stato la voce della ragione quando si trattava di rendere il web accessibile a tutti pur usando tutte le nuove tecnologie. Poiché questo è un argomento spesso tralasciato nel contesto di HTML5 abbiamo pensato fossa una buona idea parlarne. Ecco allora le dieci domande per John Foliot.

1) C'è un po' di confusione su ciò che davvero HTML5 sia. Il W3C si è fatto un bell'autogol con il rilascio del logo HTML5 descrivendolo come un "ombrello" che comprendeva anche altre tecnologie. Qual è la tua definizione di HTML5?

Per me HTML5 è la nuova versione di HTML – Hyper Text Markup Language – che sarà standardizzato dal W3C a tempo debito. E' una evoluzione di HTML4.01/XHTML1.1, che non è stato aggiornato dal dicembre 1999. In sostanza, una delle basi fondamentali per il supporto di tecnologie Web aperte.

Comprendo, tuttavia, che in termini di marketing e comunicazione di massa un termine che descrive il principale "movimento" in ambito web development è per definizione astratto. La discussione sul nome e il branding è andata avanti per un po' tempo e ho il sospetto che la maggior parte degli sviluppatori minimamente interessati sappiano già che il "blocco" di tecnologie Web aperte che stiamo usando ha bisogno di un nome (il mio amico Bruce Lawson l'ha soprannominata NEWT).

Ma ormai i buoi sono scappati dalla stalla, e il brand è HTML5. Così, quando gli sviluppatori di oggi si parlano tra di loro credo che tutti sappiano cosa si intende per HTML5. HTML5 è diventata anche il modo per il mondo di capire ciò che stiamo facendo e così non penso sia il caso di preoccuparsi troppo di un nome di marketing. Nel corso del tempo verrà coniata una nuova "buzz word", il mondo andrà avanti e HTML5 significherà lo standard per il linguaggio di markup ipertestuale – versione cinque.

2) Sembra che ci sia due fonti di "verità" su HTML5: il WHATWG e il W3C. Quando considerare uno o l'altro gruppo come il più importante? Qual è il rapporto tra loro?

Il loro rapporto? Complicato.

Due gruppi diversi possono condividere un obiettivo comune e il lavoro insieme può portare a progressi. Ma è un lavoro duro.

Il WHATWG ha un ruolo utile – direi fondamentae – nella nascita e lo sviluppo di molte tecnologie Web Open. Con il sostegno di molti (ma non tutti) i produttori di browser e una condivisione delle idee tecniche (compresi esperimenti e analisi da parte di team diversi) si è arrivati a miglioramenti nella tecnologia. E' il paradiso degli ingegneri e di chi è abituato a lavorare in modalità AGILE – perfetto, per l'appunto, per gli ingegneri. E' un posto molto emozionante, dove le nuove idee emergono, vengono scritte specifiche di massima, poi raffinate e cercano un supporto relativamente diffuso da parte dei browser in beta per poi venire implementate dai browser "consumer"

Tuttavia quelle specifiche potrebbero non essere ancora complete e anche se in corso di definizione spesso l'implementazione varia da browser a browser, e le carenze (purtroppo spesso per quanto riguarda l'accessibilità) sono significative.

Il WHATWG sta lavorando su una specifica che è in costante evoluzione – che è un bene, da un lato, ma che rende molto difficile per i soggetti di grandi dimensioni al di fuori dei produttori di browser tenere il passo. Progetti su larga scala richiedono una maggiore stabilità di quello che una "specifica vivente" è in grado di fornire, ovvero una specifica che per sua stessa natura è in costante cambiamento.

Basta pensare a questo recente commento sul blog di uno sviluppatore:

"La parte peggiore è che non si può semplicemente cercare blog / forum o spulciare la documentazione per capire come risolvere i problemi dal momento che nessuno sa come fare queste cose. Le informazioni vengono superate in maniera veramente veloce con il rilascio di una nuova versione del sistema operativo, la documentazione è molto povera e non copre i casi-limite, le specifiche sono in continua evoluzione e le diverse versioni di IOS adottano un diverso insieme di regole… " – e pensare che stava solo cercando di far funzionare il tag <video> su iPad!
Senza dimenticare che, per problemi organizzativi e politici, non tutti gli interessi costituiti sono parte del processo WHATWG, il che può essere problematico, sebbene non insormontabile.

Ad esempio Microsoft non è parte della WHATWG, e probabilmente mai lo sarà. Possiamo inveire contro IE ma con una quota di maggioranza nel mercato dei browser non possiamo ignorarlo. Così il WHATWG ha le mani un po' legate da questa situazione.

Tutti sanno come io sia un accanito sostenitore del W3C che credo fermamente porti meglio di tutti la bandiera per le Tecnologie Web a livello globale. Il W3C è qualcosa di più che "siti web nel browser": i loro standard cercano di coprire un ampio spettro di tecnologie correlate che tutti possono sfruttare per rendere la rete più "grande" e migliore, e per quanto possibile il W3C si impegna a garantire che tutti possano lavorare insieme. Si tratta di un'organizzazione globale che ha il sostegno finanziario e il supporto di governi nazionali, istituzioni accademiche e aziende tecnologiche. Prendo atto tuttavia che come ogni grande entità a volte può scontrarsi con un movimento più rapido e agile – ma la burocrazia è un male necessario in qualsiasi organizzazione di livello mondiale.

Per una persona più giovane, coinvolto nella battaglia quotidiana che è questa nuova tecnologia, questo ritmo può sembrare – comprensibilmente – frustrante, ma gli ingegneri che lavorano in grandi aziende come IBM, Microsoft, ecc, sono già abituati a questo. Nessuno è costretto a farselo piacere, ma il mondo va così.

Il WHATWG esplora idee e sistema i dettagli, il W3C stabilizza, analizza in profondità e "pubblica" un documento a cui tutti possano fare riferimento. Entrambi i ruoli sono importanti, ognuno è unico.

Per quanto riguarda la fonte di "verità", lascio ad altri decidere…

3) Tu sei un forte sostenitore dell'accessibilità. Riesci a vedere le nuove tecnologie aperte come un beneficio per l'accessibilità o ce la stiamo dimenticando?

Credo che molto di ciò che HTML5 sta cominciando a produrre sarà di beneficio a tutti gli utenti, compresi quelli che utilizzano tecnologie assistive. Molto di ciò che viene promesso, però, non è ancora supportato in tutti i browser e le tecnologie correlate – tecnologie di supporto – hanno ancora molta strada da fare per sfruttare appieno queste funzionalità.

Per esempio gran parte dei motori di rendering dei browser non fanno l'elaborazione nativa degli elementi "landmark" (credo che Firefox 4 utilizzi un motore di rendering HTML5) e il supporto per altre parti della specifica che hanno un impatto sull'accessibilità è ancora carente. Una ragione di più per ottenere uno standard HTML5, certamente un Candidate Recommendation al W3C.

Credo che delle cose su cui il WHATWG sta lavorando presentano alcuni problemi di accessibilità, per fortuna molto di meno adesso rispetto a quando si era iniziato a lavorare e a scrivere su HTML5.

Nel complesso, sono piuttosto contento di vedere quanto la consapevolezza per l'accessibilità sia cresciuta e che si sia creato un dialogo produttivo tra ingegneri e specialisti di accessibilità.

4) Un sacco di siti-vetrina di HTML5 mostrano effetti speciali ma l'accessibilità resta sempre il fanalino di coda. Non c'è interazione con la tastiera e la mancanza di test per il supporto di tecnologie assistive. Si trovano link che non vanno da nessuna parte e HTML che viene memorizzato nel documento per un utilizzo futuro – come tutta una serie di messaggi di errore che vengono mostrati e nascosti quando necessario. Cosa si potrebbe fare per questo? Qual è il tuo messaggio agli sviluppatori per far capire che l'accesso da tastiera e soluzioni di fallback non-JavaScript sono importanti?

Penso che parte del problema, forse la parte più grande, è la mancanza di cultura. Le barriera di ingresso per la creazione e la pubblicazione di pagine e siti web sono estremamente basse: ogni cretino può farlo, e così anche i cretini lo fanno – senza capire a fondo che cosa stiano realmente facendo. Mi fa ancora più male vedere siti web e blog che consigliano alcune di queste tecniche sbagliate come "il modo giusto", continuando ulteriormente pessime abitudini.

Penso che uno degli altri problemi, con particolare riguardo alle problematiche di accessibilità, è che molti sviluppatori con un qualsiasi background di ingegneria trovano molto comodo, se non vitale, il processo di sviluppo agile: si scrive codice, si prova, rottura, si risolve il problema, si prova, si rompe di nuovo, correzione, … Non riesco a ricordare quante volte ho sentito "Questa è solo la nostra prima versione, ci aggiungereme la roba di accessibilità nella prossima release." Il problema è che l'accessibilità è relegata al ruolo di 'richiesta di funzionalità' invece di 'requisito fondamentale'. Anche in questo caso, è un problema di istruzione e cultura: gli sviluppatori mainstream devono capire e impegnarsi a rendere l'accessibilità un requisito fondamentale, che aiuta a definire le decisioni funzionali e tecniche che saranno la base del loro progetto.

L'accesso tramite tastiera è un requisito importante per molti utenti, non solo con disabilità. La massiccia crescita dei contenuti web creati per i dispositivi mobili sta aiutando gli sviluppatori a diventare più consapevoli di questo. Sfido qualunque developer che legge questo pezzo a rimuovere la batteria dal proprio mouse wireless per un giorno e verificare i propri siti. Questo è forse uno dei più facili "test di accessibilità" che ogni sviluppatore può fare, non richiede strumenti speciali (hardware o software) eppure ha un enorme impatto sugli utenti non vedenti e gli utenti con varie forme di disabilità motoria.

Per quanto riguarda JavaScript le W3C Web Content Accessibility Guidelines 2 (WCAG 2) sono più tolleranti di quanto WCAG 1 sia stato. Praticamente tutti i browser oggi supportano JavaScript e lo scripting lato client è un pezzo necessario per l'infrastruttura del web moderno: ricordate che la maggior parte di Adaptive Technology interagisce con questi browser web quindi le insidie e i problemi del basarsi su JavaScript per funzionalità 'mission critical' sono ugualmente presenti per tutti gli utenti. Ancora una volta, la vera risposta a questo problema è l'istruzione e la mentalità.

5) Parliamo di tecnologie assistive. Visto che markup e scripting non dovrebbero essere pensati solo per i browser abbiamo bisogno di sapere ciò che gli screen reader, per esempio, possono fare. A che punto è il supporto per le nuove tecnologie?

In primo luogo io definisco le tecnologie assistive come un insieme di strumenti software off-the-shelf, programmi specializzati e varie combinazioni di hardware, tutti sono Assistive Technology: Dragon non serve solo a scrivere dettando, fornisce una soluzione hands-free per l'interazione di utenti con problemi gravi di mobilità; gli screen reader sono programmi che comunicano tra browser, interfaccia utente e sistema operativo, sfruttando le API di accessibilità; le barre in Braille collegata a vari dispositivi che le supportano. Soluzioni a livello di sistema operativo come VoiceOver sono un vantaggio per gli utenti non-vedenti (permettendo loro di interagire con i loro iPhones e iPads) e possono altresì essere considerate Assistive Technology.

Gli screen readers sono software sofisticati e mentre alcuni come NVDA stanno attivamente lavorando per tenere il passo con i miglioramenti in HTML5 la maggioranza è purtroppo (credo) in attesa di uno standard più formale prima di impegnare risorse per riscrivere il loro software. Se questa è la decisione giusta o no non è il punto – non è un questione filosofica, è un fatto.

E' un cane che si morde la cosa, ed è uno dei motivi per cui continuo a consigliare che lo sviluppo di software per la produzione proceda con cautela nell'usare le nuove tecnologie "HTML5". La cartina di tornasole è il fatto che ARIA è supportata abbastanza bene attualmente dagli screen reader e gli sviluppatori possono tranquillamente contare di più su ARIA insieme a tutte le altre chicche HTML5. Molti delle attuali librerie UI JavaScript (come YUI3 e jQuery UI) possono dare una mano così gli sviluppatori che hanno così la possibilità di usare un robusto e sano mix di soluzioni tecnologiche "vecchie" e nuove.

6) Una cosa molto importante per rendere un documento comprensibile per la tecnologia assistiva è il mantenimento di un ordine logico, soprattutto quando si tratta di heading. Con HTML5 abbiamo sezioni e articoli, hgroups e un ordine degli heading specifico per alcune parti del documento, piuttosto che per l'intero documento. Esiste anche una "outline implicita" del documento. Come si comportano le tecnologie assistive con questo? Finiremo per bloccare o limitare l'accessibilità agli utenti facendo la cosa "giusta" in HTML5?

Questo è in realtà un tema di grande attualità, recentemente (Gennaio 2011) molti sono giunti a mettere in discussione la fattibilità e l'utilità dell'elemento hgroup in HTML5. Il processo W3C è tale per cui la discussione su questo tema è stata rinviato a più tardi questa primavera, il Gruppo di lavoro sta cercando di cancellare vecchi bug e problemi che sono stati sollevati prima della fine di settembre 2010. Credo che attualmente nessun browser supporti hgroup.

L'algoritmo di "outline" è una grande idea, che non ha ancora visto però l'attuazione o il sostegno da parte delle tecnologie assistive. L'idea è che il browser dovrebbe euristicamente sapere che un elemento <hx> dovrebbe essere al livello "giusto" (diciamo <h3>) sulla base del suo contesto e della sua 'eredità'.

Questo rende il contesto e la struttura di un documento composito più leggibile e comprensibile dal DOM fino all'interfaccia utente, sia essa l'interfaccia grafica del browser o Adaptive Technology. In sostanza il browser 'riscrive' il livello del heading. La necessità di fare qualcosa di simile a questo è già stata capita e ripetuta da qualche tempo: XHTML2 aveva proposto innumerevoli <h>, cosa che avrebbe permesso di raggiungere lo stesso obiettivo ma per qualche strano motivo (probabilmente la semplice avversione nei confronti di XHTML2 come standard "sbagliato") l'idea non è stata portata nel gruppo di lavoro HTML5. Nonostante la mancanza di supporto per questa caratteristica, tuttavia, l'uso appropriato degli heading nei "pezzi" di contenuto è un requisito importante per gli utenti (e in particolare gli utilizzatori degli screen reader) – anche se l'ordine del DOM è 'sbagliato' gli screen reader usano gli heading per facilitare la navigazione della pagina. Oggi gli heading non sono solo belli (e talvolta – spesso – usati male), ma anche utili.

Le sezioni e gli articoli sono due elementi che non hanno ancora un supporto effettivo nei browser (anche se credo che Firefox 4 inizierà a supportarli in maniera nativa) per cui in questo momento sono ancora nella fase "questo idea è concettualmente buona ". Tuttavia i browser che non hanno il supporto nativo per questi elementi li trattano come div non-semantici e quindi con l'aggiunta di ruoli ARIA oggi possono essere ben navigabili / accessibili alle tecnologie assistive. Pensando al futuro, cercare le soluzioni migliori penso che sia una delle cose che gli sviluppatori possono iniziare ad attuare oggi – basta non dimenticare i ruoli e i landmarks ARIA.

7) Una cosa che mi è piaciuta molto nella specifica HTML5 è la definizione di figure e didascalie. Tuttavia, quando si usano e si desidera dare supporto alle tecnologia assistive è necessario utilizzare "labelled-by" di ARIA e assegnare un ID univoco per ogni figura per collegarla logicamente con la didascalia. Uno sforzo in più che molti sviluppatori non faranno. Trovo un sacco di cose ARIA estremamente verbose – ci sono gli sforzi volti a semplificare la comunicazione tra i diversi organi standard?

Assolutamente!

ARIA come tecnologia/specifica è presente da molto tempo – quasi 10 anni – ma è stato solo negli ultimi 3 a 5 anni che abbiamo visto un vero supporto in strumenti quali gli screen reader. ARIA però è stata pensata come una tecnologia ponte, progettata tanto per la soluzione di problemi attuali quanto per lo sviluppo futuro: tornare indietro e aggiungere pezzettini di codice al vostro widget per renderlo accessibile. A causa di questo, sì, purtroppo il codice prodotto non è sempre elegante e compatto. E' stato comunque un problema "è nato prima l'uovo o la gallina" da quando è stata avviata.

Uno dei pezzi importanti di lavoro che l'accessibilità su cui la W3C TaskForce si è concentrata è stata garantire che la funzionalità ARIA venga integrata e mappata "all'indietro" sui nuovi elementi di HTML5 e gli attributi. Anche se questo lavoro non è ancora completo c'è un impegno a garantire che essa sia ultimata prima che HTML5 (inteso come linguaggio di markup, versione cinque) diventi una raccomandazione finale.

Guardando i due esempi che hai indicato – figure e didascalie – il piano strategico è che questi siano mappati direttamente dal parser del browser e diventino utilizzabili alle API di accessibilità così che nel tempo "funzioneranno" – come promesso dagli slogan.

Aggiungere gli attributi ARIA oggi è una soluzione per rendere i tuoi contenuti a prova di futuro ma anche garantire che siano accessibili oggi. Per molti versi è molto simile ai "vendor prefixes" utilizzati in CSS3: l'ideale sarebbe dichiarare semplicemente la proprietà ma perché è ancora una tecnologia in evoluzione oggi abbiamo bisogno di anteporre alla proprietà un prefisso del venditore (come per esempio: -moz-margin-end, -webkit-margin-end in cui è necessario dichiarare due volte nel foglio di stile per indicare la proprietà a entrambi i browser). Stesso concetto di base: è vero, più lavoro per gli sviluppatori, ma non c'è una soluzione alternativa più facile.

8) Quali sono secondo te i problema principali di video e audio HTML5 ad oggi? E' la mancanza di opzioni per proteggere i contenuti premium? O la mancanza di un formato supportato per i sottotitoli e le didascalie? I guai di codifica?

A dire il vero penso che tutto quanto tu hai indicato sia da attribure ad una mancanza di maturità dello standard.

La questione codifica rimarrà (credo) una danza complicata fra politica e tecnologia per un bel po' di tempo e al produttore di contenuti multimediali non resta altra scelta che codificare due volte se vuole usare il tag <video> nativo su tutti i browser. Ad HTML5 al momento manca un mezzo per supportare pienamente le esigenze definite degli utenti con necessità diverse, anche se l'elemento <track> proposto sicuramente aiuterà in questo ambito (ma per quanto ne sappia io nessun browser lo supporta ad oggi o supporta la possibilità di estrarre dati <track> via una interfaccia nativa).

Per quanto riguarda il formato timestamp, temo che si tratti di un dibattito non ancora concluso (nonostante il sostegno schiacciante WG per WebSRT, cioè WebVTT o qualsiasi altra cosa decidono di chiamarlo). Penso che la garanzia di uno standard unico è venuta a cadere quando la SMTPE (Society of Motion Picture and Television Engineers) ha annunciato che loro supportano SMPTE Time Text Format, basato su TTML. Quando i fornitori di contenuti commerciali rendono nota la loro idea sul formato supportato si potrebbe sospettare che i produttori di browser (viste le pressioni da parte di distributori di contenuti online) prestino attenzione (soprattutto visto l'attuale stato d'animo verso le didascalie web a Washington). Mentre nessun browser oggi ha espresso una chiara posizione in merito, ho la sensazione che almeno Microsoft probabilmente supporterà entrambi gli standard.

Gli argomenti riguardanti i controlli DRM e il controllo genitoriale – certamente due temi molto impopolari per una generazione che è nata utilizzando torrent e feed da The Pirate Bay – sono due questioni che dovrebbero essere affrontate, ma probabilmente non lo saranno presto e questo ritarderà ulteriormente l'attuazione e la diffusione capillare della tecnologia video HTML5, a mio parere: i fornitori di contenuti commerciali vorranno una qualche forma di DRM, anche se può essere crackato – il cracking diventerebbe un atto penalmente rilevante come acquisire illegalmente il digital asset.

Nel frattempo, soluzioni alternative al <video> nativo, da Flash e Silverlight a QuickTime stesso, hanno tranquillamente implementato soluzioni DRM per i clienti desiderosi di avere questa forma di tutela per il loro contenuto – tipo Netflix. Quello che trovo curioso è che molte di quelle voci forti che denunciano DRM non hanno alcun problema ad acquistare MP3 su iTunes (che può essere condiviso solo su 3 macchine registrate con Apple).

9) Il canvas sembra essere un altro grande problema di accessibilità. Sei a conoscenza di soluzioni per rendere i cambiamenti del canvas comprensibili alle tecnologie di assistenza? Il formato SVG soffre delle stesse controindicazioni?

Hai ragione, il canvas rimane una sfida difficile per l'accessibilità. Purtroppo non mi sono concentrato su questo aspetto come ho fatto sui media ma ho fede e fiducia che il popolo dell'accessibilità stia sistemando i problemi. Richard Schwerdtfeger (IBM) è il presidente del sub-team Accessibilità Canvas ed è un ingegnere molto intelligente, e tutti i produttori di browser sono attivamente in discussione in questo sub-team. Ciò che posso vedere è che c'è un consenso generale sulla sottostruttura DOM, anche se il supporto cross browser per la soluzione ancora non c'è. Restano problemi con focus con il tasto "^" e l'interazione textMetrics con ingranditori di schermo, così come il modo per comunicare il posizionamento assoluto dei contenuti agli zoom dello schermo e screen reader che fanno uso di Braille.

SVG, come tecnologia, è molto diversa da canvas e per lo più ci sono pochi problemi di accessibilità. Ecco una bella analisi delle caratteristiche di accessibilità di SVG.

10) La soluzione ormai accettata da tutti per usare in sicurezza le nuove tecnologie sembra essere il rilevamento della compatibilità. Si prova se il browser supporta qualcosa prima di applicarlo. Questo non ha mai funzionato però con le tecnologie assistive. Perché? Perché non possiamo semplicemente usare un if (window.screenreader) ?

Ci sono una serie di ragioni per cui questo non è fattibile.

Prima di tutto "screen reader" è una classe di strumenti software che si comportano tutti in modo leggermente diverso. E' vero che oggi nel mondo di lingua inglese "occidentale" il pacchetto software JAWS detiene una quota di mercato maggioritaria ma alternative come WindowEyes, Hal / Supernova, ZoomText e nuove interessanti soluzioni come NVDA e Serotek o SAToGo stanno sfidando lo status quo. Eppure nessuno di questi strumenti si comporta esattamente allo stesso modo e a volte il loro approccio utente-interfaccia può essere molto diverso. Aggiungiamo strumenti stranieri come il coreano Sense Reader Professional e il brasiliano Leitor de canvass – per citarne solo due – e riconoscere che è presente un lettore di schermo diventa un po' inutile: se sai che sto usando SAToGo (per esempio) che cosa significa per il developer, alla fin fine?

Le cose stanno messe peggio anche peggio, a dire il vero: non solo è necessario tenere conto della marca dello screen reader ma anche della versione. Mentre WebAIM Screen Reader's Survey dello scorso anno ha confermato che la maggior parte degli utenti aggiorna il loro software (il 74,6% entro il primo anno) ciò lascia ancora quasi 1 utente su 4 che utilizza un software che può essere vecchio di 3 anni o più. Gli sviluppatori hanno bisogno di ricordare anche che gli screen reader non fanno parte del browser ma sono piuttosto uno strumento al livello del sistema operativo che dunque non interagiscono solo con il browser ma anche con altri software come editor di testo, applicazioni di foglio elettronico e strumenti per la produttività.

Infine, cosa dire su VoiceOver? L'opzione di lettura dello schermo a livello di sistema operativo di Apple è virtualmente presente in ogni sistema che distribuiscono oggi, da OSX a iOS – non vi è alcuna garanzia che semplicemente perché è presente sia utilizzato o che la persona che lo utilizzi è di fatto cieco. Molti utenti vedenti hanno un legittimo bisogno o desiderio di utilizzare la tecnologia di lettura dello schermo, come VoiceOver ha confermato, e dunque adattare un'esperienza mirata agli screen reader è, purtroppo, uno sforzo da non perseguire – alla fine i contra potranno essere maggiori dei pro. (Mi ricorda i siti web che costringono gli utenti con telefonino ad una versione alternativa del loro sito mirato e ottimizzato per dispositivi mobili senza fornire alcuna possibilità di arrivare alla versione completa del sito, anche se l'utente lo vuole).

Quello che voglio ricordare agli sviluppatori è questo: rispettate gli standard, pensate alla graceful degradation nonché al miglioramento progressivo, e ricordare sempre i "tre pilastri" dello sviluppo web: la separazione di contenuto, design e scripting. Ricordo anche che le persone con disabilità hanno un "obbligo morale" di aggiornare il proprio software (né più né meno di qualsiasi altro utente, chi supporta Netscape 4 oggi?) e/ma il progettista/sviluppatore deve sempre considerare un "Piano B" per l'interazione utente – se il "Piano A" fallisce, qual è il "Piano B"?

L'intervista originale è qui, il video (HTML5, grazie a Vid ly):