IL NOSTRO PROTOCOLLO PER APP ACCESSIBILI
Share:
L’accessibilità dei device tecnologici che ogni giorno ci accompagnano e ci connettono alla famiglia, al lavoro, al mondo, è un elemento troppo spesso sottovalutato.
Forse si è pensato per molto tempo che richiedesse troppa ricerca per un mercato tutto sommato piccolo e forse poco affluente.
22HBG pensa invece che la tecnologia abbia uno scopo: fare stare meglio tutti gli esseri umani.
Pensa inoltre che sia un mezzo di inclusione sociale e che tutto ciò faccia bene al business.
Sono le stesse radici di 22HBG a suggerirlo:
un’azienda che nasce dalla radio, mezzo per sognare senza immagini, non poteva non essere sensibile al tema.
CHECKLIST IN 5 PUNTI
- Il Voiceover riesce ad interagire con l’app.
Non sempre infatti un’app riesce ad interagire con lo screen reader per iOS e dunque deve essere ridisegnata avvalendosi del framework dedicato. - Il Voiceover interagisce parzialmente con l’app.
Un caso meno drastico rispetto al precedente può verificarsi quando alcuni oggetti presenti nell’app vengono visti e altri no.
Uno dei casi più classici è quando ci sono parti animate, parti legate a mappe etc.
In questo caso si deve agire sulle parti non accessibili capendo come lo sviluppatore abbia agito sul codice e come abbia costruito l’applicazione. - Etichettature di pulsanti non corrette.
Questo è il caso meno preocuppante perchè si tratta di label che non sono state correttamente etichettate e che Voiceover vede semplicemente come pulsanti.
In questo caso lo sviluppatore andrà a correggere il tiro etichettando in maniera corretta. - Le webapp.
E’ un tipico caso che si verifica oggigiorno, ovvero un’app che va a pescare da contenuti web di un portale o un sito.
Qui dipende da come sono gestite le varie classi nell’app e dal fatto che il sito sia stato pensato e realizzato in maniera accessibile. - Debugging.
L’analisi di eventuali crash dell’applicazione che possono verificarsi in presenza di Voiceover necessitano un’azione di debugging alla ricerca della criticità.
