Ci sono eventi che non rappresentano semplicemente un momento di aggiornamento tecnologico. Sono occasioni che lasciano un segno nel proprio percorso professionale e umano.

Per me, il Google I/O è sempre stato uno di questi.

Negli anni in cui ero manager del GDG Pisa, organizzare gli eventi Google I/O Extended era uno degli appuntamenti più importanti della nostra community. Non si trattava soltanto di seguire un keynote o commentare le ultime novità annunciate da Google: era l'occasione per riunire sviluppatori, designer, studenti e professionisti attorno a una passione comune, condividendo idee, esperienze e visioni sul futuro della tecnologia.

Ricordo ancora l'entusiasmo che si respirava durante quelle giornate. Le discussioni dopo gli annunci, i confronti tecnici, le domande su come le nuove tecnologie avrebbero influenzato il nostro lavoro e, soprattutto, la sensazione di far parte di una comunità che cresceva insieme.

Guardando indietro, molte delle innovazioni presentate in quegli anni sono ormai diventate parte integrante del nostro lavoro quotidiano. Altre, invece, hanno richiesto molto più tempo per maturare.

Tra queste c'è sicuramente il tema dell'accessibilità.

L'accessibilità come parte integrante dell'innovazione

Per molti anni l'accessibilità è stata percepita come qualcosa da affrontare in una fase successiva dello sviluppo.

Prima si costruiva il prodotto.

Poi, eventualmente, si cercava di renderlo accessibile.

Chi lavora nel settore sa bene quanto questo approccio sia limitante. L'accessibilità non dovrebbe essere un'aggiunta successiva, ma una caratteristica nativa della progettazione.

Negli ultimi anni il web ha visto una crescita enorme delle applicazioni basate su rendering grafico avanzato: editor visuali, strumenti collaborativi, piattaforme di design, visualizzazioni dati interattive e persino applicazioni complete sviluppate quasi interamente attraverso il canvas.

Tutto questo ha portato grandi vantaggi in termini di prestazioni e flessibilità, ma ha anche evidenziato un problema storico della piattaforma web.

Il limite storico del canvas

Dal punto di vista delle tecnologie assistive, il canvas è sempre stato una delle sfide più complesse.

Quando un'interfaccia viene renderizzata esclusivamente all'interno di un canvas, il browser non dispone automaticamente della semantica necessaria per descriverla agli screen reader o ad altri strumenti assistivi.

In pratica, elementi fondamentali come pulsanti, campi di input, titoli o strutture di navigazione non esistono più nel DOM come elementi HTML tradizionali.

Questo ha costretto per anni gli sviluppatori a creare soluzioni parallele:

  • layer HTML nascosti;
  • strutture duplicate dedicate agli screen reader;
  • workaround complessi per la navigazione da tastiera;
  • sincronizzazioni continue tra interfaccia grafica e contenuti accessibili.

Soluzioni spesso fragili, costose da mantenere e difficili da testare.

La novità che mi ha colpito di più

Tra le novità che ho seguito quest'anno, una delle più interessanti riguarda proprio l'evoluzione del rapporto tra HTML e canvas.

Con il progetto HTML-in-Canvas, il team Chrome sta esplorando un approccio che permette di integrare elementi HTML direttamente all'interno di contesti canvas, mantenendo la semantica e l'accessibilità offerte dal DOM.

L'obiettivo è molto ambizioso:

  • continuare a sfruttare le prestazioni del rendering grafico avanzato;
  • preservare la semantica HTML;
  • migliorare il supporto alle tecnologie assistive;
  • ridurre la necessità di soluzioni duplicate costruite esclusivamente per l'accessibilità.

Se questa direzione verrà adottata su larga scala, potrebbe rappresentare uno dei cambiamenti più significativi degli ultimi anni per chi sviluppa applicazioni web complesse e accessibili.

Le mie prove pratiche

Da professionista che si occupa quotidianamente di accessibilità, non mi sono fermata alla lettura delle specifiche e della documentazione.

Ho installato Chrome Canary, abilitato le funzionalità sperimentali e testato personalmente diversi esempi pubblicati dal team che sta lavorando alla proposta.

Naturalmente bisogna ricordare che si tratta ancora di una tecnologia in fase sperimentale e che molte implementazioni sono pensate come proof of concept.

Nonostante questo, i risultati sono già interessanti.

Durante le prove ho riscontrato un livello di accessibilità generalmente buono. La presenza di contenuti HTML integrati permette di ottenere una semantica molto più ricca rispetto agli approcci canvas tradizionali e diversi componenti risultano già individuabili e utilizzabili attraverso le tecnologie assistive.

Ci sono ancora aspetti migliorabili e sarà necessario verificare l'evoluzione del supporto nei diversi browser e screen reader, ma la sensazione è positiva.

Per essere una tecnologia ancora agli inizi, il livello raggiunto è già discreto e lascia intravedere un potenziale enorme.

La differenza più importante è che, per la prima volta, non sembra di assistere all'ennesimo tentativo di correggere i limiti del canvas tramite workaround esterni. Si sta invece cercando di affrontare il problema direttamente a livello di piattaforma.

Ed è esattamente questo il motivo per cui considero questa evoluzione così interessante.

Ripensando ai tempi del GDG Pisa

Mentre seguivo gli annunci e provavo queste nuove tecnologie, mi è tornato in mente il periodo in cui organizzavo gli eventi del Google I/O insieme alla community del GDG Pisa.

In quelle occasioni si parlava continuamente del futuro del web.

Di come sarebbe cambiato.

Di quali tecnologie avrebbero influenzato il nostro lavoro negli anni successivi.

Oggi, guardando a iniziative come HTML-in-Canvas, ho la sensazione che il futuro del web non stia diventando soltanto più potente.

Sta diventando anche più inclusivo.

E se c'è una direzione che vale davvero la pena seguire, è proprio questa: costruire tecnologie capaci di innovare senza lasciare indietro nessuno.

Riferimenti