Per le persone non vedenti non c’è niente di più frustrante che cercare di utilizzare un’applicazione per poi scoprire che è inaccessibile. Forse il lettore di schermo non riesce a leggere una parte fondamentale dell’applicazione, o forse non riesce a leggere proprio nulla. Quando le app sono sviluppate utilizzando pulsanti standard, caselle di modifica, elenchi, tabelle o altri elementi dell’interfaccia utente, non è difficile renderle accessibili. Ma alcune applicazioni sono sviluppate utilizzando un toolkit di interfaccia utente non standard, e questi toolkit sono completamente inaccessibili. Implementare l’accessibilità da zero in un toolkit per l’interfaccia utente è difficile e richiede tempo, quindi di solito non viene fatto, tranne che nei pochi toolkit per l’interfaccia utente con un forte sostegno aziendale. A volte è davvero necessario che lo sviluppatore di un’applicazione utilizzi un toolkit di interfaccia utente personalizzato, altre volte no, ma in ogni caso ci ritroviamo con applicazioni inaccessibili.
Questo problema è particolarmente urgente per le app che sono fondamentali per determinati lavori. Non è raro che una persona non vedente non riesca a ottenere un determinato lavoro perché questo richiede l’uso di un’applicazione inaccessibile. Si tratta spesso di applicazioni di nicchia per le quali non si applica il consueto incentivo economico a implementare l’accessibilità, ovvero la vendita ai settori governativo ed educativo. Abbiamo quindi urgentemente bisogno di una soluzione che abbatta il maggior numero possibile di barriere per rendere accessibile la coda lunga delle app.
Come nel caso del lavoro che Pneuma Solutions sta svolgendo sulla bonifica dei documenti e dei contenuti delle riunioni, l’apprendimento automatico può aiutare a risolvere questo problema. Apple è all’avanguardia in questo settore con la funzione di riconoscimento dello schermo integrata in iOS e i risultati ottenuti finora sono promettenti. Tuttavia, questa tecnologia non è ancora disponibile su tutti i computer e dispositivi e i risultati spesso non sono soddisfacenti. Non possiamo aspettare che questa soluzione maturi e venga adottata più diffusamente; abbiamo bisogno di un altro approccio che sia pratico nel breve periodo. Inoltre, molti sviluppatori di applicazioni e di kit di interfacce utente sono disposti a rendere accessibile il loro software, se solo non fosse così difficile e dispendioso in termini di tempo. Questi sviluppatori sono già disposti a venirci incontro; ora dobbiamo fare lo stesso.
È qui che entra in gioco il mio nuovo progetto open-source, AccessKit. L’obiettivo di AccessKit è fornire un’infrastruttura condivisa per rendere accessibili le app, sul maggior numero possibile di piattaforme e linguaggi di programmazione. Con AccessKit, uno sviluppatore che lavora su più piattaforme non dovrà implementare da zero l’accessibilità per ogni piattaforma. Un altro obiettivo di AccessKit è quello di essere meglio documentato e più facile da usare correttamente rispetto alle API di accessibilità esistenti specifiche per ogni piattaforma, come UI Automation per Windows o Cocoa accessibility per le piattaforme Apple. Dopo tutto, un’implementazione non corretta dell’accessibilità può essere frustrante quanto l’assenza di accessibilità.
AccessKit è ancora in fase iniziale di progettazione e sviluppo, ma sta già suscitando l’interesse di altri sviluppatori, compreso il contributo di un altro sviluppatore. E ora ho il grande privilegio di ricevere un finanziamento da Google per lavorare part-time su questo progetto, a partire dall’implementazione per Windows. Sono ansioso di ottenere risultati utilizzabili entro la fine dell’anno.
Sono certo che gli sviluppatori che stanno leggendo vorranno saperne di più su come funzionerà AccessKit. La versione breve è che AccessKit fornirà un’astrazione di accessibilità multipiattaforma, fortemente ispirata al motore del browser Chromium. Questa astrazione si basa su strutture di dati serializzabili, riducendo così al minimo l’overhead dell’interfacciamento tra linguaggi di programmazione. AccessKit sarà implementato principalmente nel linguaggio di programmazione Rust, che offre una combinazione unica di affidabilità ed efficienza. Tuttavia, AccessKit sarà utilizzabile da diversi linguaggi di programmazione. Ulteriori dettagli sono disponibili sul repository GitHub di AccessKit.
In quanto progetto open-source, AccessKit ha bisogno della partecipazione della comunità degli sviluppatori per avere successo e sostenibilità. In particolare, apprezzerei i contributi degli sviluppatori che conoscono bene il linguaggio di programmazione Rust. Il progetto generale di AccessKit è ancora fluido, quindi è troppo presto per delegare molto lavoro di implementazione. Ciò di cui ho bisogno a questo punto è la revisione tra pari, soprattutto da parte di sviluppatori che hanno più esperienza di me con il linguaggio Rust. Se siete interessati, unitevi a noi su GitHub.
Per concludere, uno dei motivi principali per cui ho lasciato Microsoft per fondare Pneuma Solutions è che voglio avere la libertà di lavorare su progetti legati all’accessibilità che credo avranno un grande impatto positivo per la nostra comunità, al di là di una singola piattaforma. Sono ancora entusiasta del lavoro che stiamo svolgendo in Pneuma Solutions e che continuerà. Con AccessKit, ora ho l’opportunità di risolvere un problema che mi sta a cuore da molti anni. Non vedo l’ora di lavorare con la comunità degli sviluppatori di software per rendere accessibili molte più applicazioni.
Lascia un commento