2013-03-10 16 views
39

Qual è l'approccio migliore per rendere accessibile una SPA (AngularJS) (per screen reader, ecc.)?Accessibilità nelle applicazioni a una pagina (ARIA, ecc.)

Ho poca o nessuna esperienza con le specifiche di aria, e mi chiedo se funzionerà su un'applicazione a singola pagina.

Quali sono i problemi più comuni durante lo sviluppo?

Come si fa a eseguire il debug e testare l'accessibilità durante lo sviluppo?

+0

Di che accessibilità stai parlando? Puoi essere più chiaro ... – Abilash

+0

che cosa ha a che fare ARIA con javascript o angolare o singola pagina o multi pagina? – charlietfl

+0

Da quello che ho capito è una grande differenza tra ad esempio un link href e un link onclick? E se dovessi utilizzare uno schema di navigazione off canvas, in che modo gli screen reader potranno capire quali sono i contenuti a fuoco? Forse ho sbagliato tutto questo? –

risposta

74

Questo potrebbe coprire una vasta gamma di problemi qui. Quindi passerò attraverso alcune delle nozioni di base nella speranza che ti faccia partire, le insidie ​​comuni, per così dire.

In primo luogo, come i commentatori hanno detto, sì, è necessario assicurarsi che i tag ARIA siano utilizzati correttamente. Quindi, per esempio, se volessi esporre un div come pulsante, avresti qualcosa di simile.

<div id="mysuperflashybutton" ... role="button" aria-label="Super flashy" tabindex="0"></div> 

questo pulsante quando selezionato da un lettore di schermo si chiamerà "tasto super-appariscente", quindi non c'è bisogno pulsante per mettere in attributo aria-label. Ci sono esempi più complessi là fuori, ma questo illustra le basi di ciò, più o meno. Ruolo, aria-etichetta e tabindex saranno gli attributi ARIA più diffusi che vedi.

Gli elementi di indicizzazione delle schede da utilizzare per gli utenti di screen reader sono fondamentali per questo. Imposta tabindex su 0 per includerlo nella sua posizione predefinita sul documento. Se non vuoi che venga normalmente raggiunto da persone che utilizzano la navigazione da tastiera, impostalo su -1. Ciò significa che è fuori dal normale ordine di tabulazione, ma può ancora essere navigato su se si desidera mettere l'attenzione dell'utente lì manualmente attraverso javascript/jquery .focus().

Come accennato, a volte è possibile assistere i navigatori di tastiera/gli utenti di screen reader spostando il loro focus su di essi. Un esempio potrebbe essere se fanno clic su un pulsante e viene visualizzato un menu. Si potrebbe fare qualcosa di simile per metterli sul primo link del menu:

$('#linkmenuactivator').on("click", function() { 
    $('#linkmenu').find('li:first a').focus(); 
}); 

So che è in JQuery, io non sono a conoscenza AngularJS ma la mia breve vista mi fa pensare che sia più di un controller ViewModel al contrario di qualcosa di specifico dell'interfaccia come JQuery, ma correggimi se sbaglio.

Le regioni in diretta possono essere utilizzate se si stanno facendo cose funky sullo schermo che non hanno alcun senso per un utente di screen reader. Puoi scrivere del testo sugli elementi di queste regioni per mettere le informazioni fuori testo. Il modo più semplice per farlo consiste nell'utilizzare un ruolo di avviso o stato, rispettivamente per messaggi importanti o aggiornamenti di stato generici. Questi ruoli rendono il tuo elemento una regione attiva per impostazione predefinita e qualsiasi modifica al testo viene segnalata allo screen reader. Quindi un esempio veloce sarebbe simile a questa:

<p id="ariastatusbox" ... role="status"></p> 

Poi più tardi in jQuery (prendendo ad esempio si carica un documento e dissolvenza in quando ce l'hai):

$('#maincontent').fadeIn(function() { 
    $('#ariastatusbox').text('Document loaded'); 
}); 

Questo consentirà allo screen reader di sapere che il documento è caricato e pronto per essere letto sullo schermo. Le regioni dal vivo possono essere un po 'complicate, ma sono molto potenti se riesci a dominarle.

Infine, per quanto riguarda i test di accessibilità, ci sono alcune opzioni. Qualcosa di cui mi sono imbattuto recentemente è Wave che sembra essere uno strumento di test online. Sembra buono a prima vista, si potrebbe fare un tentativo.Un'altra opzione è prendere uno screen reader autonomamente e provarlo. Raccomando NVDA che è uno screen reader open-source (quindi gratuito). È il mio screen reader di scelta ed è dannatamente buono. Il sintetizzatore fornito in dotazione non ha la voce più bella, ma ci sono altre opzioni, oppure puoi disattivare l'uscita vocale e visualizzare una visualizzazione testuale di ciò che direbbe usando il Visualizzatore vocale. Un'ultima opzione è chiedere ai tester dell'accessibilità di portare la tua app per un test drive. Per i prodotti di consumo o le cose in quelle parentesi, i non vedenti e altri utenti di tecnologie accessibili potrebbero offrirsi volontari per farlo, se richiesto. Per le app più orientate al business che potresti non volere in un forum pubblico, ci sono diverse organizzazioni che possono consultare le questioni relative alla realizzazione di applicazioni web accessibili.

Questo non è affatto un manuale esauriente sull'accessibilità, speravo di iniziare davvero nella giusta direzione. Per un aspetto più approfondito, prova a guardare la documentazione di ARIA roles (tutto ciò aiuterà ma il codice è sotto l'intestazione delle definizioni) e da questo il ARIA States and Properties documentation. Entrambi possono essere un po 'secchi, ma hanno anche la lista completa di tutto ciò che puoi usare ARIA saggia. Google dovrebbe essere in grado di fornire anche alcuni tutorial, spero.

Spero che questo ti aiuti a iniziare. In bocca al lupo!

+0

Grazie mille Craig, questo mi aiuterà, e probabilmente molti altri a venire a rendere i nostri siti più accessibili. Questo era solo il tipo di presentazione che speravo. –

+1

@Craig Questa è una risposta fantastica, vorrei poter votare più volte. :-) – DSimon

Problemi correlati