Recommended
Recommended
More Related Content
Similar to Building for Everyone - P2 - Semantica e Navigazione
Similar to Building for Everyone - P2 - Semantica e Navigazione (20)
Building for Everyone - P2 - Semantica e Navigazione
- 1. Come implementare l’accessibilità nel web Semantica & Navigazione Loredana Frontino e Simona Perrucci GDG Lead, GDG Torino
- 2. Ma prima un piccolo recap!
- 3. ● Contenuti disponibili per tutti Cosa rende un sito accessibili? E’ abbreviata con A11y ● Funzionalità utilizzabili da tutti
- 4. Difficoltà Visive ● Screen reader ● Schermi Braille ● Navigazione con la Tastiera ● Strumenti di Zoom ● Temi ad alto contrasto Difficoltà Uditive Difficoltà Motorie ● Navigazione con Tastiera ● Tracciamento oculare ● Interruttori ● Attivazione Vocale ● Segnali visivi Difficoltà Cognitive ● Strumenti di Zoom
- 5. Web Content Accessibily Guideline 4 Principi: ● Perceivable: contenuto percepible da tutti gli utenti ● Operable: tutti gli utenti devono poter interagire con il contenuto ● Understandable: contenuto e interfaccia devono essere consistenti ● Robust: contenuto deve essere utilizzabili da diversi user agent Linee guida: WCAG 2.0
- 6. 3 aree di miglioramento: ● Focus con la tastiera ● Semantica, per un interfaccia robusta, adattabile a diversi tool ● Styling, per una visual UI flessibile e usabile Come migliorare l’accessibilità
- 7. Focus
- 8. Muoversi nel Tab Order Tab Successivo Shift Tab + Precedente Enter Esc Seleziona opzione ↓ → Opzione Successiva ↑ ← Opzione Precedente Cos’è il focus
- 9. <body> <nav> <button/> <button/> </nav> <main> …. <input/> <button/> </main> </body> Come funziona il tab order Struttura del DOM <div tabindex=”-1”></div> ● tabindex=”-1” ○ non è in tab order; ○ può essere portato in focus programmaticamente; ● tabindex=”0” ○ è all’interno del tab order naturale ○ può essere portato in focus; ● tabindex=”1+” ○ è in testa al tab order; ○ può essere portato in focus; ○ usare con prudenza
- 11. Vediamo in pratica il concetto di affordance
- 12. Vediamo in pratica il concetto di affordance
- 13. Soluzione!
- 15. WebAIM WCAG Checklist 4.1.2 Name, Role, Value Il markup viene utilizzato in modo da facilitare l'accessibilità. WCAG 2.2 Per tutti i componenti dell'interfaccia utente, il nome e il ruolo possono essere determinati a livello di codice; gli stati, le proprietà e i valori che possono essere impostati dall'utente possono essere impostati a livello di codice;
- 16. Link a sito che utilizza screen reader Interfaccia oscurata e screen reader attivo
- 17. Cosa “legge” lo screen reader e cosa restituisce all’utente
- 18. Cosa “legge” lo screen reader e cosa restituisce all’utente NAME: One way, ROLE: radio, STATUS: selected VALUE:No preference, NAME: Preferred seat type, STATUS: collapsed, ROLE: combo box
- 19. A11y Tree vs DOM Tree
- 20. A11y Tree vs DOM Tree
- 21. A11y Tree vs DOM Tree
- 24. Guideline 1.1 Fornire alternative testuali per qualsiasi contenuto non testuale ● Name ● Text alternative ● Title ● Label Scrivere HTML semantico
- 25. Esistono due tipi di LABEL ● label visibile ● text alternative Scrivere HTML semantico
- 26. WebAIM WCAG Checklist 1.1.1 Non-text Content ● Tutte le immagini, i pulsanti immagine e i punti attivi della mappa immagine dispongono di testo alternativo appropriato ed equivalente. ● Alle immagini che non trasmettono contenuti, che sono decorative o che contengono contenuti già trasmessi nel testo viene fornito un testo alternativo vuoto (alt="") o implementate come sfondi CSS. Tutte le immagini linkate hanno un testo alternativo descrittivo. ● Alternative equivalenti alle immagini complesse sono fornite nel contesto o su una pagina collegata separata. ● I pulsanti del form hanno un valore descrittivo. ● Gli input del form hanno etichette di testo associate.
- 30. Navigazione
- 33. Utilizzo dello screen reader per la navigazione
- 34. Utilizzo dello screen reader per la navigazione cmd + F5 Attivazione screen reader IOS TAB / SHIFT + TAB Muoversi tra gli elementi cmd + L Attivare la searchbar CTRL + Option + U Ricerca dalla barra di navigazione CTRL + Option + ← ↑ ↓ → Esplorare i contenuti CTRL + Option + CMD (+SHIFT) + H Navigare tra gli headers Windows NVDA Linux ORCA Altri comandi Come usarlo
- 35. La gerarchia dei text Header 2.4.2 Page Titled Le pagine web devono avere titoli descrittivi e informativi 2.4.10 Section Headings Gli header aiutano a gestire l’organizzazione e le gerarchie all’interno delle pagine 1.3.1 Info and Relationships Gestire correttamente il markup semantico e le corrette modalità d’uso dei vari elementi html di una pagina
- 36. for (var i = 0, headings = $$('h1,h2,h3,h4,h5,h6'); i < headings.length; i++) { console.log(headings[i].textContent.trim() + " " + headings[i].tagName, headings[i]); } Quanti H ci sono all’interno della mia pagina?
- 37. Scorciatoie 2.4.1 Bypass Blocks Fornire la possibilità di saltare alcune informazioni all’interno della pagina
- 40. Scorciatoie Accesskey Attributo HTML che dovrebbe aiutare nella gestione delle scorciatoie da tastiera, generando un’associazione tra tasto e tag HTML associato Skip Navigation Links Creazione di collegamenti che consentono di saltare la navigazione. Contenuti fuori schermo Creazione di collegamenti che consentono di saltare la navigazione.
- 41. Scorciatoie Accesskey Attributo HTML che dovrebbe aiutare nella gestione delle scorciatoie da tastiera, generando un’associazione tra tasto e tag HTML associato Generazione di conflitti tra scorciatoia e funzionalità dello screen reader
- 42. Scorciatoie Skip Navigation Links Creazione di collegamenti che consentono di saltare la navigazione. <body> <a href="#maincontent"> Vai al contenuto principale </a> ... <main id="maincontent"> <h1>Intestazione</h1> <p>Questo è il primo paragrafo</p > </main> . . . </body> LINK VISIBILI
- 43. Scorciatoie Skip Navigation Links Creazione di collegamenti che consentono di saltare la navigazione. LINK TEMPORANEAMENTE NASCOSTI Proprietà da rispettare: ● essere nascosto come impostazione predefinita ● essere accessibile alla navigazione tramite tastiera ● diventare ben visibile quando è messo a fuoco ● impostare correttamente lo stato attivo sull'area del contenuto principale quando attivato
- 45. Scorciatoie Skip Navigation Links Creazione di collegamenti che consentono di saltare la navigazione. LINK TEMPORANEAMENTE NASCOSTI Proprietà da evitare: ● Hidden ● Display: none; ● rendere il collegamento dello stesso colore dello sfondo o completamente trasparente ● ridimensionarlo a 0 pixel o posizionarlo su un'immagine trasparente
- 46. Scorciatoie Skip Navigation Links Creazione di collegamenti che consentono di saltare la navigazione. LINK TEMPORANEAMENTE NASCOSTI Proprietà da evitare: ● Hidden ● Display: none; ● rendere il collegamento dello stesso colore dello sfondo o completamente trasparente ● ridimensionarlo a 0 pixel o posizionarlo su un'immagine trasparente
- 47. Scorciatoie Contenuti fuori schermo Creazione di collegamenti che consentono di saltare la navigazione.
- 48. Nei modali il focus può navigare solo tra gli elementi dentro alla modale Input che dopo la selezione non permettono di spostarsi nella pagina Trappole per tastiera
- 49. Parliamo dei link anti-patterns Link poco accessibili Attributi diversi da <a> o <button> che gestiscono link
- 50. Parliamo dei link anti-patterns Link poco accessibili Attributi diversi da a o button che gestiscono link
- 51. Parliamo dei link anti-patterns Link poco accessibili Link <a> utilizzati come bottoni
- 52. Parliamo dei link anti-patterns Link poco accessibili Link <a> utilizzati come bottoni
- 53. Parliamo dei link anti-patterns Link poco accessibili Link associati ad immagini senza riferimenti
- 54. Parliamo dei link anti-patterns Link poco accessibili Link associati ad immagini senza intestazioni
- 55. Struttura di una pagina
- 56. Come implementare l’accessibilità nel web Aria & Style GDG Lead, GDG Torino Nella prossima puntata!
Editor's Notes
- La scorsa volta abbiamo parlato di cosa si intende per ACCESSIBILITA’ E’ la capacità di un sito web o un’app di poter essere utilizzata anche da chi ha una disabilità, anche temporanea, e necessita di tecnologie assistive. Quindi un sito web è accessibile quando: i contenuti sono disponibili per tutti le funzionalità sono utilizzabili da tutti
- Cosa significa che un sito è accessibile? < chiedo all'audience> I contenuti del sito devono essere disponibili per tutti Le funzionalità del sito devono poter essere eseguite da tutti Accessibilità è spesso scritta in forma breve come A11y un po come I18n è l'internazionalizzazione e L10N è localizzazione
- Ovviamente non si può lasciare al caso la gestione dell'accessibilità. Esistono un set di linee guide le WCAG (Web Content Accessiblity Guidiline) ora alla versione 2.0, scritte da esperti del settore, che a volte sono addirittura inserite tra i requisiti per i siti accessibili- WCAG è basata su 4 principi , in inglese POUR: Il contenuto del sito deve essere percepibile dagli utenti, il che ci aiuta a ricordarci che dobbiamo includere anche chi non può visualizzarlo, ma usa gli screen reader Il contenuto deve essere operabile, l'utente deve poter interagire con gli elementi della UI. Se una funzione si basa sull'hover non potrà essere usata da chi usa la tastiera o il touch Il contenuto e l'interfaccia devono essere comprensibili ed essere sufficientemente consistenti da non causare confusione Il contenuto deve essere robusto e utilizzabile da diversi User Agent La WCAG è stata anche sintetizzata in una check list. Guideline e checklist non devono però essere semplicemente una cosa poter marcare per indicare che hai inserito determinate funzionalità, ma devono essere parte del processo di progettazione del sito
- Il focus è il controllo sullo schermo che riceve gli input da tastiera e dalla clipboard. Con controllo intendiamo un qualunque elemento di interazione. Tipicamente il click su un input è quello che porta su di esso il focus. Cliccando con il tasto "tab" della tastiera, spostiamo il focus al prossimo controllo. Per chi usa la tastiera per navigare e interagire con lo schermo il focus è l'elemento più importante. Il WCAG ci dice che un contenuto web deve essere navigabile da tastiera, a meno che non sia fondamentale usare un altro input (come in casi di disegno a mano libera) Il focus è l'elemento di accessibilità più semplice dalla quale partire per rendere migliore il nostro sito. Migliorerà l'esperienza sia di chi ha problemi motori, sia di chi è più produttivo nel lavorare con la tastiera.
- Il comportamento di base del tab order per gli elementi con focus integrato segue l'ordine dei tag nel html. Elementi flottanti seguono comunque questo ordine, pertanto bisogna stare attenti ad usare il css, potrebbe portare a comportamenti per gli utilizzatori di tastiera che non sono consistenti. La checklist WCAG prevede che gli elementi siano in ordine logico e intuitivo per lettura e navigazione. E' buona pratica ogni tanto provare a muoversi con I tab per vedere se l'ordine rimane coerente. Ma a volte possono esserci elementi che hanno necessità di essere gestiti con il tab ma non hanno questo comportamento nativamente. Viene quindi in nostro soccorso il tabindex. Tabindex può essere applicato a qualunque elemento html, accoppiato ad un numero. Se tab index vale "-1" l'elemento ( e il suo contenuto ) non è in tab order, ma può essere portato in focus programmaticamente da javascript, utile per esempio con i modali < document.querySelector('#modal').focus() > Se tab index vale "0", l'elemento è inserito nel tab order naturale, e può comunque essere portato in focus, questo è molto comodo in caso di elementi customizzati creati usando dei div per esempio. L'elemento ora è in grado di ricevere gli input da tastiera Se tab index è maggiore di 0, questo salterà in testa al tab order, qualunque posto esso sia. Va maneggiato con cura poiché è un anti-pattern, e può causare problemi soprattutto per gli utilizatori di screen reader Se siete tentati di aggiungere Tab index ovunque per aiutare screen reader o utilizzatori da tastiera, tirate il freno, è consigliato metterlo solo sui controlli di interazione con la quale si vuole far interagire l'utente Ovviamente ad ogni regola generale seguono delle eccezioni. Quando ho la pagina divisa in sezioni che posso raggiungere con dei link rapidi Quando ho una single page application a schede il cui contenuto cambia al click della scheda In questi casi conviene identificare un header, applicare un tabindex di -1, che prima abbiamo visto permette di spostare il focus in un certo punto ma senza inserirlo nel tab order, e spostare manualmente il focus dopo l'interazione con il link rapido da parte dell'utente. Se non facessimo questo procedimento, l'utente al cambio di scheda si ritroverebbe a interagire con tutti gli elementi che ci sono prima di arrivare alla parte cambiata, se invece stesse usando uno screenreader non si accorgerebbe del cambio avvenuto al click.
- La semantica nel contesto dell’accessibilità fa riferimento all’uso semantico del codice HTML. Un tag semantico è un elemento HTML che descrive senza ambiguità il proprio significato (e di conseguenza il proprio contenuto) al browser che lo decodifica. Scrivere un codice HTML semantico rende semplice la traduzione della pagina web da parte della tecnologia assistiva, è ha un valore significativo anche per la SEO. Quindi abbiamo detto cos’è un tag semantico e abbiamo detto quanto sia importante per il corretto funzionamento dello screen reader, aggiungiamo un altro termine per avere tutti gli strumenti a portata di mano. Parliamo di affordance è l’invito all’uso! la capacità fisica di un oggetto di suggerire le azioni per usarlo nel modo giusto. Nel contesto delle interfacce utente, le affordance indicano le azioni che gli utenti possono compiere. Ad esempio in una pagina web un bottone invita l’utente a compiere un’azione, proprio come farebbe un pulsante nella vita reale… gli oggetti disegnati nelle interfacce utente sono ispirati agli oggetti reali così che sia facile per l’utente capire come funzionano. Una buona progettazione dell'interfaccia rende le affordance facilmente comprensibili, semplificando l'uso senza richiedere un lungo periodo di apprendimento.
- Questa è una schermata di prenotazione volo online, è composta da diverse parti che guidano l’utente verso il completamento del task. la scelta se la tratta è singola, se è andata e ritorno o se prevede delle soste in diverse città l’indicazione del nome del viaggiatore l’indirizzo Partenza e Arrivo, data di partenza e data di arrivo il tipo di posto a sedere, finestrino, corridoio ecc.. l’iscrizione alla newsletter per ricevere offerte future e la ricerca
- L’obiettivo di questo esercizio è quello di combinare gli elementi UI con la loro affordance.
- i radio buttons indicano che posso scegliere un’opzione tra quelle elencate qui si capisce che posso inserire una riga di testo Il campo data significa: posso inserire una data in formato US la checkbox è una opzione Sì o No, acceso o spento il bottone indica che al click verrà eseguita un’azione
- Quindi, uniamo i pezzi per capire come la semantica e le tecnologie assistive vadano a braccetto: Chi non può vedere lo schermo è tagliato fuori dalle info visive dell'interfaccia. Chi usa un browser vocale deve sperare che il software vocale riesca a interagire con la pagina web. Quindi è fondamentale assicurarsi che le info siano comunicate in un modo semantico, così le tecnologie assistive possono creare un’interfaccia alternativa su misura per chi le usa. Un elemento diventa comprensibile e traducibile dalla tecnologia assistiva in una interfaccia alternativa, grazie alla sua espressione semantica.
- Al capitolo 4 delle WebAIM WCAG 2 checklist, viene specificato che i markup NAME, ROLE e VALUE devono essere usati in modo da facilitare l'accessibilità Le WCAG vanno più nel dettaglio… Ma cosa si intende per NAME, ROLE e VALUE e come devono essere impostati a livello di codice? Per rispondere ci metteremo dalla parte di chi usa le tecnologie assistive e faremo riferimento prevalentemente allo screen reader, ma le tecniche applicate al codice in realtà sono valide per la maggior parte delle tecnologie assistive, come voice control e switch control che usano la stessa semantica espressa a livello di codice.
- Qui l’esercizio del form con l’interfaccia oscurata e lo screen reader attivato, facciamo una prova di navigazione tra gli elementi per testare come lo screen reader interpreta gli elementi presenti nel form.
- Se abbiamo fatto le cose per bene, ci aspettiamo di sentire per ogni elemento: ROLE NAME STATE VALUE (non necessariamente in quest’ordine!)
- Se abbiamo fatto le cose per bene, ci aspettiamo di sentire per ogni elemento: ROLE NAME STATE VALUE (non necessariamente in quest’ordine!)
- Proviamo a costruire una interfaccia utente solo per gli utenti di screen reader. Per farlo dobbiamo fornire allo screen reader le informazioni di cui ha bisogno l’utente per utilizzare l’interfaccia, senza ovviamente preoccuparci della UI perchè in questo caso l’aspetto dell’interfaccia non conta. Ma come possiamo esprimere il fatto di essere all’interno di un form…in pratica dobbiamo creare una specie di API del DOM, un’applicazione che descriva la struttura della pagina. Ma nella nostra API per lo screen reader non dobbiamo mettere tutte le info che abbiamo nel DOM perchè molte sono informazioni legate all’aspetto visuale e a noi non servono.
- Quindi se prendiamo per esempio questo DOM
- Succede che il browser prende l’alberatura del DOM, elimina le parti non necessarie e la trasforma in una alberatura che sia utilizzabile dalla tecnologia assistiva per creare un Accessibility Tree, che vediamo a destra! L’Accessibility Tree permette all’utente di passare dalle sezioni di alto livello agli elementi e permette di acquisire informazioni rispetto al tipo di elemento e a come si compila.
- In breve, abbiamo esaminato l'albero del DOM e come il browser lo converte in un albero di accessibilità (A11y Tree), ma la domanda è: come ci riesce? La risposta sta nel fatto che gran parte del DOM ha un significato semantico implicito. Questo accade grazie all'uso di elementi HTML standard, i quali sono automaticamente riconosciuti dai browser. In questo esempio, l’oggetto a sinistra ha l’aspetto e il funzionamento di un bottone. Ma se guardiamo il codice HTML che lo ha generato vediamo che non si tratta di un elemento Button. Con questo codice lo screen reader non lo riconoscerà come un bottone, perchè semanticamente non è un bottone e così può essere utilizzato solo usando il mouse. Come si corregge?
- Usando l’item <button> al posto del div. In questo modo lo screen reader sarà in grado di interpretare semanticamente l’elemento, che avrà un ROLE: button, un NAME: Give me wombats
- Come abbiamo detto, lo screen reader annuncia per ogni elemento: ROLE NAME STATE VALUE non necessariamente in quest’ordine. Usando gli elementi semantici siamo sicuri di avere sempre ROLE STATE e VALUE definiti, ma dobbiamo essere sicuri di aver definito anche un Nome per ogni elemento. Proprio come indicato dalla Web AIM WCAG Checklist al primo punto: Guideline 1.1 Fornire alternative testuali per qualsiasi contenuto non testuale L’attributo NAME può essere indicato in modo diverso a seconda del tipo di elemento: name text alternative title label tutti questi termini in HTML vengono usati in diversi contesti ma si riferiscono allo stesso concetto. NAME e LABEL sono intercambiabili, ma generalmente useremo LABEL
- Esistono due tipi di LABEL: label visibile (che permette a tutti di attribuire significato all’elemento) text alternative (che permette agli utenti di screen reader di interpretare l’elemento) L’immagine non ha bisogno di avere un’etichetta visibile, se la puoi vedere! Il text alternative non è una label visibile in pagina, ma è la label che viene riportata nel codice per poter essere letta dallo screen reader a vantaggio degli utenti che non possono vedere l’immagine.
- Le immagini, i pulsanti immagine e i punti attivi della mappa immagine, deve avere un text alternative equivalente. Se l’immagine non trasmette contenuti o è puramente decorativa o è già spiegata dal testo relativo, allora può avere l’alt vuoto o essere gestita come background image nel css I pulsanti hanno un valore descrittivo, come abbiamo visto prima <button>SEARCH</button> Gli input hanno label di testo associate
- Facciamo qualche esempio per spiegare come gestire il text alternative delle immagini. il logo ha un testo alternativo: si tratta di un’immagine che potrebbe essere un pittogramma e che quindi potrebbe essere difficile da descrivere e la descrizione potrebbe non essere utile, allora come alt possiamo usare il nome del sito che rappresenta, così verrà letto dallo screen reader; l’icona del carrello, è in realtà un bottone-immagine, un button che non ha un testo SHOPPING CART tra l'apertura e chiusura tag ma ha un’immagine, se non diamo mettiamo l’alt lo screen reader non lo leggerà; in questo caso l’icona del carrello è puramente decorativa ed è meglio non specificare un alt così lo screen reader salterà oltre; anche per questa immagine lasceremo l’alt vuoto perchè abbiamo già la caption sopra l’immagine e sarebbe una inutile ripetizione. non mettere l’alt ad una immagine o lasciarlo vuoto non è la stessa cosa, non metterlo è un errore di accessibilità.
- Come si associa una label ad una input? Se aggiungiamo semplicemente un testo sotto una input, visivamente potrebbe sembrare che sia la label della input… ma questo testo non risulterà collegato all’input e quindi il reader non sarà in grado di annunciare la input per nome, come vedete abbiamo uno spazio vuoto e il reader leggerà solo STATUS e ROLE. Inoltre cliccando sul testo, non succederà nulla alla input checkbox proprio perchè quello è un semplice testo e non è collegato all’input.
- Possiamo correggere in due modi: possiamo avvolgere con la label l’input, e così saranno automaticamente associati possiamo aggiungere sotto l’input la label avendo l’accortezza di specificare nell’attributo for=”” l’id dell’input
- Accedendo a una pagina web come ad esempio wikipedia, normalmente vediamo la sezione a sinistra con varie voci di link ad articoli del sito, in alto le voci menu, la barra di ricerca e nella sezione centrale l’articolo vetrina e altri riferimenti.
- Quando invece ci si affida a uno screen reader le prime informazioni che vengono comunicate dal lettore è un indice con tutti i link presenti nella pagina, gli input di testo, le tabelle e gli header.
- Lo screen reader applica una lettura logica dei contenuti, riprendendo i concetti di accessibility tree Evidenzia tutti i titoli e sottotitoli presenti, i tag link, i bottoni, i form e tutti gli elementi html che compongono la pagina, facendo riferimento all’organizzazione delle informazioni rispetto al DOM e non a come vengono visualizzati https://udacity.github.io/ud891/lesson3-semantics-built-in/03-experience-screen-reader/
- Ci sono diversi strumenti che consentono di attivare lo screen reader, per i vari sistemi operativi Windows mette a disposizione nvda, linux orca e ios ha un sistema incorporato del VoiceOver attivabile con cmd + f5. Qui una serie di azioni che è possibile fare da tastiera
- L’utilizzo dei tag Header crea una struttura gerarchica che identifica titolo principale, paragrafi e sottoparagrafi sino a giungere all’H6 (2.4.10) Le label text sono da associare esclusivamente a input di testo e se necessario associare l’aria Le tabelle vengono utilizzate per i dati tabulari e le celle dati sono associate alle relative intestazioni. Le didascalie delle tabelle dati, se presenti, sono associate alle tabelle dati.
- Con questa funzione è possibile identificare tutti gli elementi presenti nell’html di tipo H
- Navigando all’interno di un sito da tastiera ci si trova a passare tra pagine che possono avere alcuni contenuti che vengono ripetuti. Quindi può essere utile fornire la possibilità di saltare alcune informazioni all’interno della pagina. MA andiamo a capire meglio il perchè e poi come è possibile farlo…
- Secondo voi da questa pagina se accedo alla sezione ferrovie federali svizzere, avrò delle informazioni in comune che da vedente tenderei a saltare perchè conosco già?
- Queste informazioni già nella seconda pagina del sito, tendiamo ad ignorarle per concentrarci sul centro dello schermo (dove solitamente appare il contenuto principale) o la capacità di un utente con il mouse di selezionare un collegamento con un singolo clic del mouse Cosa che non sarebbe fattibile per un utente che utilizza ad esempio lo screen reader con tastiera, in quanto dovrebbe scorrere una lista infinita di elementi prima di arrivare alla voce desiderata. E non saltarne neppure uno La maggior parte dei browser Web fornisce scorciatoie da tastiera per spostare lo stato attivo dell'utente nella parte superiore della pagina, quindi se viene fornita una serie di collegamenti di navigazione nella parte inferiore di una pagina Web, fornire un collegamento "salta" potrebbe non essere necessario.
- Ecco alcune scoriciatoie che è possibile praticare e capiremo come si comportano in relazione a uno screen reader o altri strumenti.
- Nonostante le buone intenzioni e a causa delle implementazioni del browser varie e insufficienti, accesskey molto spesso non fornisce una soluzione praticabile per le scorciatoie da tastiera sul web. La maggior parte dei browser non supporta valori di chiave di accesso duplicati. Ad esempio, una pagina non può avere due scorciatoie con accesskey="1". Se presente, la maggior parte dei browser supporterà al massimo uno degli elementi. Poiché gli screen reader dipendono dai browser per gran parte delle loro funzionalità, l'implementazione dello screen reader di accesskey dipende in gran parte dal browser utilizzato. Alcuni lettori di schermo indicheranno il valore accesskey ogni volta che si incontra l'elemento. Ciò può introdurre rumore e ripetizioni non necessarie una volta che l'utente si è orientato verso quella chiave di accesso. Una delle maggiori preoccupazioni relative alle scorciatoie da tastiera è la possibilità che l'accesskey sovrascriva le scorciatoie da tastiera degli screen reader, che hanno molti più comandi da tastiera rispetto ai browser standard. Le scorciatoie da tastiera sono un componente critico della funzionalità di uno screen reader, quindi gli utenti dello screen reader possono trarre grandi vantaggi dall'uso corretto dell'accesskey. Al contrario, se una scorciatoia da tastiera dello screen reader viene disabilitata da una scorciatoia da tasto di accesso (o viceversa), all'utente dello screen reader potrebbe essere impedito di eseguire funzionalità importanti. In caso di conflitti, le scorciatoie dello screen reader generalmente hanno la precedenza, il che significa che le scorciatoie del tasto di accesso vengono effettivamente disabilitate, anche se verranno comunque identificate dall'utente. Il vantaggio in termini di accessibilità offerto dai tasti di scelta rapida viene perso, ma la funzionalità dello screen reader rimane intatta. Ciò, tuttavia, potrebbe creare confusione se l'utente desidera attivare una chiave di accesso.
- Skip navigation links possono essere link visibili, che rimandano grazie a un link associato a un id di un elemento della pagina, che permette di muoversi fino al contenuto corrispondente Oppure link salta temporaneamente nascosti
- Molti designer valutano anche l’impatto visivo che un link di questo tipo potrebbe avere sugli utenti che visualizzano la pagina. Evidenziando anche problematiche legate all’usabilità del sito da persone vedenti. Quindi vengono introdotti i link temporaneamente nascosti, ovvero che vengon resi visibili al focus, grazie all’assegnazione di proprietà all’elemento. Questo avviene nel sito di wikipedia Proprietà che deve avere: essere nascosto come impostazione predefinita essere accessibile alla navigazione tramite tastiera diventare ben visibile quando è messo a fuoco impostare correttamente lo stato attivo sull'area del contenuto principale quando attivato
- Wikipedia utilizza un espediente per rendere esplicite alcune informazioni che senza la possibilità di visualizzarle potrebbero non essere comprese
- Evitare di impostare proprietà che potrebbero rimuoverlo dal flusso come hidden o display none, oppure dare problemi di accessibilità di altro tipo come rendere il collegamento uguale allo sfondo o trasparente, o di dimensioni minime
- Evitare di impostare proprietà che potrebbero rimuoverlo dal flusso come hidden o display none, oppure dare problemi di accessibilità di altro tipo come rendere il collegamento uguale allo sfondo o trasparente, o di dimensioni minime Cosa si può fare invece per i contenuti fuori schermo come gli hamburger menu o i menù di opzioni? Questi se non gestiti correttamente portano l'utente che naviga con l'uso della tastiera a scorrere del contenuto non visibile. Tipicamente questi menu sono caricati nel dom, e impostati con larghezza 0 per poter essere animati durante l'apertura. E' sufficiente che quando sono intergabili abbiano display: none o visbility:hidden, per non essere considerato in termini di focus, e appena prima di animarli, li si può riportare visbili.
- Evitare di impostare proprietà che potrebbero rimuoverlo dal flusso come hidden o display none, oppure dare problemi di accessibilità di altro tipo come rendere il collegamento uguale allo sfondo o trasparente, o di dimensioni minime Cosa si può fare invece per i contenuti fuori schermo come gli hamburger menu o i menù di opzioni? Questi se non gestiti correttamente portano l'utente che naviga con l'uso della tastiera a scorrere del contenuto non visibile. Tipicamente questi menu sono caricati nel dom, e impostati con larghezza 0 per poter essere animati durante l'apertura. E' sufficiente che quando sono intergabili abbiano display: none o visbility:hidden, per non essere considerato in termini di focus, e appena prima di animarli, li si può riportare visbili.
- Andiamo ora a trattare un ultimo caso particolare. Può capitare che in alcuni elementi, soprattutto autocompletamenti, che si incappi in quella che è detta keyboard trap, la trappola per la tastiera, l'utente che usa la tastiera per navigare, non riesce più ad uscire dall'elemento in focus. Può capitare quando si tenta un auto completamento, si seleziona l'elemento completante, e poi ci ritrova con il focus nell'input ma nessuna possibilità di proseguire con tab o shift+tab. Questo comportamente è considerato da evitare dalla checklist WCAG. Ma la trappola per tastiera può essere usata anche a vantaggio nostro. Prendiamo il caso di una modale, se aperta, non abbiamo interesse che il focus possa uscire fuori da essa, ma che rimanga solo tra gli elementi interni alla modale. Possiamo quindi creare una trappola artificiale all'apertura della modale, che dato l'elenco di elementi che sono soggetti a focus della nostra modale, quando premo tab o shift tab non permette di uscire al di fuori del modale
- Ci sono dei casi in cui i link sono poco accessibili: Quando si usa un tag diverso da a che funge da elemento link o bottone, o un tag a che non ha la proprietà href associata Oppure un’immagine che funge da link, dovrebbe avere un attributo alt che permette di comprendere il testo del link. Inoltre per i link all’interno di un testo, per permettere di strutturare meglio la gerarchia delle informazioni è utile separare il link dal resto del testo, magari assegnandolo al titolo
- In questo modo il link viene visualizzato all’interno della lista dei links e può essere raggiunto attraverso la keyboard
- In questo modo il link viene visualizzato all’interno della lista dei links e può essere raggiunto attraverso la keyboard
- Ci sono dei casi in cui i link sono poco accessibili: Quando si usa un tag diverso da a che funge da elemento link o bottone, o un tag a che non ha la proprietà href associata Oppure un’immagine che funge da link, dovrebbe avere un attributo alt che permette di comprendere il testo del link. Inoltre per i link all’interno di un testo, per permettere di strutturare meglio la gerarchia delle informazioni è utile separare il link dal resto del testo, magari assegnandolo al titolo
- Ci sono dei casi in cui i link sono poco accessibili: Quando si usa un tag diverso da a che funge da elemento link o bottone, o un tag a che non ha la proprietà href associata Oppure un’immagine che funge da link, dovrebbe avere un attributo alt che permette di comprendere il testo del link. Inoltre per i link all’interno di un testo, per permettere di strutturare meglio la gerarchia delle informazioni è utile separare il link dal resto del testo, magari assegnandolo al titolo
- Ci sono dei casi in cui i link sono poco accessibili: Quando si usa un tag diverso da a che funge da elemento link o bottone, o un tag a che non ha la proprietà href associata Oppure un’immagine che funge da link, dovrebbe avere un attributo alt che permette di comprendere il testo del link. Inoltre per i link all’interno di un testo, per permettere di strutturare meglio la gerarchia delle informazioni è utile separare il link dal resto del testo, magari assegnandolo al titolo Come detto prima
- HTML5 ha introdotto la divisione delle aree della pagina in header, main, section, footer, navbar, article MAIN: contenuto principale di una pagina, che al suo interno contiene gli article e le section, tipicamente di main ce ne è uno all’interno della pagina; HEADER: Contiene i link alle varie sezioni o può rappresentare l’intestazione di una pagina; FOOTER: contiene info sulla pagina o il sito, oppure come l’header può essere l’elemento conclusivo di una sezione; NAV: contiene i link alle pagine del sito; ARTICLE: elemento di una sezione, come il post di un blog, può essere preso separatamente dagli altri elementi della pagina; SECTION: Sezione generica di una pagina o applicazione; ASIDE: contenuto collegato all’elemento padre, contiene info extra sulla sezione di riferimento o sulla pagina, ad es le sidebar sono degli aside
- Un tag semantico è un elemento HTML che descrive senza ambiguità il proprio significato (e di conseguenza il proprio contenuto) al browser che lo decodifica. Scrivere un codice HTML semantico è il primo passo per migliorare l’accessibilità web, perchè rende semplice la traduzione della pagina web da parte della tecnologia assistiva, ma ha un valore significativo anche per la SEO. Scrivere codice non semantico è un errore da più punti di vista. Quindi SEMANTICA, SIGNIFICATO espresso dal tag semantico e TECNOLOGIA ASSISTIVA
- Prima di arrivare al cuore della semantica è bene spiegare alcuni dei termini che userò più e più volte nel corso della presentazione: ASSISTIVE TECHNOLOGY con questo termine si indicano tutti gli strumenti che sono stati progettati per aiutare gli utenti le cui disabilità possono impedire o rendere difficile l’accesso alla tecnologia. E’ un termine allargato che comprende device, software e strumenti che aiutano tutte le persone con una disabilità a completare un task. Le tecnologie assistive rappresentano un sottoinsieme delle tecnologie in generale ma la distinzione in realtà non è così netta, per esempio la sintesi vocale è stata inventata per permettere ai non vedenti di utilizzare la calcolatrice, e poi è stata utilizzata in molte altre applicazioni da Google Maps ad al Google Home. E succede anche il contrario, succede di usare la tecnologia generale come assistiva quando per esempio usiamo lo zoom della camera del nostro smartphone per guardare qualcosa di piccolo nel mondo reale! Esiste una vasta gamma di tecnologie assistive in ambito sviluppo web, per dare supporto a diversi tipi di disabilità, sono quelle che abbiamo elencato nel recap della prima parte di Building for Everyone: screen reader, è un software che identifica e interpreta ciò che è visualizzato sullo schermo e lo rende fruibile da persone non vedenti o ipovedenti; braille display, è un dispositivo collegato al computer su cui lo screen reader indirizza il testo catturato dallo schermo, sulla superficie superiore una riga di aghi si alzano e si abbassano riproducendo il codice braille; lente di ingrandimento / zoom: integrato nel browser; voice control è una app che permette di controllare il cellulare con i comandi vocali; switch access è un dispositivo che viene collegato al cellulare utilizzando uno o più sensori al posto del touch screen; eye tracking che monitora i movimenti oculari traducendoli in input specifici consentendo così la scrittura che viene letta in maniera automatica e quindi di fatto permette ad una persona con una malattia del sistema nervoso di parlare di nuovo!
- L'affordance è l’invito all’uso! la capacità fisica di un oggetto di suggerire le azioni per usarlo nel modo giusto. Ad esempio, guardando una teiera, possiamo intuire come utilizzarla grazie a caratteristiche come il manico e il beccuccio.
- E possiamo anche intuire se c’è qualcosa che non va…come nel caso della celebre teiera del masochista di Donald Norman! Nel contesto delle interfacce utente, le affordance indicano le azioni che gli utenti possono compiere. Ad esempio, i bottoni in un'interfaccia grafica rappresentano dell azioni possibili. Queste affordance visive, come i bottoni, sono ispirate agli oggetti reali per facilitare l'apprendimento dell'utente. Una buona progettazione dell'interfaccia rende le affordance facilmente comprensibili, semplificando l'uso senza richiedere un lungo periodo di apprendimento.
- Guardando com’è fatto il DOM a sinistra, riusciamo ad assegnargli il giusto Accessibility Tree di fianco? Per rispondere viene facile spacchettare il DOM e leggerlo in orizzontale, invece che in verticale… guardiamo gli elementi: main heading (h1.Comments) - link (href.Home) -div1 -div2 -div3 div2: text - text fields div3: button Quindi la risposta è la 3!