Esplorare l'impegno di Rocket Software per l'accessibilità

La nostra missione in Rocket Software va oltre la semplice fornitura di soluzioni innovative. Ogni aspetto del nostro lavoro è guidato dai nostri valori più ampi: Empatia, Umanità, Fiducia e Amore. E all'interno di questi valori, Rocket Software pone grande enfasi sull'accessibilità. Indipendentemente dalla tecnologia, dal sistema o dall'ambiente IT, ci impegniamo a fornire soluzioni che funzionino per tutti.

Per saperne di più sul nostro approccio alle soluzioni dal punto di vista dell'accessibilità, abbiamo incontrato Brian Kunz, Principal Software Architect di Rocket Software.

Brian vanta oltre 20 anni di esperienza nella creazione e progettazione di applicazioni front-end. Si è dedicato completamente all'accessibilità nel 2024, guidando il progetto di sviluppo dei componenti di accessibilità fondamentali necessari per la nuova interfaccia utente di Rocket Content Services, Rocket Content Explorer.

Come definiresti l'accessibilità dal punto di vista del software e dello sviluppo?

Dal punto di vista software, si tratta di far funzionare la tastiera con l'applicazione. L'interfaccia della tastiera è il driver per qualsiasi tecnologia assistiva come gli screen reader. Se qualcosa deve essere manipolato sullo schermo, deve poter essere manipolato tramite una serie di comandi da tastiera; questi comandi sono comuni e noti agli utenti finali. Come utente finale, dovrei essere in grado di fare tutto in un'applicazione senza mai toccare il mouse.

Ci concentriamo così tanto sulla creazione di applicazioni basate sul mouse: è questa la mentalità che deve cambiare.

Dal punto di vista dello sviluppo, l'accessibilità è una competenza, una competenza che la maggior parte degli sviluppatori non possiede. Questo valeva per me e per tutti gli sviluppatori che hanno lavorato al nostro nuovo progetto di interfaccia utente.

Le pratiche agili sono probabilmente un fattore chiave per cui l'accessibilità non è più al centro dell'attenzione. Storicamente, gli sviluppatori si sono concentrati sull'aspetto dell'applicazione e sul funzionamento del mouse quando viene cliccato; questa è stata la soglia per considerare completata una funzionalità. E una volta completata quella funzionalità, si passa alla successiva, perché l'obiettivo è aggiungere quante più funzionalità possibile.

Quindi, l'accessibilità diventa vittima del tempo a favore del "realizzare una funzionalità". Non è che gli sviluppatori non vogliano creare applicazioni accessibili, ma abbiamo trascurato l'importanza di programmare per l'accessibilità perché richiede tempo aggiuntivo. Anche l'attenzione del management è un fattore da considerare, poiché programmare per l'accessibilità richiede un po' più di tempo e impegno da parte di tutti i soggetti coinvolti.

L'accessibilità può essere considerata una competenza secondaria di cui non si parla né si promuove l'importanza, ma è un aspetto che vorremmo cambiare. Vogliamo che l'accessibilità diventi parte integrante di qualsiasi progetto.

In parole povere, puoi spiegare i quattro principi delle Linee guida per l'accessibilità dei contenuti Web (WCAG) e spiegare perché sono importanti?

Esiste un acronimo per questo: POUR. Sta per Percepibile, Operabile, Comprensibile e Robusto.

Cominciamo con la percepibilità. È così che si crea un'applicazione complessa che sia visivamente accattivante e ben progettata, in modo che le relazioni tra gli elementi visivi sullo schermo possano essere comunicate anche a chi non ha la vista. Ad esempio, come fa un utente a sapere che c'è un pulsante che, se premuto, visualizza un nuovo pannello di informazioni a cui può accedere? Oppure, quando si esegue un'operazione e la schermata cambia anche in modo impercettibile, in che modo questo cambiamento viene comunicato all'utente in modo diverso da quello visivo? Percepibilità significa dipingere un'immagine nella mente di qualcuno di dove si trova in un'applicazione e di come è strutturata.

Quando parliamo di "operabile", intendiamo che qualsiasi elemento manipolabile deve essere accessibile tramite la tastiera. E riconosciamo che le tecnologie assistive includono anche opzioni come il riconoscimento vocale per gli utenti con disabilità motorie, poiché le tastiere potrebbero non essere un'opzione. "Operabile" significa che tutto ciò che può essere manipolato, come un pulsante, una casella di riepilogo, un input di testo e così via, deve essere azionabile tramite tastiera o comando vocale. Questo crea sfide uniche per operazioni che tradizionalmente vengono eseguite con il mouse, come il trascinamento e il ridimensionamento. Quando si programma per l'accessibilità, dobbiamo considerare il mouse non come il mezzo principale di modifica, ma semplicemente come un altro strumento. Non vogliamo escludere funzionalità come il clic e il trascinamento semplicemente perché un utente non può usare un mouse.

