Web accessibility Andrea Crevola
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Web accessibility Andrea Crevola andrea.crevola@3juice.com
Accessibilità tecnica e funzionale Per costruire un sito web accessibile è necessario dedicare attenzione a: ● Struttura semantica della pagina (HTML) ● Colori, forme e dimensioni degli elementi (CSS) ● Eventi e animazioni (Javascript) ● Contenuti, immagini, video ● Navigazione e architettura ● Modalità di interazione tra utente e sistema
Tecnologie assistive
Adattamento / cambiamento di configurazioni ● Uso di font personalizzati ● Uso di uno schema di colori personalizzato ● Aggiustamento della dimensione del testo (dimensione minima) ● Cambio del livello di zoom ● Blocco delle finestre popup ● Impostazioni nel volume o velocità di riproduzione Configurare il browser: Firefox, Chrome, Internet Explorer, Edge Su Windows: Pannello di controllo > Accessibilità > Centro accessibilità
Screen reader
● Tecnologia assistiva “tipica”, utilizzata da non vedenti e ipovedenti per
superare problemi di accesso legati a disabilità della vista:
○ difficoltà a leggere il contenuto lo SR elabora il codice HTML e lo pronuncia nella lingua
dell’utente
○ difficoltà a cogliere il significato di una pagina nel suo complesso => lo SR permette di
accedere alla struttura (outline) della pagina
○ difficoltà a muoversi rapidamente nella pagina => lo SR introduce meccanismi di navigazione
speciali
○ difficoltà a utilizzare un mouse => lo SR rende il browser e sito internet operabile da tastiera
○ https://developer.paciellogroup.com/blog/2018/01/a-tale-of-two-rooms-understanding-screen-
reader-navigation/Screen reader: principali software
● JAWS (Windows) ● Apple Voice Over
○ http://www.freedomscientific.com/ ○ https://www.apple.com/accessibility/
Products/Blindness/JAWS iphone/vision/
○ http://www.freedomscientific.com/training/ ○ https://help.apple.com/voiceover/info/
training-JAWS-keystrokes.htm guide/10.12/?lang=it#/vo27974
● NVDA ● Google TalkBack (Android)
○ http://www.nvda.it/download ○ https://play.google.com/store/apps/details?
○ http://www.nvda.it/nvda-20164-guida- id=com.google.android.marvin.talkback&hl
dellutente =en
○ https://support.google.com/accessibility/
android/answer/6283677?hl=itScreen reader: alcune statistiche
Fonte: https://webaim.org/blog/survey7results/
Browser preferiti:
https://webaim.org/projects/screenreadersurvey7/
#browsersPrincipali problemi segnalati dagli utenti ● Captcha ● Il contenuto o parte del contenuto cambia repentinamente senza opportuni avvisi ● Gran parte dei siti web non soddisfa le basi dell’accessibilità: accesso da tastiera, testi alternativi alle immagini, titoli, tabelle. ● Le parti che compongono una pagina (header, contenuto, footer) non sono opportunamente segnalate alla tecnologia assistiva ● il 33% degli utenti adotta una barra braille insieme ad uno screen reader; ● il 41% afferma di usare una tastiera esterna insieme a un dispositivo mobile.
Utilizzare NVDA ● Screen Reader Basics: NVDA -- A11ycasts #09 https://www.youtube.com/watch? v=Jao3s_CwdRU&list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7g&index= 21 ● Comandi utili ○ CTRL + ALT + N => lancia NVDA ○ h => scorre gli heading ○ k => scorre i link ○ l => scorre gli elenchi ○ i => scorre gli elementi in un elenco ○ f => scorre i campi di un form ○ NVDA + f7 => lista degli elementi ○ NVDA + spazio => entra o esci dalla modalità “form”
Magnificatori di schermo Strumenti utilizzati da soggetti ipovedenti per applicare un forte ingrandimento dello schermo. ● Integrati nei principali OS (anche se esistono anche prodotti più completi) ● Ingrandimento fino a 16x ● Maggiore l’ingrandimento, minore è la porzione di schermo visibile ● Spesso uso abbinato a uno screen reader ● Problemi con il contrasto cromatico ● Problemi con la luminosità dello schermo (opzione per inversione colore) ● Problemi con interfacce “bi-dimensionali” ● Problemi con messaggi in hover ● Problemi con risultati distanti dai comandi che li hanno innescati
Dispositivi di input ● Tastiera ● Tastiere speciali ● Voice recognition / input ● Switch ● Touchpad ● Trackpad ● Software di scrittura assistita
Kit del valutatore Dispositivi: ● Personal computer Windows / Apple ● Dispositivi mobili Android e iOS Software ● Tutti i principali browser (vedi) ● Screen reader desktop e mobile (vedi) ● Validatori automatici e ausili alla valutazione ● Colour Contrast Analyzer
Browser (lista AGID) https://design-italia.readthedocs.io/it/stable/doc/user-interface/principi.html È necessario assicurare la compatibilità con almeno i seguenti browser: ● Internet Explorer 10+ ● Edge 12+ ● Safari 8+ ● Google Chrome (ultime versioni) ● Opera (ultime versioni) ● Mozilla Firefox (ultime versioni) ● IE Mobile 10+ ● iOS Safari 8+ (versione del sistema operativo) ● Android Browser 4+ (versione del sistema operativo)
Validatori automatici e ausili alla valutazione ● Validatore W3C del markup: https://validator.w3.org/ ● Validatore W3C del CSS: https://jigsaw.w3.org/css-validator/ ● Web developer toolbar: https://chrispederick.com/work/web-developer/ ● Google Chrome Lighthouse: https://developers.google.com/web/tools/lighthouse/ ● Vamolà: http://www.validatore.it/vamola_validator/checker/index.php Fino a che punto sono utili? Permettono di automatizzare i controlli ripetitivi e onerosi, ma non sono sufficienti per una valutazione approfondita che consideri il piano “semantico” della pagina.
Colour Contrast Analyzer https://developer.paciellogroup.com/resources/contrastanalyser/
Accessibilità & UX
Layout accessibili: errori comuni ● Combinazioni cromatiche non sufficientemente contrastate ● Testi sovrapposti a immagini ● Testi inseriti in immagini (a eccezione di loghi e decorazioni) ● Font size troppo ridotto ● Font weight troppo leggero ● Fare affidamento al solo uso del colore per veicolare informazioni
Layout accessibili: errori comuni /2 ● Fare affidamento ad icone non accompagnate da testo ● Fare affidamento sulla posizione degli elementi ● Link e bottoni non si distinguono dal resto del testo / pagina ● Distanza insufficiente tra gli elementi ● Controlli UI non standard ● Ordine degli elementi non significativo
Indicazioni per i testi ● Specificare sempre un colore per il testo e uno per lo sfondo (anche se bianco) ● Le righe di testo non dovrebbero essere più lunghe di 60-70 caratteri ● Interlinea minima 150% ● Tra un paragrafo e l’altro, inserire uno spazio pari a 1.5 volte l’interlinea del testo ● Il testo deve essere ridimensionabile fino al 200% (senza tecnologie assistive) senza che debba essere necessario scorrere orizzontalmente
Indicazioni per i testi / 2 ● Valutare l’adozione di font amichevoli verso i dislessici (Easy Reading: http://www.easyreading.it/it/) ● Non giustificare e allineare il testo a sinistra (per lingue occidentali) ● Attenzione agli “Icon fonts” (http://fontawesome.io/accessibility/) ● Dichiarare la lingua globale e i cambi di lingua ● Esplicitare acronimi e abbreviazioni ● Prevedere un glossario per termini tecnici o settoriali
Indicazioni per i testi / 3 ● Il testo deve essere comprensibile per una persona che ha seguito un ciclo di 9 anni di scuola: ● Introdurre il testo con un sommario ● Inserire illustrazioni, immagini e simboli che aiutino a spiegare idee, eventi e processi ● Prevedere una versione parlata del testo ● Rendere il testo facile da leggere (vedi) ● Per lingua italiana, considerare l’indice GULPEASE ( https://labs.translated.net/leggibilita-testo/)
Indicazioni per i testi / 4 ● 1 argomento = 1 paragrafo ● Frasi più semplici possibile (soggetto - verbo - oggetto) ● Frasi non più lunghe di 20 -25 parole ● Dividere le frasi troppo lunghe ● Periodi con meno di due congiunzioni ● Evitare gergo professionale ● Preferire parole semplici a forme più lunghe e meno familiari ● Eliminare tutte le parole non necessarie o ridondanti ● Liste puntate e numerate ● Attenzione ai pronomi ● Usare le forme attive dei verbi
Link e bottoni ● Il testo di link e bottoni deve essere comprensibile anche fuori contesto ● Sfruttare l’attributo title ● Sfruttare gli attributi aria-label, aria-labeledby, aria-describedby ● Non fare affidamento solo sul colore / forma / posizione per identificare un link o bottone ● Verificare il contrasto cromatico ● Prevedere uno stile (e verificare l’accessibilità) per tutti gli “stati” del bottone: hover, visited, focus... ● Usare controlli HTML5 standard
Struttura della pagina / sito ● Inserire gli elementi di navigazione sempre nello stesso punto ● Prevedere controlli per saltare le sezioni ripetitive, accessibili solo da screen reader e al focus ● Sfruttare una “Table of contents” ● Inserire titoli per strutturare la pagina ● Dare all’utente molteplici strade di accesso ad una pagina (navigazione, mappa del sito, ricerca) ● Aiutare l’utente a capire dove si trova (evidenziare voce di menu corrente, breadcrumbs) ● Non usare display:none per eventuali aree nascoste ma di interesse per gli screen reader (vedi)
Form ● Per ogni campo di form, inserire etichette () esplicite ● Ordine da tastiera deve essere significativo ● Il form deve essere compilabile integralmente con la sola tastiera ● La compilazione non dovrebbe essere soggetta a limiti di tempo; nel caso l’utente dovrebbe poter allungare tale tempo di 10 volte (avvisare se il tempo sta per scadere) ● in caso di interruzione, permettere all’utente di riprendere dal punto a cui era giunto ● identificare ed evidenziare chiaramente quale controllo abbia il “focus” ● non fare affidamento sull’attributo placeholder
Form / 2 ● Introdurre chiaramente l’obiettivo del form (titolo significativi, testo introduttivo) ● identificare gli errori e descriverli agli utenti, affinché li possano risolvere ● usare HTML5 per prevenire ed evidenziare gli errori (es required) ● per anticipare gli errori, accompagnare i campi con esempi di compilazione e altre istruzioni (attivabili da tastiera e persistenti) ● (quando il form richiede informazioni legali o finanziarie, oppure che influenzano altri dati già raccolti, oppure che sono parte di un test,) l’utente dovrebbe poter annullare oppure correggere oppure revisionare/confermare/ correggere prima di inviare definitivamente il form
Video / Audio
● Assicurarsi che il player sia accessibile da tastiera e via screen reader
● Player accessibili:
○ Youtube
○ Able Player: https://ableplayer.github.io/ableplayer/
○ Paypal Accessible HTML5 Video Player:
https://github.com/paypal/accessible-html5-video-player
○ Universal Video Player: https://source.ind.ie/project/video-player
● Sottotitoli (identificare il parlante + rumori di fondo)
○ Linee guida BBC: http://bbc.github.io/subtitle-guidelines/
● TrascrizioneAnimazioni ● Assicurarsi che nulla lampeggi più di 3 volte al secondo ● Gli eventi che guidano / innescano le animazioni devono essere attivabili da tastiera (non fare affidamento sull’esistenza di un mouse) ● Se l’animazione ha un ruolo informativo (es. istruzioni di montaggio di un oggetto), devono essere previsti i controlli per gestire l’avanzamento dell’animazione e un testo alternativo equivalente Vedi WAI-ARIA
Accessibilità & Codice
Impostazione generale del documento
Nota bene: l’applicazione corretta di HTML5 è Da non dimenticare...
un ottimo punto di partenza per assicurare
accessibilità alla pagina. Spesso non occorre ●
molto di più! ● html {font-size: 100%;}
●
Strategie di implementazione
1. Codice valido e conforme
2. Progressive enhancement
3. Responsive web designVisibilità degli elementi
● display:none nasconde un elemento per tutti i browser e tecnologie
assistive. Un testo così nascosto, non sarà letto dallo screen reader
● A. Gustafson, “Now you see me”, http://alistapart.com/article/now-you-see-me
visibility: hidden; Contenuto ignorato dallo screen reader
display: none; Contenuto ignorato dallo screen reader
height: 0; width: 0; overflow: hidden; Contenuto ignorato dallo screen reader
text-indent: -999em; Contenuto accessibile allo screen
reader
position: absolute; left: -999em; Contenuto accessibile allo screen
readerWAI-ARIA
● ARIA = Accessibile Rich Internet Applications
● https://www.w3.org/TR/wai-aria/
● Insieme di metodi per fornire alle tecnologie assistive indicazioni sul
funzionamento di un’applicazione web:
○ indicare il tipo di widget presentato ("menu", "treeitem", "slider", "progressmeter")
○ indicare il ruolo assunto da un elemento nella struttura della pagina web
○ indicare lo stato in cui si trova un widget (es. checked per un checkbox)
○ definire le aree “live”, ossia quelle che possono essere aggiornate dall’applicazione a seguito
dell’interazione con l’utente
○ gestire interazioni basate su drag and drop
○ fornire una navigazione / uso basati su tastiera per tutto quanto menzionatoNiente ARIA è meglio che cattiva ARIA ● ogni comando ARIA è una promessa che deve essere mantenuta ● i comandi ARIA possono anche peggiorare le cose, per esempio andando in conflitto con le normali e robuste API di accessibilità di HTML5 ● prima di usare ARIA, chiedersi sempre se non esista un equivalente comando HTML5 che svolga già quel compito (es. )
ARIA Landmarks
Consentono allo screen reader di identificare ●
delle “aree di navigazione” della pagina, a cui
●
l’utente può accedere agevolmente.
●
I tag strutturali HTML5 creano automaticamente
i landmark principali, anche se può essere utile ●
esplicitarli per ragioni di compatibilità. ●
●
(con aria-label=”” oppure aria-labeledby=””)
●
(con aria-label=”” oppure aria-labeledby=””
oppure title=””)
●ARIA roles
Metodi per comunicare alla tecnologia assistiva button, checkbox, gridcell, link, menuitem,
quale ruolo semantico abbia un elemento menuitemcheckbox, menuitemradio, option,
dell’interfaccia, indipendentemente dal suo progressbar, radio, scrollbar, searchbox,
markup separator, slider, spinbutton, switch, tab,
tabpanel, textbox, treeitem, combobox, grid,
Utili per rendere più accessibili elementi costruiti listbox, menu, menubar, radiogroup, tablist, tree,
con markup originale, come controlli UI custom treegrid, application, article, cell, columnheader,
definition, directory, document, feed, figure,
Esempio:
group, heading, img, list, listitem, math, none,
Etichetta
note, presentation, row, rowgroup, rowheader,
(ma sarebbe meglio usare !!!) table, term, toolbar, tooltip
https://www.w3.org/TR/wai-aria/
#roles_categorizationARIA live regions
● Metodo per avvisare l’utente in merito a cambiamenti avvenuti nel DOM
○ https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions
● Elemento che controlla l’aggiornamento:
○ Valida i dati
● Area che viene aggiornata:
○
Errori di validazione
Si sono verificati…ARIA live regions / 2
● role = ● aria-labeledby=”id_titolo”
○ “log”
○ “status” ● aria-describedby=”id_descrizione”
○ “alert”
● aria-atomic=”false”
○ “progressbar”
○ “marquee” ● aria-relevant=
○ “timer” ○ “additions”
○ “removals”
● aria-live=
○ “text”
○ “polite”
○ “all”
○ “assertive”
○ “off” (default)Applicazioni di accessibilità
Esempi di applicazione WAI-ARIA
● Ricordare sempre che “Niente ARIA è meglio che cattiva ARIA”
● WAI-ARIA Authoring Practices 1.1
○ https://www.w3.org/TR/wai-aria-practices-1.1/
● Esempi basati su jQuery:
○ http://hanshillen.github.io/jqtest/
● Bootstrap 4
○ https://getbootstrap.com/docs/4.0/components/Principali design pattern ● Accordion https://www.w3.org/TR/wai-aria-practices-1.1/examples/accordion/accordion.html ● Alert https://www.w3.org/TR/wai-aria-practices-1.1/examples/alert/index.html ● Breadcrumb https://www.w3.org/TR/wai-aria-practices-1.1/examples/breadcrumb/index.html ● Button https://www.w3.org/TR/wai-aria-practices-1.1/examples/button/button.html
Principali design pattern /2 ● Dialog (modal) https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html ● Disclosure (show/hide) https://www.w3.org/TR/wai-aria-practices-1.1/examples/disclosure/disclosure-faq.html ● Menubar https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html ● Tabs / Carosello https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-1/tabs.html
Puoi anche leggere
