Share
Questo è l'ultimo principio che vedremo. A grandi linee afferma che il contenuto e la navigazione del sito devono essere comprensibili. Mentre la responsabilità di implementare molte di queste raccomandazioni spetta al plugin o all'utente finale (o chiunque stia pubblicando il contenuto) del tema, ci sono raccomandazioni che gli sviluppatori di questi plugin e temi possono implementare.
La prima linea guida afferma che il contenuto dovrebbe essere "leggibile e comprensibile". Molte raccomandazioni riguardano il livello di lettura del contenuto e l'uso di parole insolite, abbreviazioni e acronimi, nessuno dei quali è rilevante per gli sviluppatori.
Una raccomandazione che possiamo implementare è che il linguaggio umano della pagina web dovrebbe essere in grado di essere identificato in modo programmatico. Per ottenere ciò, la lingua dovrebbe essere specificata sul elemento, tramite il Lang attributo. Inoltre il dir attributo dovrebbe essere usato per indicare se il contenuto è da destra a sinistra.
WordPress rende questo facile fornendo language_attributes (), che stampa gli attributi richiesti. Nel header.php del tuo tema:
>
Il language_attributes () funzione imposta la lingua del sito e, se necessario, la direzione e filtra l'output, consentendo ai plugin (ad esempio, plug-in multilingue) di modificare l'attributo come appropriato.
La seconda linea guida afferma che un sito web dovrebbe essere presentato e comportarsi in modo prevedibile. Molte raccomandazioni possono essere soddisfatte garantendo che il markup HTML del tema sia ben strutturato e logico. In aggiunta a ciò vi sono numerosi consigli "non fare" s contro l'adozione di modifiche che interrompono il comportamento naturale e logico di una pagina Web.
Abbiamo detto di non usare tabindex nel quarto articolo di questa serie ("Operabile"). Questo consiglio si basa su questo per affermare che quando un oggetto riceve attenzione, non dovrebbe essere considerato un trigger per qualche cambiamento dello stato della pagina.
Ad esempio, un pulsante di modulo che riceve lo stato attivo non deve far sì che il modulo venga inviato e un collegamento che riceve lo stato attivo non deve attivare quel collegamento. Questo è non per dire che i tooltip o, nel caso dei menu di navigazione, i sottomenu non dovrebbero apparire quando l'oggetto appropriato riceve lo stato attivo. Questi esempi non costituiscono un cambiamento di stato. In poche parole si possono equiparare le idee di un oggetto che riceve attenzione e un oggetto al passaggio del mouse.
Dovresti evitare di rimuovere il focus da un elemento che lo riceve. Ad esempio, non si dovrebbe mai fare qualcosa di simile al seguente:
Accentsconagua
$ ('a'). on ('focus', function () $ (this) .blur (););Di default gli unici moduli rilevanti per gli sviluppatori di temi sono i moduli di login / registrazione, ricerca e commento. Di questi, solo gli ultimi due sono in genere oggetto di attenzione da parte dello sviluppatore del tema. Poiché i moduli di ricerca non generano mai un "errore", ci concentriamo in questa sezione sui moduli di commento.
WordPress fa un ottimo lavoro nel notificare agli utenti un errore e informarli esattamente su quale sia l'errore. Tuttavia, lo fa consentendo agli utenti di lasciare la pagina originale e presentandoli con una pagina di errore "senza uscita".
Se gli utenti tornano alla pagina originale, il modulo avrà perso la concentrazione e dovrà trovarlo di nuovo. Una soluzione migliore sarebbe impedire agli utenti di inviare il modulo finché non hanno compilato correttamente il modulo. Tuttavia, quando si esegue questa operazione è essenziale comunicare agli utenti che il valore inserito non è valido, altrimenti le si intrappoleranno essenzialmente.
Sono disponibili numerosi script di convalida sul lato client ed è anche molto semplice creare il proprio script di convalida semplice. Ciò che è importante è:
role = "alert".Ecco un semplice esempio, basato sull'esempio di WebAIM di convalida della forma accessibile (che ti incoraggio a leggere), che aggiunge un messaggio di errore se il campo del nome è vuoto.
jQuery (document) .ready (function ($) $ ('# author'). on ('blur', function (e) var value = $ (this) .val (); if (! value) if ($ ('# author-error'). length> 0) $ ('# author-error'). remove (); $ ('') .insertAfter ($ (' # author ')) .text (' Name field error: Si prega di fornire un nome '); else if ($ ('# author-error'). length> 0) $ ('# author-error'). remove (); ); );L'esempio WebAIM impedisce inoltre agli utenti di lasciare il campo non valido e li restituisce al campo per correggere l'errore. Se lo fai, ti consiglierei non restituire l'utente al campo se il valore è vuoto, altrimenti si frustreranno gli utenti che hanno accidentalmente dato il focus sul campo, ma non hanno intenzione di inviare il modulo.
Come notato in precedenza in questa serie, non si deve fare affidamento solo sul colore o sulla posizione per trasmettere significato. In questo contesto, i messaggi di errore dovrebbero essere ovviamente così dal testo, così come i campi a cui si riferiscono.
I temi dovrebbero essere utilizzati comment_form () per visualizzare i moduli di commento e questo gestisce le etichette in modo accessibile. Allo stesso modo, anche il modulo di ricerca predefinito non ha bisogno di ulteriore lavoro. Tuttavia, nella personalizzazione o nello stile di questi moduli è necessario:
Le etichette devono essere visibili in ogni momento. In particolare, ciò significa che i segnaposto non costituiscono un'etichetta e non devono essere utilizzati come ricerca. Ci sono diverse ragioni per questo:
Se un campo modulo richiede ulteriori istruzioni, questi possono essere forniti dopo il campo, ma sono ancora esplicitamente collegati ad esso utilizzando il comando Aria-describedby attributo. Il contenuto dell'elemento a cui fa riferimento questo attributo viene letto dopo l'etichetta di campo.
Come esempio dal sito web del W3C:
Tuttavia, dovresti essere consapevole del fatto che esiste un supporto incoerente tra i lettori di schermo.
I campi richiesti devono essere contrassegnati come tali con aria-required = "true" attributo. Il modulo di commento WordPress predefinito come prodotto da comment_form () già gestisce questo, quindi non c'è azione voi bisogno prendere qui. Tuttavia, si dovrebbe essere consapevoli di questo se si sceglie di personalizzare i moduli di commento.
Questo articolo conclude la nostra guida per gli sviluppatori di temi approssimativi ai principi di accessibilità del W3C e come possono essere implementati. Nell'ultimo articolo di questa serie vedremo alcuni semplici modi per andare oltre, e incoraggiare attivamente e aiutare l'utente finale del nostro tema (o plugin) a produrre contenuti accessibili.
