Il software funziona. Ma per chi? L’accessibilità che il Service Desk non misura

Il software funziona. La persona non riesce a usarlo

Una collega apre il portale aziendale per richiedere un dispositivo. Il login riesce, il monitoraggio è verde, ma il pulsante di conferma non è raggiungibile dalla tastiera. Un'altra persona non distingue il messaggio d'errore, indicato soltanto dal colore. Una terza non riesce a concludere la procedura con un lettore di schermo. Sono esempi ipotetici, ma rappresentano difetti tecnici riproducibili: nessun server è fermo, eppure il lavoro è bloccato.

Il Service Desk potrebbe rispondere «prova un altro browser» oppure «chiedi a un collega». In questo modo il problema passa dal prodotto alla persona. La disponibilità resta ottima, mentre il tempo perso sparisce dai report. L'accessibilità digitale riguarda anche software, documenti e strumenti interni, non soltanto siti rivolti al pubblico.

Quando diciamo che un servizio funziona, che cosa misuriamo davvero? L'uptime è necessario, ma non dimostra che tutte le persone possano completare le attività per cui il servizio esiste.

Standard e persone: cosa è cambiato nel 2026

Nel settembre 2026 ETSI ha pubblicato EN 301 549 versione 4.1.1, dedicata ai requisiti di accessibilità dei prodotti e servizi ICT. È un riferimento tecnico per chi progetta, acquista o verifica tecnologie. La sua applicabilità obbligatoria dipende da normativa, settore e contratti: non ogni software interno di un'impresa privata ricade automaticamente negli stessi obblighi.

Il W3C propone le WCAG 2.2 per il web e la guida WCAG2ICT, pubblicata come Group Note nel dicembre 2025, per interpretare alcuni criteri anche in software e documenti non web. La Group Note è informativa, non uno standard vincolante. Separare standard, guida e obbligo di legge evita di creare confusione e permette di usare bene ciascuna fonte.

L'indagine EU-OSHA OSH Pulse 2025, svolta su oltre 28.000 lavoratori, considera l'uso delle tecnologie digitali insieme ai rischi psicosociali e alle condizioni di lavoro. Non attribuisce automaticamente uno specifico disagio a un singolo difetto software; invita però a guardare le tecnologie anche dal lato degli effetti sulle persone.

Il ticket invisibile: quando un workaround non è una soluzione

Immaginiamo che una richiesta di ferie non possa essere inviata usando soltanto la tastiera. L'operatore suggerisce il mouse e chiude il ticket come «workaround fornito». Per chi non può usare quel dispositivo non è una soluzione. Se serve un collega per completare la richiesta, vengono meno autonomia e forse riservatezza. Il ticket chiuso non prova il ritorno al lavoro.

Una segnalazione utile distingue tre cose: il passaggio tecnico che non funziona, l'attività rimasta bloccata e la misura temporanea che consente davvero di completarla. Non serve indagare diagnosi o raccogliere dati personali superflui. Serve descrivere una barriera riproducibile.

Il difetto deve arrivare a un owner di prodotto: team applicativo, responsabile del portale o fornitore. Il Service Desk non diventa un laboratorio di accessibilità, ma impedisce che un problema di qualità finisca nella categoria generica «errore utente». Se la stessa barriera torna dopo ogni rilascio, la sua ricorrenza merita un Problem Management.

Quattro prove che un normale collaudo può dimenticare

Prima di dichiarare riuscito un rilascio, aggiungerei quattro prove sui percorsi essenziali. Completare l'attività senza mouse, verificando focus e comandi da tastiera. Capire errori e stati senza dipendere soltanto dal colore. Ingrandire i contenuti senza perdere informazioni o azioni. Usare una tecnologia assistiva compatibile sulle schermate più importanti.

Non sono una certificazione e non sostituiscono un audit specialistico. Sono controlli di servizio che possono intercettare ostacoli prima della produzione. Le WCAG 2.2 forniscono criteri verificabili; WCAG2ICT aiuta a ragionare anche sui programmi non web, con i limiti e le differenze del caso.

Il punto è ripetere le prove. Una nuova versione può rompere un pulsante che prima funzionava. Un aggiornamento può togliere il testo a un errore o cambiare l'ordine di navigazione. Il deployment è riuscito, ma il servizio è peggiorato. Le verifiche di regressione dovrebbero includere login, richieste, autorizzazioni e comunicazioni.

Misurare le barriere senza classificare le persone

Una dashboard non deve contare quanti dipendenti hanno una disabilità. Deve misurare difetti e processi compromessi: tempo al ritorno operativo, ticket riaperti, barriere ricorrenti, workaround utilizzabili e correzioni definitive. Il denominatore può essere il numero di transazioni o rilasci osservati, non una categoria personale.

Anche la priorità va ripensata. Un problema che coinvolge poche persone può impedire un'attività essenziale, come accedere alla busta paga, seguire la formazione obbligatoria o approvare una richiesta. E se è inaccessibile il portale di assistenza, la persona potrebbe non riuscire neppure ad aprire un ticket. I canali alternativi devono essere provati, non soltanto annunciati.

Ascoltare volontariamente persone con modalità d'uso differenti aiuta a vedere ciò che i test automatici non intercettano. Non significa trasformarle in collaudatori permanenti. Significa trattare il loro feedback come evidenza sul prodotto, rispettando privacy e autonomia.

Un esperimento di trenta giorni per il Digital Workplace

Partirei da un processo interno frequente, come una richiesta di accesso. Prima settimana: ricostruire il percorso e rileggere i ticket archiviati come «problema utente». Seconda: eseguire le quattro prove, registrando schermata, passaggio e risultato. Terza: assegnare ogni barriera a un owner, con correzione prevista e misura temporanea verificata. Quarta: ripetere i test dopo gli interventi.

Porterei in service review due evidenze: quali attività sono tornate completabili e quali dipendenze restano aperte. Non prometterei percentuali di miglioramento senza una baseline. Il valore sta nel collegare il problema a una responsabilità e a una verifica successiva.

Alla prossima riunione in cui qualcuno dirà «servizio disponibile», aggiungerei una domanda: disponibile per fare che cosa, e per chi? Il Service Desk può essere il punto in cui una barriera digitale smette di sembrare un problema individuale e diventa finalmente un problema di servizio da risolvere.

Per rendere il test replicabile, conserverei una scheda essenziale: versione dell'applicazione, browser o ambiente, sequenza di passaggi, risultato atteso, risultato osservato e verifica dopo la correzione. È un piccolo investimento documentale che evita di ricominciare ogni volta da zero. E rende la conversazione con i fornitori più concreta: non una sensazione di difficoltà, ma una prova che si può ripetere.