Accessibilità... sul back-end?

Puoi leggere questo articolo in inglese qui.

Quando si parla di accessibilità digitale, la maggior parte delle persone pensa che le pratiche di questo argomento siano eseguite solo da sviluppatori e designer di frontend. Se è vero che la maggior parte del lavoro è in queste aree, chi lavora con il backend non è del tutto escluso da questo argomento.

Ma io, lo sviluppatore del backend, non mi occupo del layout dello schermo, scrivo una mezza dozzina di righe di HTML una volta nella vita, come potrei essere d'aiuto in questo scenario?

Beh, c'è sempre un modo. Di seguito riporto alcune idee di azione da persone di backend nell'area dell'accessibilità.

Prestazione

Non è una novità che sentiamo che è estremamente importante eseguire ottimizzazioni delle prestazioni nelle applicazioni, e questo di solito ha due ragioni principali:

• Le prestazioni possono essere un fattore decisivo per l'utente per completare un acquisto , e la mancanza di prestazioni su un sito può comportare la perdita di potenziali clienti;
• Google considera il punteggio delle prestazioni del sito come un criterio di ranking della ricerca .

L'utente impiega in media 3 secondi per rinunciare ad accedere a una pagina perché non è ancora stata caricata . Ma immaginiamo uno scenario in cui l'utente sia insistente e disposto a spendere “tutto questo tempo” in attesa: proprio all'ingresso del sito avrà già una brutta impressione, eventualmente la lentezza provocherà un'ansia o un'irritazione che può ( e probabilmente influenzerà il resto dell'esperienza sul sito.

Internazionalizzazione

L'internazionalizzazione è tutta una questione di accessibilità. In pratica, entrambe le tecniche hanno un obiettivo comune: far capire all'utente il contenuto sullo schermo .

Questo è un lavoro che dipende molto dall'applicativo che si sta sviluppando per essere considerato “back work” o “front work” (o entrambi), ma una cosa è certa: quando si sviluppa qualcosa pensato per essere multilingue, il lavoro deve essere fatto di coerente internazionalizzazione. Chi non è mai entrato in un sito “tradotto” in portoghese, ma ha notato diversi testi in inglese? Sì, non seguire quell'esempio.

OH! Questo sembra essere troppo semplice persino da menzionare, ma è molto comune dimenticarlo nella vita di tutti i giorni: usa l'attributo langin HTML, di solito è usato nell'elemento radice della pagina ( tag html) ma può anche essere usato quando una parte specifica della pagina è in una lingua diversa rispetto al resto del sito. Questo attributo è molto importante per il browser per identificare la lingua utilizzata nella pagina e suggerire traduzioni automatiche basate sulla lingua del browser dell'utente.

imparare le basi

Anche se non fa necessariamente parte della tua vita quotidiana, è consigliabile sapere cos'è l'accessibilità e come funziona nel contesto di un'applicazione Web/Mobile. Spesso gli sviluppatori di back-end generano pagine HTML e, quando lo fanno, tali pagine potrebbero non essere strutturate nel modo più intuitivo possibile.

Parla con i colleghi di altre aree

Se il tuo team ha già una certa maturità in relazione all'accessibilità in aree come frontend e design, parla con persone di queste aree per scoprire come viene svolto questo lavoro e come puoi aiutarli. Forse manca solo un campo descrittivo per gli alt dell'immagine o informazioni extra nei dettagli del prodotto, e sì, questi dettagli sembrano così piccoli da essere insignificanti, ma insieme ad altri miglioramenti finiscono per fare una grande differenza.

Limite di tempo per completare le azioni

Il tempo non dovrebbe essere una limitazione che impedisce all'utente di completare un'attività, ovvero, se l'utente ha bisogno di 5 minuti o 1 ora per inviare un modulo, così sia, l'applicazione deve essere preparata per entrambi gli scenari.

Certo, non possiamo ignorare il fatto che ci sono diverse limitazioni tecniche che possono impedirci di fornire questo, ma è sempre bene evitare questo tipo di problema che genererà solo frustrazione per l'utente. Inoltre, come spiega il W3C , ci sono alcune eccezioni a questa regola:

• Eventi in tempo reale: ci deve essere un limite di tempo per l'attività, come un'asta online.
• Attività in cui il tempo è essenziale: il tempo è essenziale e l'aumento del limite renderebbe l'azione non valida, come un'offerta a tempo limitato su un sito di e-commerce.
• Limite di 20 ore: sebbene sia improbabile che un'attività richieda più di 20 ore consecutive per essere completata, questo è stato scelto come limite dal W3C, dopodiché è consentito un limite di tempo.

Come raccomanda il W3C , dobbiamo fornire un modo per mostrare il significato di un'abbreviazione quando viene utilizzata nella pagina, al fine di aiutare gli utenti che:

• avere difficoltà a decifrare il significato di un acronimo;
• fare affidamento su lettori di schermo;
• avere una memoria limitata;
• hanno difficoltà ad utilizzare il contesto in cui si trova per comprendere il significato dell'acronimo.

riautenticazione

Immagina il seguente scenario:

La mia band preferita di tutti i tempi sta suonando in uno spettacolo vicino a dove vivo e ho la rara possibilità di realizzare questo sogno di vederli. Sapendo già che la competizione per garantire i biglietti sarà grande, lascio tutta la mia registrazione pronta sul sito, aspettando solo che i biglietti vengano rilasciati per l'acquisto. Quando finalmente i biglietti diventano disponibili, garantisco il mio, inserisco i dati della mia carta e tutto, ma… quando vado a finalizzare l'acquisto, la mia sessione va in crash. In quel momento mi prende la disperazione, mi autentico velocemente e quando provo a procedere con l'acquisto vedo il triste messaggio... biglietti esauriti .

Una situazione "una specie di" noiosa, giusto? Così è.

OK, questo è un problema, ma cosa c'entra con l'accessibilità?

Non si tratta, infatti, di un problema esclusivo di accessibilità, ma se già questa situazione provoca grande fastidio agli utenti che non hanno alcuna limitazione, immaginate per chi può usare solo il mouse, o dipende da uno screen reader per navigare?

Ecco perché dobbiamo stare attenti quando implementiamo flussi che richiedono l'autenticazione, l'utente deve poter continuare la sua attività senza perdere alcun dato se la sua sessione scade. In questo scenario di ticket, ci sono alcune soluzioni che alleviano il problema:

• Estendere periodicamente il tempo della sessione mentre l'utente è attivo sul sito;
• Prenotare il biglietto e salvare i dati del modulo man mano che l'utente lo digita, nel caso in cui per qualche motivo non sia in grado di completare la compilazione e voglia continuare successivamente;
• Fornire un'opzione per eseguire nuovamente l'autenticazione senza lasciare la pagina corrente e continuare il flusso dopo la riautenticazione.

Negli scenari in cui è possibile cercare contenuti per testo, è interessante disporre di un meccanismo che suggerisca contenuti con nomi simili, nel caso in cui il sistema sospetti che ci sia un errore di ortografia nella ricerca. In questo modo evitiamo la necessità per l'utente di effettuare una seconda ricerca, correggendo il suo errore e solo successivamente trovando ciò che desidera.

Come per molte cose quando si tratta di accessibilità, la correzione ortografica aiuta tutti i tipi di utenti, ma soprattutto le persone con un basso livello di istruzione e le persone con qualche tipo di deterioramento cognitivo come la dislessia.

Concludendo

Ok, ma cosa succede se nessuno di questi suggerimenti si applica al mio backend quotidiano? Devo ancora avere conoscenze sull'accessibilità?

Ebbene, poiché l'area della tecnologia è sempre più popolare e inclusiva, e l'ingresso di nuove persone (compresi i PCD) è in aumento, una conoscenza di base dell'argomento può aiutare non solo le persone sviluppatori di backend, ma tutti i membri del team , quindi possiamo comprendere le esigenze non solo degli utenti per i quali sviluppiamo i sistemi, ma anche di eventuali collaboratori che potrebbero avere tali esigenze.

Vale anche la pena ricordare che non solo le persone che lavorano con il frontend, il backend, il design e il QA sono responsabili dell'accessibilità, ma chiunque attraversi qualsiasi fase della progettazione di un software può contribuire.

Riferimenti

• Sì, anche l'accessibilità è un problema di backend (Eric Bailey)
• Timing regolabile — Limiti di tempo comportamenti richiesti (W3C)
• Abbreviazioni (W3C)