Esaminare le considerazioni sulla progettazione

Completato

Esaminare l'accessibilità durante tutto il ciclo di sviluppo del prodotto è fondamentale perché garantisce che l'inclusione sia integrata in ogni fase della progettazione e del sviluppo. Affrontando fin dall'inizio il problema dell'accessibilità, è possibile identificare e risolvere le potenziali barriere in anticipo, creando un'esperienza più semplice e intuitiva per tutti gli utenti, inclusi quelli con disabilità. Questo approccio proattivo non solo migliora l'usabilità, ma aiuta anche a soddisfare gli standard legali ed etici, offrendo infine a un panorama digitale più equa. Al termine di questa unità, si è dotati di conoscenze per esplorare il processo di sviluppo del prodotto in modo efficace, assicurando che i progetti non siano solo innovativi ma anche accessibili.

Albero dell'accessibilità

Un albero di accessibilità è una struttura speciale creata dai browser web per facilitare le tecnologie assistive, come i lettori di schermo, per comprendere e interagire con la maggior parte degli elementi HTML. I browser converte html in un albero DOM (Document Object Model), che contiene la struttura e i dettagli di tutti gli elementi, gli attributi e il testo. I browser usano l'albero DOM per generare un albero di accessibilità, che viene quindi usato dalle API di accessibilità specifiche della piattaforma per creare una versione della pagina Web che le tecnologie assistive, come i lettori di schermo, possono interpretare. Tuttavia, l'albero di accessibilità include solo elementi rilevanti per scopi di accessibilità, ad esempio pulsanti, collegamenti e campi modulo. Si consideri una mappa che mostra le diverse parti di una pagina Web connesse e le operazioni eseguite. Questa mappa include informazioni su pulsanti, collegamenti, immagini e altri elementi, semplificando la navigazione e l'uso del sito Web da parte delle persone con disabilità.

Esistono tre componenti cruciali di un albero di accessibilità:

• Nome: etichetta o identificatore per un componente dell'interfaccia utente. Ad esempio, il nome di un pulsante potrebbe essere "Invia" o "Cerca". Indica agli utenti che cos'è l'elemento o cosa fa.
• Ruolo: definisce l'elemento, ad esempio testo, immagine, pulsante e così via. Ad esempio, un <button> tag ha il ruolo di un pulsante. Il ruolo consente agli utenti di comprendere come possono interagire con l'elemento .
• Stato/Valore: rappresenta lo stato o il valore corrente di un elemento, ad esempio il valore di un dispositivo di scorrimento (50%) o lo stato di una casella di controllo (selezionata o deselezionata).

Tabella con tre colonne con etichetta "Name", "Role" e "Value". Le voci in "Nome" includono Piè di pagina, casella di testo Piè di pagina, Numero diapositiva, Non visualizzare nella diapositiva del titolo e Applica a tutti. In "Ruolo", vengono identificati come casella di controllo, campo di testo o pulsante. La colonna "Valore" mostra stati come Attivato, Riservato, Disattivato e Applica a tutti. Uno screenshot inset di piccole dimensioni in basso a destra mostra un'interfaccia utente con caselle di controllo e opzioni di input di testo corrispondenti alle voci della tabella.

Il nome, il ruolo e lo stato/valore di ogni elemento devono essere determinati a livello di codice in modo che le tecnologie di assistive technology come le utilità per la lettura dello schermo possano trasmettere accuratamente queste informazioni agli utenti.

Confronto tra un albero DOM e un albero di accessibilità. L'albero DOM mostra il codice HTML con una barra degli strumenti etichettata "Barra multifunzione", che contiene un pannello di schede denominato "Home" con i pulsanti "Grassetto", "Corsivo" e "Sottolineato". L'albero di accessibilità elenca una finestra denominata "PowerPoint", con un riquadro denominato "Barra multifunzione". All'interno del riquadro è presente un gruppo denominato "Home", che contiene i pulsanti "Grassetto", "Corsivo" e "Sottolineato".

Risorse

• Che cos'è l'albero di accessibilità di un sito Web?
• Albero dell'accessibilità
• Informazioni sul criterio di esito positivo 4.1.2: Nome, Ruolo, Valore

Interazione tra siti Web/app e utilità per la lettura dello schermo

Per sviluppare siti Web e app che supportano le utilità per la lettura dello schermo, è fondamentale comprendere come interagiscono tra loro.

App e utilità per la lettura dello schermo

L'app chiama l'API di accessibilità del sistema operativo per fornire un albero di accessibilità. L'utilità per la lettura dello schermo usa quindi questa API per accedere all'albero.

