7

Sto creando a website for a reading service for the blind and visually impaired e sto usando JavaScript (con jQuery) per stampare alcune cose in alcune pagine dopo che la pagina è stata caricata.Lettori di schermo e Javascript

Lo screen reader legge il contenuto stampato sulla pagina con jquery dopo che la pagina è stata caricata?

Da this page - "Generalmente, [screen reader] accedono al DOM (Document Object Model) e utilizzano le API del browser (Application Programming Interfaces) per ottenere le informazioni di cui hanno bisogno."

e sappiamo che jQuery è una libreria di manipolazione DOM.

Quindi la domanda diventa .. gli screen reader prendono una copia dell'intero DOM e quindi la analizzano e la leggono? O leggono il DOM, lo stesso su cui lavora jQuery?

Ecco un esempio di una delle pagine su cui uso JavaScript. Usa una funzione che determina quale programma abbiamo trasmesso via etere e poi stampa il nome del programma e un link per ascoltarlo.

<div id="now-playing-div"></div> 

<script> 

// invoke the audio-reader javascript library 
$(document).ready(function() { 
    var callback = nowPlaying; // catalog, schedule, podcasts, archive or nowPlaying 
    var selector = '#now-playing-div'; 
    makeAudioReaderPage(callback, selector); 
}); 

</script> 

Quindi, come si può vedere, se il lettore di schermo non legge quello che i JavaScript/jQuery stampe al # ora-playing-div allora leggerà niente. Quindi, abbiamo iniziato a ricevere alcune e-mail di ascoltatori confusi che si chiedevano cosa fosse successo al collegamento Now Playing.

Quindi questa mattina ho aggiunto questo:

<div id='no-js'>Please enable JavaScript to receive this content.</div> 

<script> 
$(document).ready(function() { 
    $('#no-js').toggle(); 
}); 

</script> 

Ma se il problema non è che ha bisogno di JavaScript per essere abilitato (a recent survey shows che il 99% degli utenti di screen reader hanno permesso JavaScript), allora il problema non è risolto e reso ancora peggiore perché ora l'utente dello screen reader potrebbe pensare che JavaScript non sia abilitato.

Cosa fare ??

+1

Dovresti controllare con uno specifico fornitore di screen reader, non c'è modo di rispondere a questo - loro ** DEVONO ** interrogare il live dom, e quindi vedi eventuali cambiamenti, ma se uno specifico interroga una volta e memorizza le cache, allora probabilmente non dovrebbe essere usato. Le pagine "statiche" non esistono più, e lavorare su una copia immediatamente morta/inutile/obsoleta di una pagina è estremamente inutile/stupido –

+2

C'è un buon modo per testare inizialmente questo - installa [NVDA] (http://www.nvaccess.org/), uno screen reader gratuito per Windows. Se sei su un Mac, prova VoiceOver. Puoi anche scaricare ed eseguire una prova di [JAWS] (http://www.freedomscientific.com/Downloads/JAWS). Ottieni una [panoramica video di NVDA] (https://www.youtube.com/watch?v=Vx1vSd5uYS8) o [scorciatoie da tastiera per tutti] (https://www.paciellogroup.com/blog/2015/01/basic screen-lettori-comandi-per-accessibilità test /). Successivamente, esplorare [ARIA live regions] (https://www.paciellogroup.com/blog/2014/03/screen-reader-support-aria-live-regions/). – aardrian

risposta

0

avevo bisogno di dire al lettore di schermo che la pagina è cambiata e che ha bisogno di leggere di nuovo il contenuto.

Questo viene eseguito con gli attributi ARIA.

Ho aggiunto il codice aria-live="polite" al mio html. L'impostazione "educata" indica allo screen reader che dovrebbe leggere il nuovo contenuto ma non interrompere ciò che viene attualmente detto. IIRC le altre impostazioni sono off e assertive.

<div id="now-playing-div" aria-live="polite"></div> 

<script> 

// invoke the audio-reader javascript library 
$(document).ready(function() { 
    var callback = nowPlaying; // catalog, schedule, podcasts, archive or nowPlaying 
    var selector = '#now-playing-div'; 
    makeAudioReaderPage(callback, selector); // the callback will append HTML to the element via jquery with the selector as the query term 
}); 