Il passo successivo è la comprensibilità. Garantire che qualcosa sia comprensibile significa garantire che qualsiasi widget funzioni come l'utente si aspetta. Le tecnologie assistive identificano gli elementi su uno schermo e condividono messaggi come "pulsante" o "tabella" quando un utente naviga. Questo tipo di descrizione di base spiega all'utente come può manipolare quell'elemento, nonché come utilizzare le comuni scorciatoie da tastiera fornite dalle tecnologie assistive. Ad esempio, se un utente sa che ciò che è in primo piano è una casella combinata, sa che può attivarla tramite il tasto Invio o il tasto freccia giù, ecc. Come sviluppatori, dobbiamo garantire che le attività e l'ordine delle attività per un particolare elemento corrispondano all'esperienza attesa per un utente che si affida alle tecnologie assistive, altrimenti si crea uno scenario che crea confusione per l'utente e una tecnologia che non può essere utilizzata in modo efficace.

Infine, arriviamo alla robustezza. Esistono convenzioni di codifica e attributi che gli sviluppatori dovrebbero utilizzare per garantire che il nostro software funzioni con qualsiasi tecnologia assistiva. Gli standard WCAG sono il contratto che noi sviluppatori rispettiamo e che viene utilizzato anche dagli sviluppatori delle tecnologie assistive. Finché entrambi i gruppi di sviluppo fanno la loro parte, otteniamo un'esperienza funzionale e accessibile per i nostri utenti finali. Codifichiamo secondo uno standard, non per una specifica tecnologia assistiva.

La robustezza riguarda la scrittura di software che funzioni con diversi altri user agent e tecnologie assistive. L'altro aspetto della robustezza è che un utente può muoversi rapidamente all'interno dell'applicazione con poche azioni da tastiera. Se gli sviluppatori hanno progettato un'applicazione correttamente, questa consente a un utente con una tastiera di spostarsi rapidamente tra le varie aree dello schermo senza dover premere il tasto Tab per scorrere ogni singolo controllo o ogni singolo elemento sullo schermo.

Per le persone daltoniche, come è possibile garantire che le linee guida sul contrasto dei colori siano rispettate nel design di un sito web o di un'applicazione e quali tipi di strumenti si possono utilizzare?

WCAG raccomanda un rapporto tra i colori di primo piano e di sfondo: 4,5 a 1. È un po' difficile descrivere esattamente cosa significhi, ma riguarda le sfumature di colore tra il primo piano e lo sfondo nell'applicazione.

Come possiamo determinarlo? Si parte dalle prime fasi del design. Abbiamo utilizzato uno strumento chiamato Figma per creare wireframe complessi per l'applicazione. Questo strumento ci aiuta a garantire che il design stesso non violi il rapporto di contrasto del colore. Vogliamo evitare di progettare qualcosa che riteniamo abbia un bell'aspetto e di dedicargli tempo e risorse, per poi renderci conto che non supererà i controlli di contrasto del colore.

C'è anche uno strumento che utilizziamo nel browser chiamato Accessibility Insights; si tratta di un plugin del browser che puoi attivare per qualsiasi pagina e che ti segnalerà se ci sono violazioni del rapporto di cui ho parlato prima. Lo strumento può anche visualizzare l'applicazione in scala di grigi, un modo semplice per vedere cosa è stato sviluppato, eliminando completamente il colore dall'equazione e vedendo come appare con il contrasto in scala di grigi e valutando la facilità di distinzione degli elementi.

Quali strategie avete utilizzato per educare e promuovere le migliori pratiche di accessibilità tra i team di sviluppo e progettazione?

Quindi, potrebbe spaventarvi guardare le specifiche WCAG. Sono grandi. Sono molto tecniche e sembrano difficili da assimilare. Ma una volta superato il fastidio iniziale, diventa tutto molto semplice una volta che si incastra. È una cosa che è successa anche a me nel mio percorso. Sapevo di doverlo fare, ed era la cosa giusta da fare.

Ho scoperto che, una volta acquisita questa consapevolezza, ho un rinnovato entusiasmo per l'accessibilità. Programmare in questo modo rende le nostre applicazioni molto più efficaci e, dopotutto, non è poi così complesso... e inizi a chiederti perché hai evitato queste strategie di programmazione fino ad ora.

Il mio obiettivo è rendere la programmazione per l'accessibilità una seconda natura per gli sviluppatori front-end, in modo che non venga percepita come un'attività superflua o come difficile o non degna di essere affrontata. Ho aiutato il nostro team di sviluppo fornendo schemi di base sui design visivi per valutare l'accessibilità. Come esperto del team, ho potuto dire: "Ehi, quando create questa schermata, considerate questi aspetti per la schermata e questi vari altri elementi per l'accessibilità". Hanno applicato queste pratiche durante il completamento della loro programmazione e noi le abbiamo poi valutate durante il nostro processo standard di revisione del codice. C'era sempre qualche piccolo ritocco da apportare perché era una novità per tutti; stavamo sviluppando nuove competenze e tutti stavano imparando. Quindi, abbiamo testato e modificato il codice fino a ottenere l'esperienza che desideravamo.

