Creazione di applicazioni Oracle JET accessibili

Nota: questo percorso di apprendimento prevede un prerequisito, Sviluppare un'applicazione Web in Oracle JavaScript Extension Toolkit (Oracle JET), che deve essere completato prima di iniziare questo corso.

Introduzione all'accesso facilitato

Ora che hai una conoscenza di base di come utilizzare Oracle JET per sviluppare applicazioni Web, è giunto il momento di soddisfare le esigenze specializzate di quasi il 10-20% del tuo pubblico di destinazione, ovvero quelli con disabilità. Secondo un articolo pubblicato dall'Organizzazione Mondiale della Sanità del 2014, circa il 15% della popolazione mondiale ha una qualche forma di disabilità, e quel numero cresce con una popolazione sempre più anziana.

Cronologia

Il concetto moderno di accessibilità ha avuto origine alla fine del 1960s come movimento di base nei campus universitari e nelle comunità locali per affrontare i diritti delle persone disabili che cercano l'accesso fisico agli edifici pubblici. Questo accesso includeva rampe lungo passerelle pubbliche, ingressi, porte automatiche ed etichette Braille negli ascensori per edifici pubblici, governativi e universitari.

Legislazione sulla parità di accesso

Oggi, "accesso" incorpora sia l'accesso fisico alle strutture e l'accesso all'attuale panorama tecnologico di PC, laptop, tablet, smartphone e dispositivi a controllo vocale come Amazon Alexa. La legislazione sulla parità di accesso continua ad affrontare le questioni dell'accesso fisico e della tecnologia da cui siamo dipendenti.

L'accessibilità del software è obbligatoria dalle leggi civili in molti paesi in tutto il mondo. Ad esempio:

• The Americans with Disabilities Act negli Stati Uniti
• The Accessibility for Ontarians with Disabilities Act in Ontario, Canada
• The Equality Act del 2010 nel Regno Unito

Sfide per l'accesso - Tipi di ostacoli

Come web application designer e sviluppatori, dobbiamo essere consapevoli del fatto che i clienti disabili affrontano ostacoli quando accedono alla tecnologia. Considerare quanto riportato di seguito.

• Un utente non può manipolare il mouse a causa di una mobilità compromessa (difetto alla nascita congenito, malattia di Lou Gehrig, morbo di Parkinson, artrite reumatoide, lesioni o un deficit correlato all'invecchiamento). In che modo un utente di questo tipo attiva il testo a cui è associato un evento in fase di clic?
• Un utente è ipovedente e non può vedere che le istruzioni per l'utilizzo di una pagina o di un modulo seguono dopo il contenuto. Come saprebbe l'utente leggere l'intera pagina per trovare le istruzioni?
• Un utente ha una visione ridotta e utilizza una lente di ingrandimento dello schermo che si concentra e ingrandisce solo una piccola parte dello schermo alla volta. Date le limitazioni dell'ingranditore, come potrebbe l'utente sapere se un messaggio viene visualizzato altrove sullo schermo?
• Un utente è daltonico e non riesce a distinguere determinati colori. Come farebbe l'utente a sapere qual è il pulsante rosso, blu o verde a cui si fa riferimento nel testo della pagina?

Queste sono solo alcune illustrazioni delle preoccupazioni che uno sviluppatore deve affrontare durante la creazione di un'applicazione web accessibile. Questo percorso formativo fornisce metodi chiari per la codifica e il test dell'accessibilità al fine di garantire la conformità agli standard più aggiornati definiti dalle linee guida per l'accessibilità dei contenuti web (WCAG) versione 2.2.

È prudente esaminare attentamente le linee guida sopra menzionate, poiché costituiscono la base del nostro lavoro in materia di accessibilità.

Linee guida per l'accessibilità dei contenuti Web (WCAG)

Il World Wide Web Consortium (W3C) ha creato un insieme di standard denominati Web Content Accessibility Guidelines (WCAG) che forniscono regole molto specifiche per l'accessibilità di siti Web e applicazioni Web. Queste linee guida costituiscono la base per questo percorso di apprendimento.

Gli standard WCAG si concentrano su quattro aree di un'applicazione Web o di un sito Web:

1. Percepibilità: l'interfaccia può essere percepita da una grande maggioranza di individui indipendentemente dalle disabilità?

   • Rapporti di contrasto di colore che funzionano bene per coloro che hanno la visione bassa
   • Semplicità di layout che funziona bene per coloro che hanno deficit cognitivi

2. Funzionalità: le persone possono interagire con l'interfaccia indipendentemente dalle disabilità?

   • Accesso solo da tastiera: navigare e utilizzare l'interfaccia senza l'uso di un mouse
   • Accesso solo vocale: gestisci l'interfaccia solo con l'input vocale

3. Comprensibilità: l'interfaccia è facilmente comprensibile dalle persone indipendentemente dalle disabilità?

   • Il contenuto è scritto per essere compreso da individui con disabilità cognitive
   • L'interfaccia è compresa da un individuo che utilizza un lettore di schermo

4. Robustezza: l'interfaccia supporta una varietà di agenti utente (browser, dispositivi e tecnologie assistive)?

Se i criteri WCAG sono soddisfatti, anche le applicazioni Web e i siti Web devono soddisfare tutti i requisiti legali.

Il costo dell'accessibilità

Va notato che l'accessibilità non dovrebbe mai essere un ripensamento quando si scrive il codice. Anche se il processo di sviluppo è più lungo, è più conveniente scrivere funzionalità di accessibilità nel codice durante la fase di sviluppo che modificare un'applicazione esistente.

Gli sviluppatori spesso si lamentano della necessità di soddisfare i requisiti speciali di una popolazione probabilmente piccola. Se implementato correttamente, il codice accessibile rende un'applicazione più facile da usare per tutti, non solo per i disabili. Ad esempio, semplificando l'interfaccia e scegliendo i colori con rapporti di contrasto più elevati, le applicazioni sui dispositivi mobili o sui browser più vecchi sono più semplici da utilizzare.

1, 2, 3 passi per il successo

L'accessibilità inizia nella fase di progettazione. I progettisti creano un progetto di ciò che il programma fa. Dovrebbero tessere l'accessibilità in tutto il design per garantire che il piano includa meccaniche efficaci per l'accesso solo da tastiera. Questo tipo di accesso consente dispositivi di input alternativi per coloro che hanno un uso limitato o nullo delle loro mani.

Gli sviluppatori devono avere sia una solida conoscenza di come codificare per l'accessibilità (front-end) sia una consapevolezza tecnica su come testare l'accessibilità (back-end).

Gli ingegneri del Quality Assurance (QA) devono parlare il linguaggio dell'accessibilità. Essi, come gli sviluppatori, devono comprendere ed eseguire test di accessibilità insieme ai normali test per funzionalità e sicurezza. I professionisti del controllo qualità sono il buffer tra il software che viene rilasciato e il potenziale di contenzioso se non vengono rispettate le linee guida sull'accessibilità.

Note all'avviso

Oracle JET è aperto al pubblico per l'utilizzo in applicazioni e siti Web non Oracle. Pertanto, quando si scrivono applicazioni Oracle JET, è necessario rispettare le WCAG versione 2.2.

Questo percorso di apprendimento si concentra principalmente su quegli aspetti dell'accessibilità che si applicano all'accesso alla tastiera e all'uso del lettore di schermo. Questo percorso non si concentra sugli aspetti cognitivi della progettazione o della creazione di un'applicazione Oracle JET.