Questo principio afferma che tutto il contenuto deve essere in un formato (o disponibile su richiesta in un formato) che possa essere facilmente percepito dall'utente. Detto in altri termini, i tuoi siti web dovrebbero essere progettati in modo tale che chiunque possa 'leggere' il contenuto, indipendentemente da eventuali disabilità che potrebbero avere. Molti utenti con disabilità useranno tecnologie assistive; per esempio quelli con disabilità visive possono usare uno screen reader, che legge ciò che appare sullo schermo, o un convertitore testo-braille. L'obiettivo è quindi quello di facilitare queste tecnologie assistive.
Si prega di ricordare che le linee guida qui sono non esauriente, quindi è necessario fare sempre riferimento alle Linee guida per l'accessibilità del contenuto Web.
Questo è forse il consiglio più comune per migliorare l'accessibilità. Se il tuo sito web contiene qualunque immagini, quindi queste sono ignorate dagli screen reader salvo che usi il alt
etichetta.
Nota che la descrizione di alt potrebbe non essere necessariamente una descrizione di cosa sia l'immagine, ma piuttosto di ciò che l'immagine sta cercando trasmettere. Il tag alt dice a parole quello che stai cercando di dire con l'immagine.
Sebbene questo consiglio sia per lo più adatto agli editori, lo sollevo qui perché gli sviluppatori di temi spesso forniscono un logo anziché un testo per trasmettere il nome del sito Web o dell'azienda. In questo caso, probabilmente è meglio usare il nome del sito (get_bloginfo ( 'name')
) come descrizione alternativa:
eco ''. get_bloginfo ('nome'). '
';
I tag alt dovrebbero non essere utilizzato per immagini puramente decorative, altrimenti si costringe l'utente a setacciare informazioni eccessive e non necessarie.
Se il tuo plug-in crea un modulo, potresti aver bisogno di una sorta di conferma dell'accesso a una persona anziché a un computer. Se decidi di fornire all'utente un'immagine o una clip audio, che devono quindi interpretare, dovresti spiegarlo nel testo e fornire una forma alternativa di CAPTCHA per accogliere diverse disabilità.
Questa linea guida si applicherà ampiamente agli sviluppatori di plug-in, ma può anche essere applicata ai temi. Se il colore, la forma o la posizione vengono utilizzati per trasmettere un significato che non è discernibile dal testo, tale significato viene perso per gli utenti che sono daltonici o ciechi.
Ad esempio, un esempio tipico potrebbe essere rappresentato dai pulsanti del modulo di contatto che si basano esclusivamente su un'icona del famoso font Font Awesome:
Lo scopo di questi pulsanti è evidente a un utente avvistato, ma per coloro che si affidano a lettori di schermo non vi è alcuna indicazione su cosa fanno i pulsanti. Se, per motivi di progettazione, vuoi evitare di usare il testo, devi specificare l'etichetta usando il Aria-label
attributo.
Questo è solo un esempio del protocollo ARIA, che tratteremo in maggior dettaglio nel prossimo articolo.
Questo è un requisito quasi ovvio. Anche per una persona ben vista, un sito web con un basso contrasto tra testo e sfondo è difficile da leggere e può causare affaticamento della vista. Per chi ha problemi di vista, è richiesto un livello ancora maggiore di contrasto, motivo per cui il WCAG afferma che lo sfondo e il colore del testo dovrebbero avere un rapporto di contrasto di 4,5: 1.
Non è immediatamente evidente quale sia il rapporto o il significato di questo rapporto, ma esistono una varietà di strumenti che consentono di verificare il rapporto:
Il testo più grande ha un requisito inferiore di 3: 1, mentre i loghi, il testo che è puramente decorativo o non visibile e il testo / i pulsanti "disattivati" non hanno requisiti di contrasto.
Sebbene la maggior parte dei temi offra ai propri utenti la possibilità di regolare i colori utilizzati sul sito Web, è opportuno assicurarsi che almeno i colori predefiniti (o le "tavolozze" disponibili) soddisfino il requisito minimo di contrasto. Più avanti in questa serie esamineremo la creazione di una funzione nel tema che avverte l'utente se sta selezionando i colori con contrasto insufficiente.
La British Dyslexia Association raccomanda di evitare gli sfondi bianchi puri per il testo e invece di utilizzare un colore biancastro, una crema o un tenue color pastello. Il ragionamento dietro questo è che la luminosità di una pagina bianca può "abbagliare" il lettore.
Per coloro che soffrono di sindrome da sensibilità scozzese (o sindrome di Irlen), un contrasto troppo elevato tra sfondo e testo può esacerbare sintomi come:
Questi sintomi rendono la lettura difficile e scomoda e possono causare affaticamento degli occhi, affaticamento degli occhi, sonnolenza e mal di testa.
In vista della sezione precedente, il miglior consiglio è quello di garantire un buon contrasto, ma non troppo contrasto. Poiché le preferenze variano da individuo a individuo, ciò che costituisce "troppo" dipenderà dal giudizio personale.
Un layout strutturato, con l'uso appropriato delle intestazioni, rende più facile per gli utenti comprendere le informazioni che vengono loro presentate. Gli utenti di screen reader si affidano in qualche modo a una struttura "sensibile" per aiutarli a orientarsi su una pagina.
Un modo rapido per testare questo è visualizzare il tema con CSS e JavaScript disabilitati. UN meglio il modo è usare Lynx che è un browser basato su testo. Se la struttura del tuo sito fa apparire il contenuto in modo disorganizzato, sarà difficile per gli utenti che utilizzano Lynx o altre tecnologie di assistenza leggere il tuo sito web. Poiché gli utenti che fanno affidamento su tali tecnologie non hanno i vantaggi che CSS e JavaScript apportano per favorire l'orientamento sulla pagina e il flusso dei contenuti, è importante che la sequenza di lettura corretta sia ovvia senza di essi.
Questo è abbastanza semplice da realizzare: assicurarsi che il markup HTML rifletta l'ordine visivo previsto. Questo è abbastanza naturale, e se trovi che il tuo sito web non legge bene senza CSS, probabilmente lo hai intenzionalmente deviato. Come regola generale, il tuo sito web dovrebbe seguire lo schema:
Questo è abbastanza facile da ottenere. Le regole sono semplici:
tag per intestazioni solo, non solo per applicare uno stile particolare ad un testo.
dovrebbe essere annidato dentro a
e
dentro a
. (Questo segue da (2)).Una domanda che viene spesso posta è: Il titolo del mio sito dovrebbe essere all'interno di a etichetta? Le raccomandazioni del W3C indicano che mentre ci sono alcuni casi in cui questa sarebbe una cosa valida da fare, nel contesto dei temi di WordPress, probabilmente è meglio non usare
tag per il titolo del sito. Ci sono un paio di motivi:
etichetta. Mentre questo è spesso trascurato e un po 'brutto per gli utenti visivi, è la prima cosa letta dagli screen reader. Quindi avvolgere il titolo del sito in
conferisce una prominenza ridondante agli utenti di screen reader, mentre rendere il titolo più ovvio per gli utenti vedenti può essere raggiunto senza l'uso del tag di intestazione.Indipendentemente da ciò che decidi, le intestazioni successive sulla tua pagina dovrebbero sedersi al di sotto di essa. Quindi, gli articoli in "The Loop" o i titoli delle tue pagine dovrebbero avere tag se hai usato il
tag per il titolo del tuo sito, e
tag altrimenti.
Dopo il contenuto del post, la maggior parte dei temi mostrerà i commenti del post. È naturale avere "commenti" come intestazione, poiché è una rottura logica dal contenuto, ma poiché è legata al contenuto del post, il livello di intestazione dovrebbe riflettere questo. La cosa più logica da fare è avere l'intestazione "Commenti" di un livello sotto il titolo del post.
Ecco un frammento di a single.php
:
>
Nel mio esempio ho usato un tag per il titolo del post, quindi il modello dei commenti (
comments.php
) potrebbe quindi assomigliare a qualcosa:
// ...
Alcuni utenti con lievi disabilità visive possono fare affidamento sull'ampliamento delle dimensioni dei caratteri piuttosto che sulle tecnologie di assistenza come le lenti di ingrandimento dello schermo. In considerazione di ciò, le linee guida WCAG specificano che il tuo sito non deve "interrompersi" quando il testo viene ingrandito fino al 200%. "Break" qui significa che il testo scompare, si scontra, trabocca dai suoi contenitori, o più in generale il layout del sito viene interrotto in modo che sia difficile o confusionario da leggere.
Poiché i browser moderni sono migliorati nel ridimensionamento del testo, l'utilizzo delle dimensioni relative dei caratteri non è importante come in passato (sebbene IE9 non ridimensiona le dimensioni dei caratteri definite in pixel). Indipendentemente da ciò, si consiglia comunque di utilizzare le dimensioni relative dei caratteri (percentuali, ems o rems). L'unità Rem risolve alcuni dei problemi con l'unità em e, sebbene sia stata introdotta solo con CSS3, è possibile utilizzarla in un modo compatibile con i precedenti browser. I dettagli su come implementare i relativi caratteri sono leggermente fuori portata, ma puoi saperne di più qui:
Tuttavia, il ridimensionamento del testo può portare a problemi di layout. Il testo potrebbe essere spostato fuori dallo schermo, costringendo l'utente a scorrere, o il testo potrebbe essere cancellato dal suo contenitore, potenzialmente in altro testo, rendendo illeggibili parti della pagina web. Questo dove a di risposta (o fluido) il layout può aiutare. I siti "Responsive" sono progettati per adattarsi a qualsiasi dispositivo su cui vengono visualizzati; in quanto tali usano raramente pixel fissi per altezza / larghezza o dimensione del carattere. Di conseguenza, tali siti di solito si comportano bene quando vengono cambiate le dimensioni dei caratteri: il loro layout non si interrompe.
Le linee guida WCAG raccomandano non solo che il testo possa essere ingrandito fino al 200%, ma anche che il sito web possa adattarsi alle dimensioni del testo. Il web design reattivo può essere d'aiuto perché:
Tuttavia, è importante notare che la progettazione reattiva e l'accessibilità non sono la stessa cosa: sebbene possano completarsi a vicenda, alla fine hanno obiettivi diversi. Un sito reattivo non è necessariamente accessibile e viceversa.
L'uso di tabelle come aiuti in un layout di pagina è (si spera) una cosa del passato. Ci sono anche ramificazioni relative all'accessibilità per l'uso scorretto delle tabelle. Le tabelle hanno lo scopo di rappresentare dati o informazioni e in quanto tali righe e colonne hanno un significato intrinseco e gli screen reader assumono questo quando leggono i dati.
Ad esempio, uno screen reader leggerà il numero di riga e colonna prima di leggere il contenuto della cella. Poiché la posizione della cella nelle tabelle utilizzate per scopi puramente di presentazione è irrilevante, questa informazione può essere fonte di confusione, o per lo meno irritante: l'utente finale viene informato che esiste una struttura tabellare, quando in realtà non c'è.
La maggior parte degli sviluppatori di temi non avrà bisogno di produrre tabelle (e il calendario dei post WordPress è già accessibile). Tuttavia, i plugin possono visualizzare tabelle attraverso shortcode o widget. Ci sono molte cose da sapere quando si produce il markup del tavolo:
Dove appropriato, fornire un
elemento nella parte superiore di una tabella, descrivendo ciò che mostra la tabella:
per tavolo intestazioni e per dati della tabella. le celle non dovrebbero mai essere vuote. - Fornire uno scopo per
celle, che indicano se si tratta di un'intestazione di riga o colonna: o . Sebbene lo scope sia spesso determinato dallo screen reader, non fa male essere esplicito. - Puoi usare
, e , ma non offrono vantaggi in termini di accessibilità. -
Utilizzare il titolo
attributo delle intestazioni per spiegare un'abbreviazione utilizzata nella cella:
Febbraio 2014 M T W T F S S ...
ARIA e moduli
Applicazioni Internet Rich accessibili Gli attributi (ARIA) sono utili per identificare lo scopo di una particolare parte della pagina, eventuali proprietà (ad esempio l'etichettatura di un modulo obbligatorio inserito come tale) e lo stato (ad esempio l'etichettatura di un pulsante come disabilitato). L'utilizzo di questi strumenti può aiutare le tecnologie assistive a comprendere meglio il tuo sito Web e presentare così la tua pagina in modo più chiaro all'utente finale. Guarderemo ARIA nel prossimo articolo di questa serie. Più avanti nella serie, guarderemo anche al markup del modulo corretto e al feedback accessibile.