Grazie a questa esperienza, ho creato una serie di video di formazione progressiva, disponibili per tutti i partecipanti al programma Rocketeer che desiderano integrare l'accessibilità. Ho generato quasi 5 ore di contenuti: non sarà un'attività che richiederà molto tempo. Questi video forniscono un'introduzione per comprendere i concetti di base e imparare come metterli in pratica con una piccola applicazione di esempio.

Il mio obiettivo è eliminare la paura di adottare gli standard WCAG dimostrando che è piuttosto semplice. Inoltre, i nostri team hanno sviluppato una libreria di widget per l'interfaccia utente che gestisce già la maggior parte degli aspetti di accessibilità, quindi questo aiuterà altri team a creare prodotti migliori in futuro utilizzando questi widget. Gli altri team non dovranno preoccuparsi dell'accessibilità all'interno di quel widget perché è già gestita per loro.

Hai suggerimenti o trucchi da condividere con gli sviluppatori o i team che stanno appena intraprendendo un percorso verso l'accessibilità?

Il mio consiglio è di usare HTML5 come è stato concepito. In questo modo si ottiene un'elevata accessibilità gratuitamente. Poi, quando si programma per un design visivo, si presta attenzione agli elementi di base.

Se qualcosa rappresenta un elenco di contenuti, usate gli elementi elenco veri e propri in HTML5. Se qualcosa si comporta come un pulsante, trasformatelo in un pulsante. Se presentate dati tabulari, usate gli elementi tabella perché le tecnologie assistive forniranno informazioni semantiche ai loro utenti se usate questi elementi di base. Come sviluppatori, tendiamo a usare contenitori generici che hanno uno stile che li fa apparire come qualcosa di specifico e poi applichiamo manualmente i gestori di clic. Questa è la via più semplice e crea qualcosa che ha un bell'aspetto ed è cliccabile con il mouse, ma non ha alcun significato per chi utilizza una tecnologia assistiva. Utilizzare gli elementi di base di HTML5 vi darà almeno metà di ciò di cui avete bisogno.

In termini di risorse tecniche, c'è una pagina dedicata ai pattern. Questa è stata la risorsa che mi ha davvero fatto capire tutto. Questa pagina contiene specifiche per ogni singolo tipo di widget che si possa desiderare; contiene esempi, esempi di codice, specifiche di tastiera per vari elementi, ecc. È anche possibile utilizzare una tecnologia assistiva come JAWS per testare i widget di esempio e vedere come JAWS gestisce le cose. È stato un modo meraviglioso per capire, quando ho iniziato a imparare, che programmare per l'accessibilità non è poi così difficile; ho dovuto solo cambiare alcune cose mentre scrivevo.

Qual è la cosa più interessante che hai imparato lavorando a un progetto incentrato sull'accessibilità?

La risposta semplice è che vedo il valore fondamentale dell'empatia di Rocket Software in ciò che stiamo facendo. Vogliamo che il nostro software sia utilizzabile da tutti. Come ho detto prima, nel nostro mondo di sviluppo agile, ci concentriamo sul percorso più rapido per realizzare una funzionalità e questo ci porta a scrivere applicazioni che potrebbero escludere determinati utenti. Questo non è intenzionale e non c'è malizia, ma possiamo facilmente trascurare le persone con disabilità e non considerare la loro esperienza e le difficoltà che potrebbero incontrare nell'utilizzo del nostro software.

Dobbiamo cambiare la nostra mentalità riguardo a tutto ciò a cui diamo il nome Rocket Software. Si tratta di essere consapevoli delle diverse esigenze dei nostri utenti e di non creare strumenti esclusivi, anche se ciò significa che le cose richiedono un po' più di tempo per essere codificate e testate. Ecco perché voglio che le strategie di programmazione accessibile diventino una seconda natura per i nostri sviluppatori, in modo che non pensino necessariamente "Lo faccio per l'accessibilità" – al contrario, è una parte fondamentale della programmazione per qualsiasi progetto.

Il futuro mi entusiasma. Le nuove funzionalità che abbiamo introdotto offrono un grande potenziale. Ora sto valutando come utilizzare strumenti come Rocket^® Content Smart Chat per colmare le lacune nell'interazione con i contenuti all'interno di un'applicazione, e non solo con l'applicazione stessa. Ad esempio, se presentiamo a un utente un documento contenente un'immagine, Rocket^® Content Smart Chat potrebbe fornire un riepilogo dell'immagine e informare l'utente dicendo "Questa è un'immagine di XYZ" oppure fornire un riepilogo di un documento dicendo "Questo documento è una ricevuta di pagamento per materiali acquistati". Funzionalità come questa potrebbero far risparmiare tempo agli utenti. Non dovrebbero più leggere l'intero documento per poi rendersi conto che non è quello che cercano.

Invece, ricevono rapidamente il riepilogo e possono poi passare al compito successivo. Credo che possiamo fare ancora di più utilizzando tecnologie all'avanguardia per migliorare ulteriormente la nostra esperienza accessibile.

È entusiasmante per me e sono molto orgoglioso di essere all'avanguardia in questo tipo di iniziative a livello interno. Offrire agli utenti questa esperienza WCAG è una svolta.

Scopri di più sulle ultime funzionalità di Rocket Content Services .