Una visione per lo sviluppo software che supera i limiti dei framework

Nel mondo dello sviluppo software, l’accessibilità è da anni un tema centrale, così come lo è il progressive enhancement, una filosofia che punta a creare esperienze digitali resilienti soprattutto negli ambienti basati su Javascript. Sebbene entrambi i concetti siano fondamentali, raramente vengono considerati in modo congiunto. Con questo articolo, ho unito questi due principi per cercare di formalizzare una nuova metodologia di lavoro, che ho chiamato Accessibility Progressive Enhancement. Il mio obiettivo è dimostrare come questo approccio possa superare le attuali limitazioni dei framework e permetterci di costruire applicazioni e infrastrutture digitali più accessibili.

L’idea fondamentale è semplice: a differenza della cultura che domina l’uso dei moderni framework, dove si tende a mettere in campo tutto e subito, il mio approccio si basa sulla costruzione a strati. Si parte da una base solida e si procede con miglioramenti graduali. L’accessibilità non è un vincolo da aggiungere in seguito, ma il pilastro di un progetto. Con questo approccio, intendo dimostrare che l’accessibilità può e deve essere il motore stesso del nostro lavoro, superando le logiche che rischiano di comprometterla fin dall’inizio.

Il fondamento: una base solida e completa

Il primo passo per costruire un’infrastruttura digitale a misura d’utente è porre un fondamento solido e completo. Questo significa creare un’architettura che funzioni per tutti, indipendentemente dalle tecnologie che si utilizzano. La base è già un applicativo funzionante, che integra i livelli minimi di HTML, CSS e JavaScript per offrire un’esperienza utente coerente e navigabile. A questo si aggiunge un livello base di WAI-ARIA per fornire semantica aggiuntiva che supporti le tecnologie assistive.

L’uso di un HTML pulito e semantico, unito a CSS per lo stile e un JavaScript essenziale per la funzionalità, crea un’esperienza già accessibile e fruibile. L’integrazione iniziale di WAI-ARIA assicura che ruoli e stati chiave siano comunicati correttamente, consentendo a lettori di schermo e altri strumenti di interpretare l’interfaccia.

Questo approccio rispecchia il principio del progressive enhancement: si comincia con l’essenziale, ciò che è universale e garantito per funzionare. Ignorare questo passaggio significa costruire un edificio su fondamenta instabili, che rischia di crollare non appena si presenta un ostacolo, come un browser obsoleto o una tecnologia assistiva.

Il design a livelli: non un progetto, ma una progressione

Oggi, il design è spesso concepito come un oggetto monolitico: i designer creano un progetto completo e definitivo, che deve essere reso operativo dallo sviluppo. Questa visione del design come un oggetto a un solo livello è una delle principali cause del disallineamento con un approccio di sviluppo progressivo.

Per allinearsi al concetto di Accessibility Progressive Enhancement, il design dovrebbe essere concepito in modo altrettanto stratificato. Sarebbe necessario creare prototipi che riflettano i diversi stadi di progressione, in modo che gli sprint di sviluppo possano essere condizionati da questa visione. Si pensi, ad esempio, a una barra di ricerca: inizialmente, il design potrebbe prevedere una versione molto semplice, magari con il solo campo di testo e il pulsante di invio, che genera una pagina di risultati. Questo sarebbe il livello di base, funzionale e accessibile per tutti. Gli sprint successivi potrebbero arricchirla progressivamente con nuove funzionalità: suggerimenti primari durante la digitazione, poi suggerimenti complessi con filtri e immagini, fino ad arrivare a una ricca esperienza di ricerca dinamica.

Questo approccio non limita la creatività del designer, ma la organizza in una progressione logica, creando una roadmap che guida lo sviluppo verso un prodotto finale che non solo è completo, ma è anche intrinsecamente robusto, accessibile e funzionante a ogni livello di complessità.

I framework e la cultura dello sviluppo

Il successo dei moderni framework e delle librerie ha portato un’enorme accelerazione nella produzione di applicativi, ma questo progresso ha un rovescio della medaglia significativo per l’accessibilità. Spesso, questi strumenti incoraggiano un approccio “tutto e subito”, offrendo componenti complessi e ricchi di logica che nascondono la complessità strutturale e semantica sottostante. Questo si pone in netto contrasto con la filosofia del progressive enhancement ed è ciò che genera confusione, sovrabbondanza di informazioni, errori strutturali e di processo.

Di conseguenza, gli sviluppatori si trovano a costruire applicazioni partendo da un’architettura complessa, che integra già stili, comportamenti e logiche sofisticate, anche quando non sono strettamente necessari. La base, invece di essere un solido HTML semantico, diventa una struttura astratta, spesso generata in automatico, che rende più difficile garantire un’esperienza accessibile. Questo processo è rischioso, perché una singola modifica in un componente può compromettere l’accessibilità di intere sezioni dell’applicazione.

