Accessibilità... sul back-end?

Puoi leggere questo articolo in portoghese qui.

Quando si parla di accessibilità digitale, la maggior parte delle persone pensa che le pratiche di questo argomento siano eseguite solo da sviluppatori o designer di frontend. Sebbene gran parte del lavoro riguardi effettivamente queste aree, gli sviluppatori di backend non vengono esclusi dall'argomento.

Ma io, come persona di backend, non sviluppo alcun layout dello schermo, scrivo a malapena alcune righe di HTML ogni tanto, come potrei aiutare in questo scenario con qualcosa?

Beh, c'è sempre un modo. In questo post, porto alcune idee sulle cose che le persone di backend possono fare nel campo dell'accessibilità.

Prestazione

Abbiamo sentito per molto tempo che è estremamente importante ottimizzare le prestazioni nelle nostre applicazioni e questo di solito ha due ragioni principali:

• Le prestazioni potrebbero essere un fattore chiave per l'utente per completare un acquisto e la mancanza di prestazioni su un sito Web può comportare la perdita di potenziali clienti;
• Google ha il punteggio delle prestazioni come fattore di ranking nel suo motore di ricerca .

L'utente impiega in media 3 secondi per rinunciare ad accedere a una pagina perché non è stata ancora caricata . Ma immaginiamo uno scenario in cui l'utente è persistente e vuole passare "tutto questo tempo" ad aspettare: proprio all'inizio del flusso avrà già una brutta impressione, e questa lentezza può causare ansia o rabbia che può (e probabilmente lo farà ) influenzano l'intera esperienza dell'utente.

Internazionalizzazione

L'internazionalizzazione ha tutto a che fare con l'accessibilità. In pratica, le due tecniche hanno un obiettivo comune: rendere comprensibili all'utente i contenuti sullo schermo .

Questo è un lavoro che varia tra i diversi sistemi per essere considerato un "lavoro di backend" o "lavoro di frontend" (o entrambi), ma questo è un dato di fatto: quando si sviluppa qualcosa che è progettato per essere multilingue, è necessario un lavoro di internazionalizzazione coerente Fatto. Ti è mai capitato di entrare in un sito web “tradotto” in inglese, ma di notare diversi testi in un'altra lingua? Sì, non seguire quell'esempio.

OH! Questo potrebbe sembrare così semplice da non aver nemmeno bisogno di essere menzionato, ma a volte è abbastanza facile dimenticarlo: usa l' langattributo nel tuo HTML, questo attributo è generalmente usato nell'elemento radice della pagina ( htmltag) ma può anche essere usato quando una parte specifica della pagina è in una lingua diversa rispetto al resto del sito web. Questo attributo è molto importante per il browser per identificare la lingua utilizzata dalla pagina e suggerire traduzioni automatiche in base alla lingua dell'utente.

Impara le basi

Anche se non fa necessariamente parte del tuo lavoro quotidiano, è consigliabile conoscere cos'è l'accessibilità e come funziona in un contesto applicativo Web/Mobile. Spesso gli addetti al backend scrivono alcune righe di HTML e, quando ciò accade, le pagine generate potrebbero non essere strutturate nel modo più accessibile possibile.

Parla con persone di altre zone

Se il tuo team ha già una certa maturità in termini di 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 è solo questione di aggiungere un campo di descrizione dell'immagine da utilizzare su un'immagine alt o informazioni extra nei dettagli del tuo prodotto, e sì, questi dettagli potrebbero sembrare così piccoli da sembrare insignificanti, ma insieme ad altri miglioramenti finiscono per fare un grande differenza.

Limita il tempo per completare le azioni

Il tempo non deve 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.

Naturalmente, non possiamo ignorare il fatto che diverse limitazioni tecniche possono impedirci di fornirlo, ma è sempre bene prevenire questo tipo di problema che non farà che frustrare 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à, ad esempio in un'asta online.
• Attività in cui il tempo è essenziale: il tempo è un fattore essenziale e l'aumento del tempo limite renderebbe l'azione non valida, ad esempio in un'offerta disponibile per un tempo limitato in un negozio online.
• 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 rendere disponibile un modo per mostrare il significato di un'abbreviazione quando viene utilizzata su una pagina, per aiutare gli utenti che:

• avere difficoltà a interpretare il significato di un acronimo;
• dipende dagli screen reader;
• avere una memoria limitata;
• hanno difficoltà ad utilizzare il contesto in cui si trovano per comprendere il significato dell'acronimo.

Riautenticazione

Immagina il seguente scenario:

La mia band preferita di tutti i tempi sarà vicina a dove vivo e ho la rara possibilità di realizzare questo sogno di vederli diventare realtà. Sapendo che la competizione per ottenere i biglietti sarà grande, creo il mio account sul sito web e aspetto solo che i biglietti siano disponibili. Quando finalmente arriva questo momento, prendo il mio biglietto, digito il numero della carta di credito e tutto, ma... proprio quando clicco per terminare l'acquisto vengo disconnesso. In questo momento mi dispero: provo velocemente ad accedere di nuovo, e quando provo a procedere con l'acquisto vedo il triste messaggio… biglietti esauriti.

Non va bene, vero? Sì.

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

In effetti, questo non è un problema solo per l'accessibilità, ma se questa situazione crea frustrazione per gli utenti che non hanno alcuna limitazione, vi immaginate come lo sia per coloro che possono usare solo il mouse o dipendono da uno screen reader per navigare?

Ecco perché dobbiamo stare attenti quando implementiamo flussi che richiedono l'autenticazione, l'utente dovrebbe essere in grado di continuare l'attività senza perdere alcun dato nel caso in cui la sessione scada. In questo scenario di ticket ci sono alcune soluzioni che alleggeriscono il problema:

• Estendere periodicamente la durata della sessione mentre l'utente è attivo sul sito;
• Prenota il ticket e salva i dati del modulo mentre l'utente digita, nel caso in cui non possa terminare la compilazione per qualche motivo e voglia continuare in seguito;
• Fornire un'opzione per eseguire nuovamente l'autenticazione senza uscire dalla pagina corrente e continuare il flusso dopo la riautenticazione.

Nei casi in cui è possibile effettuare ricerche testuali per trovare contenuti, è interessante avere un meccanismo che suggerisca contenuti con nomi simili, nel caso in cui il sistema sospetti che l'utente abbia digitato male una parola nella ricerca. In questo modo evitiamo la necessità per l'utente di effettuare una seconda ricerca, correggendo l'errore e solo successivamente trovando ciò che desidera.

Come per molte cose quando si tratta di accessibilità, il controllo ortografico 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.

Avvolgendo

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

Ebbene, poiché l'area tecnologica sta diventando sempre più popolare e inclusiva, e sta aumentando anche l'ingresso di nuove persone (comprese le persone con disabilità), una conoscenza di base della materia può aiutare non solo a sostenere le persone, ma tutti in una squadra, in questo modo 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 notare che l'accessibilità non è responsabilità solo delle persone che lavorano con frontend, backend, design e QA, ma chiunque attraversi qualsiasi fase della concezione del software può contribuire.

Riferimenti

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