Recommended
Recommended
More Related Content
Featured
Featured (20)
Building for Everyone - P1 - Cos'è l'accessibilità?
- 1. Cosa è l’accessibilità? Giacomo Ranieri GDG Lead, GDG Torino
- 2. Cosa è l’ Accessibilità
- 5. ● Contenuti disponibili per tutti Cosa rende un sito accessibili? E’ abbreviata con A11y ● Funzionalità utilizzabili da tutti
- 6. Dove falliamo di solito?
- 8. Quali strumenti: ● Screen reader ● Schermi Braille ● Navigazione con la Tastiera ● Strumenti di Zoom ● Temi ad alto contrasto Difficoltà Visive Quali difficolà: ● Cecità Completa ● Cecità Parziale (daltonismo, miopia, …) ● Cecità Temporanea (rifrazione solare)
- 9. Difficoltà Motorie Quali strumenti: ● Navigazione con Tastiera ● Tracciamento oculare ● Interruttori ● Attivazione Vocale Quali difficolà: ● Paralisi ● Problemi situazionali (bimbo in braccio) ● Problemi tecnici (trackpad difettoso)
- 10. Difficoltà Uditive Quali strumenti: ● Segnali visivi Quali difficolà: ● Sordità ● Problemi situazionali (luoghi rumorosi)
- 11. Difficoltà Cognitive Quali strumenti: ● Strumenti di Zoom Quali difficolà: ● ADHD ● Problemi situazionali (stress)
- 13. 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
- 14. 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 miglioreremo l’accessibilità?
- 15. Focus
- 16. Cosa è il focus
- 17. Muoversi nel Tab Order Tab Succesivo Shift Tab + Precedente Enter Esc Seleziona opzione ↓ → Opzione Successiva ↑ ← Opzione Precedente
- 18. <body> <nav> <button/> <button/> </nav> <main> …. <input/> <button/> </main> </body> Come funziona il tab order? Importante: ● Attenzione al CSS, conta il DOM ● Usare ordine logico e intuitivo
- 19. <div tabindex=”-1”></div> E se il tab order naturale non basta? ● 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
- 20. ● Pagina divisa in sezioni ● Single Page Application con cambio del contenuto al click L’eccezione che conferma la regola Soluzione: ● Identificare header di sezione ● Applicare tabindex=”-1” all’elemento ● Spostare manualmente il focus sull’elemento
- 21. Skiplink ● Ad inizio pagina ● Porta al contenuto principale evitando tutti i menu Migliorare ulteriormente l’esperienza
- 22. Le guide pratice ARIA ci dicono come comportarci per ogni elemento ● Combobox ● Caroselli ● Accordion ● Dialog ● etc E se uso componenti personalizzati? https://www.w3.org/WAI/ARIA/apg /
- 23. Costruiamo un radio group con il pattern Roving Focus ● Elemento corrente avrà tabindex=”0” ● Altri elementi tabindex=”-1” ● Al cambio ○ elemento succesivo tabindex=”0” ○ elemento corrente tabindex=”-1” ○ focus sull’elemento successivo Costruiamo un componente LET’S CODE
- 24. Contenuti fuori schermo ● Menu a scorrimento ● Elementi con larghezza 0 Soluzione: ● display:none o visibility:hidden ● Basta ripristinare la visibilità prima di animare
- 25. Esiste un caso dove è consigliato ● Modali ○ Focus può navigare solo tra gli elementi dentro alla modale Trappole per tastiera ● Input che dopo la selezione non permettono di spostarsi ● Comportamento da evitare per WCAG
Editor's Notes
- Prendiamo questo esempio, che problemi ha? < domanda al pubblico> Alcuni testi sono I ngrigio chiaro, quindi hanno un basso contrasto Le label sono dalla parte opposta del form, il che crea problemi con l'associazione label-informazione, grosso problema per chi usa gli strumenti di ingrandimento La checkbox non è associata alla label ( questo ve lo dico, ma fidatevi che succede spesso ) e devo cliccare una piccola area per selezionarla, e gli screen reader avrebbero difficoltà nel capire l'assocazione
- Con un po di magia dell'accessibilità eco il risultato: Il testo ora ha più contrasto, pur mantenendo la sua semantica Le label ora sono vicino all'informazione con la quale sono associate E ora label e checkbox sono un blocco cliccabile unico La versione precedente per me poteva funzionare lo stesso, ma avrebbe indotto maggiori errori e un maggior stress nella compilazione. Questa nuova versione funziona meglio per me e funziona anche per chi prima aveva problemi di accessibilità
- 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 Accesssiblità è spesso scritta in forma breve come A11y un po come I18n è l'internazionalizzazione e L10N è localizzazione
- Di solito come sviluppatori (e non solo) pensiamo che tutti siano in grado di vedere ed usare un mouse o un touch screen e che possano usare le applicazioni come noi, così facendo automaticamente riduciamo il range di persone che possono usare la nostra applicazione. Accessiblità riporta il focus sulle persone escluse dal nostro range ristretto, che possono avere qualche impedimento o disabilità, in modo che possona utilizzare la nostra applicazione. Mancanza di accessiblità è mancanza della possibilità di usare un sito perchè sei in un range di utenti che non è il tipico dell'applicazione. Noi tutti lo viviamo sulla nostra pelle accedendo da mobile ad un sito che non è responsive.
- Le persone con disabilità visive usano spesso screen reader, che con sintetizzatori text to speech, leggono quanto visualizzato sullo schermo, o il braille con gli schermi appositi. Spesso ci dimentichiamo della navigazione con tastiera, che è necessaria per queste persone per poter usare la nostra applicazione Chi non è cieco, ma ha forti impedimenti alla vista, usa screen reader e lo zoom per esempio. l'8% dei maschi e 0.5% delle femmine sono daltonici, e hanno problemi a distinguere rosso e verde o giallo e blu A volte basta che siamo sotto al sole diretto o che il proiettore sia di scarsa qualità, che ci ritroviamo con difficoltà ad intereagire con le applicazioni
- Ma ci sono anche persone che hanno difficoltà motorie, ci vedono, ma possono usare solo la tastiera, o il tracciamento oculare, degli interruttori o l'attivazione vocale O persone che hanno semplicemente un trackpad rotto o un sono su un treno traballante.
- Esistono inoltre persone con difficoltà uditive, come le persone sorde, che beneficiano di segnali visivi che attirano la loro attenzione, insieme ai segnali sonori che avrebbero la stessa funzione per chi non soffre di quella tipologie di difficoltà.
- E infine ci sono persone con difficoltà cognitive, come l'ADHD, che preferiscono zommare un testo per poterlo leggere o beneficiano di interfacce minimali che non li distraggano. Tutti possiamo beneficiarne quando abbiamo un alto carico cognitivo o siamo sotto stress.
- Ovviamente non si può lasciare al caso la gestione dell'accessibilità. Esitono 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 contento 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.
- All'interno di una pagina con il tasto tab spostiamo il focus sull'elemento successivo, con shift+tab lo spostiamo sul precedente e con le frecce ci possiamo muovere all'interno dell'elemento in focus, come ad esempio una lista. L'ordine con la quale specifichiamo questi spostamenti, il tab order, sarà quindi un elemento importante Input, Select e Button hanno integrata la possibilità di essere soggetti a focus, hanno tab order ed eventi da tastiera già integrati. Altri elementi non hanno di default la possibilità di essere soggetti a focus. http://udacity.github.io/ud891/lesson2-focus/01-basic-form/
- 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 seguire solo l'ordine naturale non è sufficiente, possono esserci elementi che hanno necessità di essere gestibili 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 programmaticamente, 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 , bottoni, input e altri elementi con la quale si vuole far interagire l'utente
- Ovviamente ad ogni regola generale seguono delle eccezioni. Mi fate alcuni esempi di quando potrebbe essere necessario? 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.
- <vediamo un esempio> Abbiamo visto come si naviga con la tastiera, ma vi siete accorti di una cosa? Quando apriamo la pagina, essendo i primi elementi sulla quale va il focus i primi nell'html, ci ritroveremo con il dover sempre passare tutti gli elementi nella navbar o del menu laterale prima di arrivare al contenuto. Questo può essere frustrante, soprattuto per chi usa degli switch attuati per esempio da un movimento della testa per effettuare gli spostamenti. Esiste quindi una prassi per risolvere questo problema, detta "skip link" Uno skip link è un link che permette subito all'inizio della pagina di portare il focus direttamente al contenuto principale <lo fixiamo> I browser moderni non necessitano nemmeno dell'inserimento di tabindex=-1, perché quando specifici l'href che punta ad un id, automaticamente all'interazione ti spostano il focus Il nostro skip-link sarà fuori dallo schermo, in una posizione assoluta nell'angolo in alto a sinistra, e quando avrà il focus si sposterà per diventare visibile
- Abbiamo visto come gli elementi nativi si comportano al focus, ma spesso realizzando i nostri siti, creaiamo componenti customizzate, che non usano gli elementi nativi del browser, e quindi non eriditano tutti i comportamenti del focus. In questi casi esistono delle guide pratiche ARIA (ARIA APG) che illustrano per ogni componente il comportamenti previsti e che quindi occorre realizzare. Ci sono sia per compenenti con un equivalente nativo che altri elementi di tipici del design dei siti (combobox, accordio, dialog, carosellli, etc)
- Vediamo un esempio di creazione di un radio group. Usiamo un pattern chiamato Roving Focus Dai i nostri elementi del radio group, l'elemento corrente avrà un tabindex=0, tutti gli altri avranno tabindex=-1, cliccando i tasti destra o giù ci dovremo muovere all'elemento successivo, pertanto cambiaremo i tabindex, portando il precedente a -1 e il corrente a 0 e faremo il focus sul nuovo elemento. Con un attributo checked e un po' di css potremo anche evidenziare l'elemento corrente. Arrivati alla fine della lista, il successivo diventerà il primo della lista e si ricomincerà il loop. Ovviamente è possibile fare lo stesso con i tasti sinistra e su per scorrere la lista dal verso opposto
- 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, soprattuto 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 possiblità 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 crerare 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 si