Non bisogna leggere questa critica come un invito a non utilizzare un framework. La mia storia professionale è legata a questi strumenti, e so bene quanto tempo ho dedicato e sto dedicando al loro studio e all’evoluzione accessibile. Tuttavia, è fondamentale comprenderne la natura. Un esempio lampante è Bootstrap: la sua missione, implicita nel nome stesso, è fornire un punto di partenza per “avviare rapidamente” un progetto, non l’oggetto finale definitivo. L’approccio Accessibility Progressive Enhancement ne fa un alleato, perché lo considera una base su cui costruire miglioramenti progressivi in modo consapevole e studiato.

Il vero problema non è lo strumento, ma la cultura che a volte lo circonda. Il limite si manifesta quando il framework viene considerato il punto di arrivo, e non il punto di inizio. A peggiorare il quadro c’è la chimera del framework fantastico, che promette di fare tutto da solo, su ogni piattaforma, magari basato su web components per essere anche agnostico rispetto al sistema. Tutte queste promesse portano a condizioni di non consapevolezza, di mancanza di controllo sull’infrastruttura e, di conseguenza, di scarsa accessibilità. E tra tutte le discipline digitali, l’accessibilità è la più fragile.

L’importanza degli sprint di ottimizzazione e i miglioramenti progressivi

Nel mondo dello sviluppo agile, quasi tutti i gruppi di lavoro operano per sprint, ma questa metodologia rischia di essere limitata. Spesso gli sprint sono definiti esclusivamente in base a perimetri funzionali, spingendo a realizzare il maggior numero di funzionalità nel minor tempo possibile. Questo approccio favorisce una mentalità “tutto e subito” che, come abbiamo visto, è nemica dell’accessibilità.

Sarebbe invece fondamentale integrare gli sprint con una visione diversa, che si allinei alla filosofia dell’Accessibility Progressive Enhancement. Non si tratta di limitare le funzionalità, ma di fornirle a strati: nei primi sprint si realizzano le funzionalità di base, quelle che garantiscono a tutti l’accesso al contenuto e alle interazioni essenziali.

Una volta che la struttura di base è solida e accessibile, gli sprint successivi possono essere dedicati ai miglioramenti progressivi. Questi non sono semplici abbellimenti, ma strati successivi di ottimizzazione, ognuno dei quali richiede analisi, studio e professionalità. A questo punto si aggiungono ottimizzazioni come strutture HTML e CSS più evolute per layout e interfacce utente complesse. Si implementa un JavaScript più performante e ottimizzato, che aggiunge interattività sofisticata e dinamicità all’applicazione. Il WAI-ARIA viene perfezionato e ampliato per gestire interazioni complesse.

Questo lavoro richiede un’analisi attenta di ogni singola funzionalità: si deve studiare come renderla non solo efficiente, ma anche accessibile e comprensibile, garantendo che le informazioni e le azioni siano disponibili per tutti. Ad esempio, un widget di autocompletamento può essere migliorato per supportare una navigazione più fluida e intuitiva per gli utenti di tastiera e di screen reader, pur mantenendo un’esperienza di base funzionale per tutti.

Tre vantaggi concreti e un obiettivo raggiungibile

L’adozione di questa metodologia potrebbe non essere un percorso semplice. Potrebbe richiedere tempo, competenza e una profonda comprensione delle metodologie di sviluppo, delle piattaforme informatiche a disposizione e delle esigenze degli utenti. Tuttavia, i vantaggi che ne deriverebbero potrebbero essere significativi e concreti:

1. Massima accessibilità fin dall’inizio. Il primo e più evidente beneficio sarebbe la garanzia di un’esperienza accessibile sin dalle prime fasi del progetto. Le funzionalità di base, rilasciate per prime, sarebbero già ottimizzate per tutti gli utenti, senza esclusioni.
2. Rilascio più rapido sul mercato. Poiché la base sarebbe solida e funzionale, gli applicativi potrebbero essere rilasciati in produzione più rapidamente. Le funzionalità di base sarebbero operative, permettendo al prodotto di essere utile e accessibile da subito, per poi essere arricchito con gli aggiornamenti successivi.
3. Riduzione dei costi e del lavoro post-produzione. Questa metodologia ridurrebbe drasticamente gli interventi di adeguamento all’accessibilità da fare in post-produzione oggi quasi sempre necessari, costosi, spesso mai definitivi.

Integrando più consapevolmente questi principi nei vari processi di produzione, si potrebbero ottenere prodotti non solo più ottimizzati e accessibili, ma si potrebbe anche finalmente aspirare a raggiungere quell’obiettivo dell’accessibilità che oggi rimane un desiderata e che, purtroppo, quasi mai viene raggiunto: non escludere nessuno.