Javascript e accessibilità

StackOverflow https://stackoverflow.com/questions/266777

Domanda

In qualità di sviluppatore web, alcuni dei progetti a cui lavoro rientrano negli ombrelli governativi e quindi sono soggetti a 508 Accessibilità leggi e talvolta Accessibilità W3C . In che misura è possibile utilizzare JavaScript pur soddisfacendo questi requisiti?

In questo senso, fino a che punto JavaScript, in particolare AJAX e l'utilizzo di pacchetti come jQuery per fare cose come visualizzare dialoghi modali, popup, ecc. supportati da moderni software di accessibilità come JAWS, Orca, ecc.? In passato, la regola era simile a " Se non funziona in Lynx, non funziona per uno screen reader. & Quot; È ancora vero o ci sono stati ulteriori progressi in questi settori?

EDIT: il consenso sembra essere che javascript va bene fintanto che ci sono fallback non javascript, tuttavia sembra ancora incerto sul supporto di AJAX nel software dello screen reader. Se qualcuno ha un'esperienza specifica con questo, sarebbe molto utile.

È stato utile?

Soluzione

Se l'accessibilità è la tua principale preoccupazione, avvia sempre un sito Web utilizzando HTML conforme agli standard (scegli una definizione del tipo di documento e attenerti) HTML. Se si tratta di un'applicazione Web (invio di moduli, ecc.), Assicurarsi che i moduli funzionino utilizzando solo HTTP GET e POST. Una volta che hai un sito Web / un'applicazione completi, puoi aggiungere bit di CSS e JavaScript purché il sito funzioni ancora, con uno o entrambi disattivati.

Il concetto più importante qui è Progressive Enhancement . Stai aggiungendo ulteriori campane e fischietti usando CSS / JavaScript, ma il tuo sito web / applicazione funzionerà perfettamente senza .

Un ottimo strumento per testare 508 , WAI , CSS disattivato, JavaScript disattivato prova a utilizzare Web Developer plugin per Firefox.

Altri suggerimenti

Penso che la risposta sia davvero nel modo in cui architetti le cose. JQuery ha la capacità di essere discreto e quindi accessibile. Il trucco è avere ridondanza attorno alle chiamate AJAX in modo che i browser senza JavaScript possano ancora utilizzare il tuo servizio. In altre parole, ovunque tu abbia risposte JavaScript, finestre di dialogo, ecc. Devi avere un equivalente degradato.

Se hai in mente l'accessibilità e stai testando correttamente entrambi i casi d'uso (JavaScript vs. Non JavaScript), dovresti essere in grado di scrivere applicazioni che soddisfino entrambi i destinatari.

Esempio ($ (documento). Già chiamato omesso per chiarezza e brevità: 

<script>
  $("#hello").click(function(){
    alert("Hi");
  });
</script>
<a href="/say_hello.htm" id="hello">Say Hello</a>

Un esempio banale ma fondamentalmente questo valuterà l'evento click JavaScript se JavaScript è supportato. Altrimenti, funzionerà come un normale link e andrà a say_hello.htm - il tuo compito come sviluppatore è assicurarti che entrambi i risultati siano gestiti in modo appropriato.

Spero che ti aiuti!

Il miglioramento progressivo è certamente un percorso, ma la discrezione non è il primo e finisce tutta l'accessibilità di JavaScript poiché gli screen reader tendono a utilizzare i browser come base per il loro lavoro. Poiché tali browser supportano JavaScript, gli script sulla tua pagina verranno comunque eseguiti. Questo è un problema particolare con AJAX poiché fare clic su una parte della pagina potrebbe cambiare un'altra parte della pagina di cui lo screen reader non è a conoscenza.

Man mano che AJAX matura, tuttavia, stanno emergendo metodi per renderlo accessibile. Cerca nel WAI-ARIA i metodi moderni per rendere accessibile AJAX e AxsJAX di Google per un buon modo di implementarlo.

Vedi

Potresti anche dare un'occhiata a FlashAid, anche se è tutt'altro che una soluzione perfetta. (Ma se hai utilizzato il miglioramento progressivo e hai utilizzato AJAX solo quando Flash era presente e l'utente non utilizzava l'API di accessibilità, potresti avere una soluzione ragionevole ... per Windows.)

A lungo termine WAI-ARIA è la soluzione. È in qualche modo supportato in JAWS 10 (beta) e Firevox, ma certamente non è sufficiente per tutti gli utenti di oggi.

  

JQuery ha la capacità di essere discreto e quindi accessibile. Il trucco è avere ridondanza attorno alle chiamate AJAX in modo che i browser senza JavaScript possano ancora utilizzare il tuo servizio. In altre parole, ovunque tu abbia risposte JavaScript, finestre di dialogo, ecc. Devi avere un equivalente degradato.

Un modo per farlo per riutilizzare il tuo codice è quello di avere il tuo "semplice" pagina che chiama una funzione "quot" (o qualunque cosa tu usi per la logica lato server) che può essere chiamata da sola, restituendo JSON o XML.

Ad esempio: /static/myform.asp (sul lato server, 'include' la stessa logica di /ajax/myform.asp) in questo modo useresti asp come template di django.

Ovviamente, con un framework completo di campane e fischietti, potresti renderlo molto più semplice (pensa di avere un 'template' html e xml per la stessa vista in django), ma si applica la stessa idea.

Fatto ciò, ripetendo tutte le ancore sul documento pronto usando jQuery e aggiungendo eventi onclick usando il link dell'ancora, la sostituzione / statica / ajax / potrebbe semplificarti la vita.

Qualcuno può pensare a ragioni per cui questo è troppo oneroso? Vorrei sapere se c'è qualche grave difetto in questa "idea progettuale".

Penso che la risposta accettata, anche se va bene per il suo tempo, non è più aggiornata. (Letteralmente un decennio al momento di scrivere questa risposta. WCAG 2.1 è stato finalizzato poche settimane fa ...)

Il documento W3C WAI-Authoring Design Patterns Practices include vari esempi di widget comuni che richiedono javaScript per comunicare la giusta semantica, stati e ruoli alle tecnologie assistive.

AJAX può essere reso accessibile, fintanto che si presta attenzione a fornire agli spettatori indizi semantici pertinenti su quale sarà l'aggiornamento in-page prima che l'utente lo attivi. Potrebbe anche essere necessario informare lo screen reader su ciò che è effettivamente cambiato in seguito, ad es. una regione aria-live potrebbe annunciare "20 nuovi articoli sono stati caricati" o qualunque altra cosa. Ciò si ottiene con javaScript.

Se la tua conoscenza dell'accessibilità si ferma al "miglioramento progressivo" e vedi la risposta accettata sopra come motivazione di quella posizione, allora potresti aver bisogno di un aggiornamento. Le cose si stanno muovendo velocemente in questi giorni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top