Diagramma che mostra il flusso tra un'utilità per la lettura dello schermo e un'app tramite le API di accessibilità. Nella parte superiore è presente una casella con etichetta "App", connessa da una riga a "API di accessibilità per provider". Di seguito è riportato "sistema operativo", seguito da "API di accessibilità per client". Nella parte inferiore è presente una casella con etichetta "Utilità per la lettura dello schermo", connessa dalle righe agli elementi precedenti.

Le app possono generare eventi relativi alle modifiche, consentendo al lettore dello schermo di rispondere ed eseguire azioni come selezionare una casella di controllo.

Diagramma che mostra l'interazione tra un'utilità per la lettura dello schermo, il sistema operativo e un'app usando le API di accessibilità. Nella parte superiore è presente una casella con etichetta "App", connessa da frecce con etichetta "Eventi" e "Patterns" alla casella "SISTEMA OPERATIVO" sotto. La casella "Sistema operativo" è connessa da frecce simili alla casella "Utilità per la lettura dello schermo" nella parte inferiore. Le frecce mostrano un flusso bidirezionale di eventi e modelli tra l'app, il sistema operativo e l'utilità per la lettura dello schermo.

In questo modello, l'app e l'utilità per la lettura dello schermo comunicano solo tramite l'API di accessibilità del sistema operativo, mai direttamente. Altre tecnologie di assistive technology, ad esempio lente di ingrandimento dello schermo e controllo vocale, usano anche questa API.

App Web e utilità per la lettura dello schermo

Per le app Web, il browser comunica con l'API di accessibilità convertendo l'albero DOM fornito dall'app Web in un albero di accessibilità per il sistema operativo. Ogni elemento sottoposto a rendering nella pagina ha un elemento corrispondente nell'albero di accessibilità, garantendo la standardizzazione tra sistemi operativi e browser nonostante le differenze nelle API di accessibilità sottostanti. Le app Web non possono generare eventi direttamente e avere capacità limitata di implementare modelli sugli elementi.

Diagramma che mostra l'interazione tra un'app, un browser, un sistema operativo e un'utilità per la lettura dello schermo tramite le API. Nella parte superiore è presente una casella con etichetta "App", con una freccia verso il basso con etichetta "DOM" che punta a una casella "Browser". Sotto il browser si trova la casella "Sistema operativo", connessa da frecce con etichetta "Eventi" e "Modelli" sia al browser che al lettore di schermo nella parte inferiore. Le frecce indicano un flusso bidirezionale di eventi e modelli tra il browser, il sistema operativo e l'utilità per la lettura dello schermo usando le API di accessibilità.

Annotazioni di accessibilità per il supporto del screen reader

Molti problemi di accessibilità possono essere previsti ed evitati durante la fase di progettazione. Usare suggerimenti pratici e un elenco curato di strumenti, plug-in e modelli per risparmiare tempo per documentare l'accessibilità nei mockup figma. Le annotazioni per il supporto ai screen reader aiutano i progettisti a comunicare come gli utenti possono navigare e interagire con i loro design usando un screen reader. Ecco alcune annotazioni comuni che usano: plug-in A11y Focus Order e Fluent Accessibility Design ToolkitA11y Focus Order Plugin A11y Focus Order e Fluent Accessibility Design Toolkit:

Nome, ruolo e stato

È fondamentale che tutti i componenti dell'interfaccia utente, inclusi gli elementi, i collegamenti e i componenti generati dagli script, includano nomi e ruoli che possono essere determinati a livello di codice. Ciò garantisce che le tecnologie assistive possano interpretare e interagire con questi elementi in modo efficace. Inoltre, è essenziale che gli stati, le proprietà e i valori che possono essere impostati dagli utenti vengono risolti anche a livello di codice. Ciò consente agli utenti di avere un'esperienza senza problemi durante l'interazione con l'interfaccia. Inoltre, è necessario assicurarsi che le modifiche apportate a questi elementi vengano notificate agli agenti utente, incluse le tecnologie di assistive technology, in modo che gli utenti siano sempre consapevoli dello stato corrente e possano interagire con l'interfaccia di conseguenza.