</script> 

In questo momento sto avendo un ragazzo che non può vedere nulla testare il sito web, ha usato per essere in grado di vedere e ha imparato ad usare il computer prima di perdere la vista dell'occhio.Sfortunatamente ha un brutto tempo con il sito web. Il problema è che quando arriva alla pagina per ascoltare l'audio, usa le scorciatoie da tastiera per cercare il pulsante di riproduzione, ma non c'è alcun pulsante di riproduzione perché il pulsante di riproduzione (jplayer) si trova in una finestra popup che viene visualizzata dopo aver fatto clic un collegamento. Si arrabbia e la telefonata è finita :(

Quindi la buona notizia è che è in grado di leggere il contenuto che viene aggiunto al documento tramite jquery, ma la cattiva notizia è che ci sono problemi più grandi con il flusso del sito Web e delle sue aspettative, è ovviamente colpa mia

3

È possibile testare questo senza dover sapere come gli screen reader analizzano il DOM. Offro questa risposta principalmente perché non hai offerto alcun codice da testare ("alcune cose in alcune pagine" non è un codice da testare) e il tuo esempio non fornisce un contesto sufficiente.

  • Installare NVDA, uno screen reader gratuito per Windows.
  • Se su un Mac, attiva VoiceOver.
  • Se su Ubuntu/Gnome, installare Orca
  • Scaricare ed eseguire una prova di JAWS.
  • Se su iOS, attiva VoiceOver.
  • Se su Android, attiva TalkBack.
  • Heck, prova Narrator su Windows.

Ci sono un sacco di tutorial per iniziare. Eccone un paio:

Quindi, se si scopre che il vostro script modifica il DOM dopo lo screen reader ha già analizzato esso, esplorare ARIA live regions e poi guardare browser support.

Infine, il tuo esempio di cui sopra sul rilevamento se lo script è attivato in realtà non hanno bisogno di script per funzionare se si utilizza l'elemento <noscript>:

<noscript> 
<p> 
Please enable JavaScript to receive this content. 
</p> 
</noscript> 

Se un browser ha scritto abilitato, questo non render (che è buono). Questo, tuttavia, non affronta casi in cui il blocco di script che si desidera mostrare non riesce per altri motivi (ritardo di rete, bug, ecc.). More on <noscript>

Dal momento che dici di "creare un sito Web per un servizio di lettura per non vedenti e ipovedenti" l'onere è davvero su di te per imparare gli strumenti e come testarli.

+0

questa è più una conferenza che una risposta, ma va bene –

+1

Scusa, non era quello il mio intento (anche se ora vedo che suona un po 'pungente). Parte del problema è che questo è un bersaglio mobile, quindi è difficile dare una risposta semplice. – aardrian

2

"In genere, gli [screen reader] accedono al DOM (Document Object Model) e utilizzano le API del browser (Application Programming Interfaces) per ottenere le informazioni di cui hanno bisogno."

I moderni lettori di schermo utilizzano l'API di accessibilità. Non devono sapere nulla di Javascript o del vero DOM e HTML (con la sola eccezione di ChromeVox).

Per questo motivo, lo stesso lettore di schermo saranno utilizzati per consultare Internet con il vostro browser preferito, scrivere mail con il vostro programma preferito (Thunderbird, Outlook, ...) o di giocare un flash player gioco, a patto poiché tali programmi forniscono le informazioni corrette alla loro API di accessibilità. Non analizzano direttamente l'HTML ma una vista ad albero accessibile di un documento.

Ciò significa che se il tuo browser comprende javascript, lo screen reader lo farà. Questo perché lo screen reader non accederà al DOM direttamente sul carico della pagina, ma interagirà con l'API di accessibilità fornita dal browser.

Ora, evidentemente, se lo screen reader legge il contenuto prima che fosse modificato da javascript, non avrà alcun indizio sulle modifiche apportate da javascript. Per questo, puoi usare l'attributo aria-live.

Questo è un breve riassunto, ma il seguente articolo può darvi maggiori informazioni sulla parsing del DOM dai lettori di schermo: Why accessibility APIs matter

Problemi correlati