Recommended
Recommended
More Related Content
Similar to Building for Everyone - P3 - Aria & Style
Similar to Building for Everyone - P3 - Aria & Style (20)
Building for Everyone - P3 - Aria & Style
- 1. ARIA & Style Giacomo Ranieri GDG Lead, GDG Torino
- 2. Cosa è l’ Accessibilità
- 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 miglioreremo l’accessibilità?
- 7. Muoversi nel Tab Order Tab Successivo Shift Tab + Precedente Enter Esc Seleziona opzione ↓ → Opzione Successiva ↑ ← Opzione Precedente Cos’è il focus
- 8. <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
- 10. Struttura di una pagina
- 11. Come si rende un sito accessibile quindi? ● Corretto ordine del DOM ● Strategia logica di Focus ● Gestione della Tastiera ● Uso degli elementi nativi e della loro semantica (Header, Landmark, etc) ● Implementazione delle Label ● Gestione dei Link
- 12. ARIA
- 13. ● Accessibile Rich Internet Applications o WAI-ARIA ● Specifiche parte di W3C Web Accessibility Initiatives ● Gestiscono i casi in cui l’HTLM non è sufficiente a fornire accessibilità ● Modificano come il DOM viene tradotto nell’Accessibility Tree ● Versione corrente 1.2 Cosa è ARIA?
- 14. <label> <input type="checkbox"> Accetta i termini e condizioni </label> Un Esempio Checkbox name:”Accetta i termini e condizioni” state: checked
- 15. <!-custom checkbox--> <div class="checkbox checked"> Accetta i termini e condizioni </div> Un Esempio Text value: ”Accetta i termini e condizioni”
- 16. <!-custom checkbox--> <div class="checkbox" role="checkbox" aria-checked="true"> Accetta i termini e condizioni </div> Un Esempio Checkbox name:”Accetta i termini e condizioni” state: checked
- 17. Aggiungere semantica Cosa possiamo fare con ARIA? <!-custom checkbox--> <div class="checkbox checked"> Accetta i termini e condizioni </div> Text value: ”Accetta i termini e condizioni” <!-custom checkbox--> <div class="checkbox" role="checkbox" aria-checked="true"> Accetta i termini e condizioni </div> Checkbox name:”Accetta i termini e condizioni” state: checked
- 18. Modificare semantica Cosa possiamo fare con ARIA? <!-custom checkbox--> <button class="toggle" checked> Accetta i termini e condizioni </button> Button name: ”Accetta i termini e condizioni” <!-custom checkbox--> <button class="toggle" role="switch" aria-checked="true"> Accetta i termini e condizioni </div> Switch name:”Accetta i termini e condizioni” state: checked
- 19. Esprimere UI pattern complessi Cosa possiamo fare con ARIA? ▼ Corso di Accessibilità ▶ Introduzione … ▶ Focus … ▶ Semantica: Basi … ▶ Semantica: Navigazione … ▶ Semantica: ARIA … <ul role="tree"> <li role="treeitem" aria-expanded="true"> Corso di Accessibilità </li> <ul role="group"> <li role="treeitem" aria-expanded="false"> Introduzione </li> <li role="treeitem" aria-expanded="false"> Focus </li> <!-etc-->
- 20. Inserire label aggiuntive Cosa possiamo fare con ARIA? <button class="glyph"> <div class="filter-glyph"> </div> </button> Button name: ”” <button class="glyph" aria-label="filter"> <div class="filter-glyph"> </div> </button> Button name:”filter”
- 21. Relazioni complesse Cosa possiamo fare con ARIA? <button aria-expanded="true" aria-controls="advanced-settings"> <h2>Impostazioni avanzate</h2> </button> <div id="advanced-settings"> <label><input type="checkbox">Mi offro per … </label> <label><input type="checkbox">Invia stat … </label> </div> Button name: ”Advanced ..” state: expanded Grou p Group name: ”” parent parent controls
- 22. Aggiornamenti Live Cosa possiamo fare con ARIA? <div role="alert"> Impossibile connettersi! </div> Impossibile connettersi! Impossibile Connettersi!
- 23. ● Esistono un moltitudine di ruoli, vedi WAI-APG ● Il solo ruolo spesso non basta, servono altri attributi ● Per custom element "role" deve essere applicato insieme a "tab- index" ● Verificare sempre le specifiche Ruoli
- 24. Ruoli ESEMPIO
- 25. ● "aria-label": permette di indicare una label accessibile, in override su quella del tag <label> Label e Descrizioni <button class="glyph" aria-label="filter"> <div class="filter-glyph"> </div> </button> Button name: ”filter”
- 26. ● "aria-labelledby": permette di indicare una label accessibile, specificando l’id di uno o più tag contenti testo, in override su quella del tag <label> e dell’attributo aria-label Label e Descrizioni <div id="rg-label"> Opzioni di volo </div> <div role="radiogroup" aria-labelledby="rg-label"> … </div> Radio Group name: ”Opzioni di volo”
- 27. ● "aria-describedby": permette di indicare una testo aggiuntivo accessibile, tipicamente più lungo, specificando l’id di uno o più tag contenti testo, Label e Descrizioni <input type="password" aria-labelledby="lb" aria-describedby="hint"/> <div id="lb" hidden> Password </div> <div id="hint" hidden> La password deve contenere minimo 8 caretteri, 1 numero, etc </div> Password edit text name: ”Password” name: ”La password deve contenere…”
- 28. Alcune accorgimenti ● Alcuni tag HTML hanno già un ruolo predefinito (input, button, …) ● Alcuni elementi hanno limiti sugli attributi che possono supportare ● Esistono ruoli che coprono le funzionalità dei landmark (header, nav, …) ● Esiste un ruolo apposito per le dialog
- 29. Modificare le relazioni ● "aria-owns": permette di indicare quali elementi sono figli dell’elemento corrente, modifica l’ordine con la quale sono visitati gli elementi <div role="menu"> <div role="menuitem" aria-haspopup="true"> Nuovo </div> <div aria-owns="submenu"></div> <!-altre opzioni--> </div> <div role="menu" id="submenu"> <div role="menuitem"> Documento </div> <!-altre opzioni--> </div>
- 30. Modificare le relazioni ● "aria-activedescendant": indica quale elemento figlio del corrente è da considerarsi in focus per le tecnologie assitive, e cattura gli eventi da tastiera <div role="listbox" tab-index="0" aria-activedesendant="i7"> <!-altre opzioni--> <div role="options" id="i5">Opzione 5</div> <div role="options" id="i6">Opzione 6</div> <div role="options" id="i7">Opzione 7</div> <!-altre opzioni--> </div>
- 31. Modificare le relazioni ● "aria-setsize" e "aria-posinset": gestiscono il posizionamento tra figli di uno stesso padre, indicando allo screen reader il numero dell’elemento corrente e il totale, utile sopratutto in caso di lazy loading <div role="listbox"> <!-altre opzioni--> <div role="options" aria-posinset="857" aria-setsize="1000">Opzione 857</div> <div role="options" aria-posinset="858" aria-setsize="1000">Opzione 858</div> <!-altre opzioni--> </div>
- 32. Nascondere gli elementi ● Gli elementi nascosti via CSS display:none e visibility:hidden o attributo HTML hidden sono rimossi dall’accessibility tree ● aria-hidden nasconde un elemento e i suoi discendenti dall’accessibility tree ma non dalla visualizzazione ● Gli elementi nascosti possono sempre reinseriti nell’accessibility tree se referenziati da aria-labelledby o aria-describedby
- 33. ARIA Live ● off : valore di default che indica la sezione come non live ● polite : indica che l'utente verrà avvertito solo al termine dell'interazione corrente, usata nella maggior parte dei casi, ad esempio per messaggi non urgenti ● assertive : in questo caso viene interrotta qualunque interazione per leggere il messaggio in quanto urgente
- 34. ARIA Live Alcuni attributi aggiuntivi: ● aria-atomic : permette di considerare una regione come un valore unico ● aria-relevant : permette di scegliere quali sono i cambiamenti da portare all'utente, e possono essere usate separatamente o come lista di opzioni [additions, removals, text, all] ● aria-busy : permette di ignorare temporaneamente i cambiamenti di un certo elemento, dopo il periodi di tempo dovrebbe essere riportato a false
- 35. Style
- 36. ● Per modificare come il focus ring compare sul browser usiamo la pseudoclasse :focus ● Impostare solo outline:0 è un antipattern ● Per assicurarci consistenza cross-browser possiamo usare box-shadow con outline:0 Focus *:focus { outline: 0; border-color: #36c; box-shadow: inset 0 0 0 1px #36c; }
- 37. Focus ● Con gli elementi nativi il browser sa distinguere tra interazioni da mouse e da tastiera, abilitando il focus ring solo su quest’ultima ● Di base negli elementi custom questa distinzione non è fatta ● Per introdurre personalizzazioni del focus da tastiera usiamo :focus- visible <div role="button" class="btn" tab-index="0"> Cliccami </div> .btn:focus-visible { outline: 2px solid blue; text-decoration: underline; color: white; background: #4aa498; }
- 38. Style sugli attributi Possiamo andare a personalizzare lo stile in base al valore di un attributo, non serve sempre aggiungere classi CSS specifiche per gli stati <div role="button" class="toggle" aria-labelledby="muteLbl" aria-pressed="true"> Muto </div> .toggle[aria-pressed="true"] { /* stile del toggle */ }
- 39. Gestione di Zoom & Rescaling grazie al meta tag viewport Responsive with=device-width initial-scale = 1 max-scale = 1 user-scalable= no <meta name="viewport" value="…">
- 40. Responsive grid con misure relative ● si adatta a diverse dimensioni schermo ● permette lo zoom della pagina Responsive % em rem
- 41. Dimensione dei bottoni minima consigliata: ● Dimensioni: 48 dp ● Distanza: 32 dp Interazione mobile
- 42. Contrasto
- 43. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua 15.9:1 5.7:1 3.5:1 1.6:1 #222222 #FFFFFF #222222 #FFFFFF #222222 #FFFFFF #222222 #FFFFFF Contrast ratio
- 44. Linee guida WCAG sul contrasto Fino a persone con acutezza visiva 20/40 (over 80) ● Ratio 3:1 per testi grandi (14dp bold o 18dp) ● Ratio 4.5:1 per testi normali Per persone con difetti visivi marcati ● Ratio 4.5:1 per testi grandi (14dp bold o 18dp) ● Ratio 7:1 per testi normali
- 45. Ultimi consigli ● Solo il colore non può veicolare errori o altre informazioni ● Rispettare le regole di contrasto può non essere sufficiente ● Meglio effettuare test attivando la modalità alto contrasto
- 46. Conclusioni
- 47. Come si rende un sito accessibile quindi? ● Strategia di focus ● Gestione della navigazione ● Uso degli elementi nativi e della loro semantica ● Implementazione delle label ● Utilizzo di ARIA per tutti i comportamenti non banali ● Creare una UI Responsive ● Attenzione al contrast ratio tra testi e background ● Seguire le linee guida WCAG
- 48. Fine… per ora!
Editor's Notes
- 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
- 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.
- 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.
- 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.
- 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
- ARIA è l'acronimo di Accessibile Rich Internet Applications, una serie di specifiche introdotte da W3C nell sue Web Accessibility Initiatives per gestire le casistiche dove l'HTML nativo non è sufficiente a fornire accessibilità, modificando come il DOM viene tradotto nell'accessibility Tree.
- SE prendiamo per esempio una checkbox nativa, questa verrà annunciata da uno screen reader come checkbox, con il nome <nome> e il suo stato checked
- Se noi volessimo riscriverla, supponendo che sia già stata implementata tutta la logica per gestirne l'interazione <esempio di check riscritta> Essa verrebbe letta come solo testo <nome>
- Per fare in modo che sia vista correttamente dallo screen reader ARIA ci viene in aiuto. Aggiugendo a questi elementi role = "checkbox" e aria-checked="true" o "false", il nostro screen reader vedrà l'elemento come una checkbox.
- Gli attributi ARIA, devono avere sempre un valore, una stringa vuota non attiverà quella funzionalità ARIA Questi non modificano in alcun modo apparenza, interazioni, focus o tastiera, si occupa solo della traduzione per l'accessibility tree. Aggiungere semantica, come abbiamo visto nell'esempio delle checkbox
- Può modificare in parte la semantica di alcuni elementi , come trasformare un bottone in uno switch
- Può essere usato per rappresentare patter UI complessi
- Può aggiungere delle label visibile solo alle tecnologie assistive, come per un pulsante con la sola immagine impostata senza possibilità di inserire un alternative text
- Può rappresentare relazioni semantiche tra elementi, oltre al solo esser figli o parent di un elemento, ad esempio il pattern, questo controlla quello, comme nel caso degli accordion, dove il controllore dell'apertura speso è tipicamente allo stesso livello del contenuto interno
- Può fornire aggiornamenti live quando un elemento viene modificato, come nel caso degli aler
- RIA fornisce un sacco di ruoli tra i quali scegliere, e ne vengono aggiunti mano a mano che i pattern di UX/UI cambiano. Quando usiamo un ruolo spesso andiamo a promettere che inseriremo altre parti. Quando specifichiamo il ruolo "checkbox", promettiamo di aggiungere uno stato checked a true o false, e un interazione da tastiera e mouse per cambiare questo stato. Seguendo la guida introdotta nella prima parte ( ARIA APG ) possiamo sapere quali cose ARIA si aspetta che andiamo a rispettare per un dato elemento. Per gestire correttamente il focus degli elementi custom, è importante che gli attributi "role" e "tab-index" siano applicati allo stesso elemenento HTML Analizzando le specifiche di ARIA siamo in grado di sapere come si deve comportare ogni elemento. Ci sono elementi che ereditano comportamenti e proprietà da altri elementi, alcuni che sono astratti e forniscono linee guida per elementi simili tra loro
- Andiamo a vedere un esempio pratico, nella prima lezione, per chi c'era, abbiamo visto come implementare le interazioni da tastiera dell'ARIA APG per un radio button group Andiamo ad aggiungere il ruolo di radiogroup all'elemento padre, e su ogni elemento figlio imposteremo il ruolo radio. Nella gestione della tastiera, aggiungeremo oltre alla gestione già presente dell'attribute checked, la gestione dell'attribute aria-checked
- ARIA suggerisce nella sua guida di aggiungere anche label e descrizioni quando possibile. Questo può essere fatto con "aria-label" "aria-labelledby" "aria-describedby" label permette di aggiungere una label accessibile, come in un pulsate con immagine senza alt text, questa eseguirà override di quanto presente normalmente sull'html
- labelledby permette di indicare un altro elemento ( tramite l'id ) il cui contenuto sarà la nuova label, ha la stessa funzionalità dell'elemento label, ma la sua relazione è contraria (elemento referenzia label) e può essere usata su tutti gli elementi. Ha pure la possibilità di concatenere più elementi. aria-labelledby override tutti gli altri elementi assegnatari di label <esempio>
- describedby ha funzionamento simile a quello di labelledby ma è nato per gestire testi descrittivi più lunghi. Per esempio lo possiamo usare per indicare testi esplicatori per le password e può essere richiamato al bisogno dall'utente
- Alcuni elementi html di default hanno un ruolo come gli input, e alcuni elementi hanno anche un limite sulle tipologie di attributi aria che possono supportare, conviene quindi verificare sempre se un attributo è supportato. I landmark che possiamo aggiungere ad una pagina, nav, header, footer, etc hanno un corrispettivo ARIA che può essere utilizzato alternativamente. Dipendentemente dal browser potrebbe essere necessario utilizzare sugli elementi landmark nativi HTML i role corrispondenti di ARIA
- Abbiamo visto comme si possono creare delle relazioni ARIA usando alcuni attributi come "aria-labelledby" ma non esistono solo questa tipologia di relazioni, altre permettono di modificare l'accessibility tree. Per esempio "aria-owns" permette di indicare che un elemento o una serie di elementi è figlio dell'elemento stesso <esempio> viene modificato l'ordine nella quale sono scorsi gli elementi, e l'ordine con il quale gli id sono elencati ne determina l'ordine ( tipicamente i figli nativi sono in ordine prima di quelli ARIA)
- Abbiamo "aria-activedescendant" che indica degli elementi figli del corrente quale è l'elemento dal focus attivo, utile per una lista, dove vogliamo il focus sulla lista stessa per poterne catturare gli eventi da tastiera, ma indica alle tecnologie assistive che l'elemento attivo è quello selezionato
- Gli attributi "aria-posinset" e "aria-setsize" invece aiutano a gestire il posizionamento tra figli di uno stesso padre, soprattuto utile quando esiste lazy rendering, e con setsize indichiamo quanti elementi prevediamo e con posinset l'elemento a che punto è di questa lista.
- Nello sviluppo di siti accessibili a volte è necessario nascondere dalla pagina o dall'accessibility tree alcuni elementi. Quando nascondiamo un elemeneto dalla pagina usando: Css display:none Css visibilty:hidden HTML5: attributo hidden Esso viene nascosto anche dall'accessibility Tree Possiamo andare a referenziare e rendere presente nell'accessibility tree elementi nascosti usando attributi come aria-labelledby o aria-describedby Per nascondere dall'accessibility Tree, ma non dalla visualizzazione, un elemento e tutti i sui discendenti usiamo invece "aria-hidden", esclusi ovviamente gli elementi referenziati da "aria-labelledby" o "aria-describedby"
- Prima abbiamo citato la possibilità di avvertire l'utente quando compare un alert, questo è permesso da "aria-live", che trasforma la sezione con l'attributo e tutto la sua discendenza in una sezione live. "aria-live" può avere 3 valori: off: valore di default che indica la sezione come non live polite: indica che l'utente verrà avvertito solo al termine dell'interazione corrente, usata nella maggior parte dei casi, per messaggi non urgenti assertive: in questo caso viene interrotta qualunque interazione per leggere il messaggio in quanto urgente E' consigliato mettere le sezioni aria-live in cima alla pagina, inoltre non tutte le tecnologie assistive reagiscono agli stessi
- Ci sono anche altre proprietà che modificano il funzionamento di aria-live: aria-atomic, che permette di considerare una regione come un valore unico, ad esempio se la scelta della data la operiamo con più di un input e al modificare di uno dei valori vogliamo ripetere tutta la data aria-relevant, permette di scegliere quali sono i cambiamenti da portare all'utente, e possono essere usate separatamente o come lista di opzioni: additions: per elementi aggiunti al dom removals: per elementi o testo sono rimossi dal dom text: quando viene aggiunto del testo un testo in uno dei discedenti del nodo "live" all: che copre tutte le tipologie additions text (default): combinazione di additions e text aria-busy, che permette di ignorare temporaneamente i cambiamenti di un certo elemento, dopo il periodi di tempo dovrebbe essere riportato a false
- Ora che abbiamo visto come rendere accessibile un sito usando focus, semantica, e aria, andiamo a vedere come il css può aiutarci a supportare meglio queste funzionalità, a gestire la flessibilità allo zoom e lo scaling della nostra UI e ad avere un appropriato contrasto
- Partiamo dal focus. Spesso ci accontentiamo di come i vari browser gestiscono di default il focus degli elementi. Andiamo invece a personalizzarlo con la pseudoclasse ":focus", essa è attiva solo quando l'elemento è in focus. Con la proprietà outline possiamo modificare l'apparenza del nostro focus ring. Nascondere il focus ring con outline = 0 è un antipattern, non aiuta gli utenti che usano la tastiera, in caso si voglia rimuovere l'outline è importante che il focus si possa distinguere, andando a renderlo chiaramente distinguibile dagli altri stati. Visti comportamenti diversi dei vari browser, può convenire non solo di nascondere l'outline ma anche di rivedere il box-shadow dell'elemento per assicurarsi un comportamento coerente. Quindi togliamo l'outline solo quando va contro lo stile del nostro sito, o si comporta in maniera anomala.
- Quando usiamo gli elementi nativi, ad esempio il bottone, il browser separa hover e focus, il primo per interazioni tramite mouse, e il secondo per iterazioni con la tastiera. Quando andiamo a creare un elemento custom, anche usando gli aria opportuni, questo comportamento non rimane e non è consistente tra i browser. Recentemente è stata introdotta per gestire quando il focus deve essere effettivamente visibile la pseudo classe :focus-visible.
- Quando andiamo a personalizzare lo stile di elementi come uno switch, attivo quando "pressed" , e andiamo anche ad usare aria per la gestione della sua accessibilità, possiamo evitare di andare a togliere e aggiungere classi per gestire il suo stato pressed, possiamo affidarci all'attributo aria-pressed="true" per modificare lo stile del nostro toggle. Questo mi assicura anche che il mio stato ARIA sia correttamente impostato
- Parliamo di responsive. Creare un sito responsive, non è solo utile per gestire le interazioni da mobile, ma è anche utile per gestire quando avviene un interazione di zoom o rescaling. Ovviamente scrivere un sito responsive è un argomento lungo, che se vi fa piacere potremo affrontare in futuro. Però possiamo svelare qualche trick utile soprattutto quando gestiamo l'accessibilità del sito. E' importante aggiungere un tag "meta" per il viewport, con with=device-width e initial-scale = 1 Questo meta tag indica al browser come gestire le dimensioni della pagina e il suo scaling, con with=device-width il browser fare il matching con la dimensione schermo in "device independent pixel", e con initial-scale = 1 indichiamo che inizieremo con 1 pixel CSS = 1 pixel device independent. Bisogna inoltre evitare, a meno che non sia indispensabile di settare la max-scale = 1 e user-scalable= no, in quanto anti pattern che impediscono all'utente di fare pinch to zoom utile per ingrandire ad esempio i testi.
- Altra cosa è di impostare il sito avendo a mente una responsive grid, che possa rispondere alle dimensioni di schermo diverse o allo zoom della pagina. Questo tipicamente è ottenuto usando unità di misura relative (le percentuali), e unità di misura per il font in em (che si basa sulla font-size del padre) e rem (che si basa sulla font-size root). Così facendo le dimensioni si adattano a quelle dello schermo e degli zoom. Ovviamente scrivere un sito responsive è un argomento lungo, che se vi fa piacere potremo affrontare in futuro. Però possiamo svelare qualche trick utile soprattutto quando gestiamo l'accessibilità del sito. E' importante aggiungere un tag "meta" per il viewport, con with=device-width e initial-scale = 1 Questo meta tag indica al browser come gestire le dimensioni della pagina e il suo scaling, con with=device-width il browser fare il matching con la dimensione schermo in "device independent pixel", e con initial-scale = 1 indichiamo che inizieremo con 1 pixel CSS = 1 pixel device independent. Bisogna inoltre evitare, a meno che non sia indispensabile di settare la max-scale = 1 e user-scalable= no, in quanto anti pattern che impediscono all'utente di fare pinch to zoom utile per ingrandire ad esempio i testi.
- Quando invece stiamo gestendo la vista mobile, è importante che la zona di interazione attorno ai pulsanti sia abbastanza grande da poterci interagire con le dita senza premere elementi indesiderati, utile soprattutto per persone con impedimenti motori. É consigliato che sia almeno di 48 device independent pixel (dp) che corrisponde circa alla dimensione di un dito (9mm) e che siano separati da almeno 32 dp per evitare di premere altre porzioni.
- Infine parliamo di contrasto. Tutti noi involontariamente pensiamo che la percezione dei colori che abbiamo sia la medesima , ma è scientificamente provato il contrario, per questo una selezione corretta di colori e contrasto ci permette di avere una UI piacevole ma anche accessibile.
- Guardando questa slide, alcuni di voi potrebbero non riuscire a leggere correttamente tutti i testi. Ognuno di questi testi ha un colore che mano a mano che andiamo a destra sbiadisce. Il rapporto tra i due colori , quello del testo e quello del background è detto contrast ratio. Più sono diversi più questo ratio aumenta.
- Le linee guida WCAG ci dicono che per i testi grandi (14dp bold o 18 dp) il ratio deve essere di almeno 3:1, mentre per tutti gli altri testi deve essere almeno 4.5:1 Solo le prime due colonne rientrano nel ratio richiesto Questi contrasti sono sufficienti per le persone con una acutezza visiva 20/40, tipica delle persone over 80 Per invece andare in contro a chi ha difetti visivi più marcati i contrasti salgono a 4.5 e 7.1
- guardo al colore, ricordiamoci inoltre che il solo colore per indicare che un campo è in errore, non è sufficiente, in quanto potrebbe non essere percepito da chi è daltonico e non è percepibile da chi usa screen reader. Questo vale anche per i link, che conviene ad esempio sottolinearli oltre che colorarli diversamente. Rispettando le regole sopra siamo abbastanza tranquilli nel dire che il nostro sito sarà correttamente navigabile, possiamo valutare però di verificare il suo comportamento sotto temi ad alto contrasto, installando l'apposita estensione di chrome