Per i componenti della libreria, "Nome" sarà uguale a quello indicato nel design e lo stesso verrà annunciato dall'utilità per la lettura dello schermo. Il ruolo verrà popolato automaticamente e l'utente dovrà quindi selezionare o definire le proprietà, scegliendo le caselle di controllo fornite o specificandole nel campo di modifica. Se è necessario includere dei tasti di scelta rapida personalizzati che possiamo aggiungere, e tutte queste altre proprietà vengono mostrate nella sezione "Note per sviluppatori". Per i componenti personalizzati è necessario eseguire tutte le operazioni, selezionando il tipo di controllo corretto, esaminare tutti i flussi, impostare le proprietà pertinenti, i collegamenti. Quindi, prima di usare componenti personalizzati, chiedere: "È necessario? "È disponibile un componente che serve lo scopo?" In caso contrario, usarlo e assicurarsi di coprire tutti i flussi e i casi limite.

Specifiche per le annotazioni dell'utilità per la lettura dello schermo: tabella della finestra di dialogo delle specifiche del widget con quattro sezioni etichettate. La tabella include etichette per lettori di schermo, componenti e note per sviluppatori. Etichetta 1 indica la "Categoria" con un componente a discesa. L'etichetta 2 evidenzia "Mostra selettore widget" con un componente casella di controllo. L'etichetta 3 indica il "Selettore widget" con un collegamento a un widget personalizzato. L'etichetta 4 indica "Salva" con un pulsante contrassegnato come facoltativo. Le note per gli sviluppatori indicano le proprietà e i tasti di scelta rapida.

Quando sono presenti più componenti con lo stesso nome visivo, è necessario eseguire l'override del nome dell'oggetto visivo. Perché dovremmo farlo? Abbiamo una navigazione diversa per pulsanti, collegamenti. Quando un utente di un lettore di schermo utilizza la rispettiva navigazione, annuncia solo il nome e nessun altro contesto visibile nell'interfaccia utente. Ad esempio, in questa immagine viene annunciato Crea, Crea e Sfoglia quando l'utente naviga con il pulsante di navigazione. È possibile fornire più contesto usando l'override di Aria o un altro modo che includa il nome visibile del controllo.

L'esempio illustrato nell'immagine seguente si riferisce al caso in cui due componenti hanno lo stesso nome visivo di 'create' che non è corretto perché annuncia Create per entrambi e cerca il terzo pulsante quando l'utente si sposta con il pulsante di spostamento, creando confusione e non descrivendo lo scopo di ogni pulsante.

L'esempio illustrato nell'immagine seguente è la posizione in cui sono presenti due pulsanti "crea", ma è stato aggiunto testo aggiuntivo in un override Aria-Label che include il nome visibile del controllo, ad esempio "Crea un nuovo onboarding di assunzione", "Crea modello di collaborazione urgente" e "Sfoglia altro modello" rispettivamente che descrive lo scopo di ogni pulsante.

Gli stati sono critici solo se illustrano un flusso o delle condizioni specifiche in cui tale particolare stato è critico, ad esempio nei casi in cui in un flusso un elemento è disabilitato, contrassegnare questo come disabilitato è una buona pratica.

Esempio di accessibilità per Nome, Ruolo e stato dei pulsanti e dei campi di input. Elemento 1: Nome - Utente nome, Ruolo - Inserimento. Elemento 2: Nome - Password, Ruolo - Input. Elemento 3: Nome - Password dimenticata, Ruolo - Collegamento. Elemento n. 4: Nome – accesso, Ruolo – Pulsante, Stato – Disabilitato. Elemento 5: Nome - Ricordami, Ruolo - Casella di controllo, Stato - Non selezionato.

Tasti di scelta rapida

Evidenzia Aggiungi tutti i tasti di scelta rapida che non sono standard piuttosto una personalizzazione e possono essere usati per eseguire azioni all'interno della progettazione.

Esempio di annotazioni di accessibilità per i tasti di scelta rapida, con i tasti di scelta rapida "CTRL+MAIUSC+M"=Disattiva", CTRL+MAIUSC+E"=Condividi contenuto e "CTRL+MAIUSC+H"=Lascia riunione

Esempio di annotazioni di accessibilità per le interazioni e i tasti di scelta rapida da tastiera, con il pulsante di testo "Grassetto" = CTRL+B, pulsante "Corsivo" = CTRL+I e il pulsante "Sottolineato" = CTRL+U

Intestazioni

Usa le intestazioni per semplificare la navigazione nei tuoi progetti. Questi sono i titoli e i sottotitoli di una pagina Web che possono essere spostati come una struttura ad albero usando la gerarchia.

• Nella pagina può essere presente un solo H1.
• Può esserci un numero qualsiasi di H2s, H3s e H4s.
• I livelli di intestazione devono seguire un ordine. Non è possibile passare da H2 a H4 senza un H3 successivo.

Interfaccia dell'applicazione chat di Microsoft Teams con due annotazioni etichettate. L'interfaccia mostra più conversazioni con timestamp e una finestra di chat a destra visualizza i messaggi. Etichetta 1 indica il pannello sinistro (H1) che visualizza un elenco dei contatti e della cronologia chat. Etichetta 2 evidenzia la sezione in alto a destra, che contiene le opzioni di ricerca e menu (H2).

Riga di cinque icone circolari, ognuna etichettata con un livello di titolo diverso: h1, h2, h3, h4 e h5. Queste icone rappresentano diverse annotazioni di intestazione usate per la navigazione con lettori di schermo.

Punti di riferimento

I punti di riferimento possono essere utili aggiunte quando si definiscono intere esperienze sullo schermo sul Web. Si tratta di contenitori o aree che possono essere usate per esplorare rapidamente le app, i siti in aree diverse, ad esempio main, search, header o piè di pagina e così via. Abbiamo vari punti di riferimento, ad esempio Banner, Navigazione, Principale, Ricerca e altri.

• Se hai un solo punto di riferimento, fai in modo che il punto di riferimento principale sia in grado di fornire un collegamento skip per passare direttamente al contenuto tramite tastiera.
• La ricerca è un punto di riferimento critico.
• Anche il punto di riferimento per la navigazione è importante.
• La maggior parte delle volte, le intestazioni saranno sufficienti.
• Per pagine lunghe/siti Web che sono suddivisi in aree e rettangoli, definire punti di riferimento per renderlo più diversificato e accessibile.
• Meno punti di riferimento sono migliori.
• Può essere presente un solo punto di riferimento banner, che è in genere l'intestazione della pagina.

Interfaccia dell'applicazione chat di Microsoft Teams con quattro annotazioni etichettate. L'interfaccia include più messaggi di chat con timestamp. L'annotazione 1 indica il pannello a destra, intitolato Main, che mostra una conversazione. L'annotazione 2 evidenzia il pannello di spostamento. Annotazione 3 indica il banner. Annotazione 4 indica la barra di ricerca in alto.

Diagramma che mostra diverse annotazioni dei landmarks del screen reader con etichette e valori. Include le caselle con etichetta "Principale", "Ricerca", "Navigazione", "Banner", "Area geografica", "Complementare", "Informazioni sul contenuto" e "Modulo". Ogni casella di riferimento ha "Etichetta: Valore" in modo che i progettisti possano immettere la rispettiva etichetta e valore. Le caselle sono delineate in stili diversi, ad esempio con linee a tinta unita o tratteggiate.

Avvisi, messaggio di errore, area dinamica

Avvisi/Messaggio di errore/Area dinamica che notifica all'utente il completamento, le modifiche all'interfaccia utente, e segnala eventuali errori. Vengono usati per consentire agli utenti dell'utilità per la lettura dello schermo di sapere quando un processo a esecuzione prolungata ha avuto esito positivo, un'attività non è riuscita o si è verificato un evento senza input dell'utente. Assicurarsi che i messaggi visivi vengano letti in modo chiaro e paritario senza distrarre l'attenzione.

Notifica desktop da Microsoft Teams che mostra un messaggio di errore. Il messaggio legge: "Non è stato possibile inviare messaggi in chat con Kat, Kayo, Bambk e quattro persone aggiuntive". A sinistra, un'annotazione di accessibilità per il messaggio di errore.

Messaggi di errore del modulo che richiedono agli utenti di compilare il campo delle informazioni prima di continuare. Le annotazioni di accessibilità segnalano un "Messaggio di Errore di Stato Vuoto" e invitano a "Inserisci il tuo nome" per correggere l'errore.

Una barra di ricerca nella pagina Donazione di Teach Access visualizza il nome "Microsoft" immesso come query. Viene visualizzata una notifica popup che informa gli utenti che Microsoft offre un programma regalo corrispondente.

Gestione del focus

Assicurarsi che il focus sia gestito correttamente, soprattutto quando vengono aperte o chiuse finestre di dialogo modali o menu, quindi il focus torna al componente da dove è stato attivato. Ciò consente agli utenti di navigare attraverso il contenuto in modo efficiente, assicurando che la focalizzazione sia prevedibile e comprensibile.

Testo alternativo

Fornire testo alternativo per immagini, icone e altri contenuti non di testo. Ciò consente alle utilità per la lettura dello schermo di descrivere questi elementi agli utenti che non possono visualizzarli. Assicurarsi di seguire le procedure consigliate per la scrittura di testo alternativo.

Risorse

• Guida alla convalida dei moduli accessibili
• Scrivere testo alternativo utile per descrivere le immagini