Ce principe stipule que tout le contenu doit être dans un format (ou disponible à la demande dans un format) qui soit facilement perceptible par l'utilisateur. Autrement dit, vos sites Web devraient être conçus de manière à ce que tout le monde puisse "lire" le contenu, quel que soit son handicap. De nombreux utilisateurs handicapés utiliseront les technologies d'assistance. par exemple, les malvoyants peuvent utiliser un lecteur d'écran, qui lit ce qui apparaît à l'écran, ou un convertisseur de texte en braille. Le but est alors de faciliter ces technologies d'assistance.
S'il vous plaît rappelez-vous que les lignes directrices ici sont ne pas exhaustif, il est donc recommandé de toujours consulter les consignes d’accessibilité au contenu Web.
C’est peut-être le conseil le plus courant pour améliorer l’accessibilité. Si votre site contient tout les images sont ignorées par les lecteurs d'écran sauf si vous utilisez le alt
étiquette.
Notez que la description alt peut ne pas être nécessairement une description de l’image, mais plutôt de ce que l’image essaie de faire. transmettre. La balise alt dit en mots ce que vous essayez de dire avec l'image.
Bien que ce conseil s'adresse principalement aux éditeurs, je le soulève ici car les développeurs de thèmes fournissent souvent un logo au lieu d'un texte pour indiquer le nom du site Web ou de la société. Dans ce cas, il vaut probablement mieux utiliser le nom du site (get_bloginfo ('nom')
) comme description alternative:
écho ''. get_bloginfo ('nom'). '
';
Les balises Alt doivent ne pas être utilisé pour des images purement décoratives, sinon vous forcez essentiellement l'utilisateur à passer au crible des informations excessives et inutiles.
Si votre plugin crée un formulaire, vous aurez peut-être besoin d'une confirmation indiquant que l'accès est fait par une personne plutôt que par un ordinateur. Si vous décidez de fournir à l'utilisateur une image ou un clip audio, qu'il doit ensuite interpréter, vous devez l'expliquer, sous forme de texte, et fournir une autre forme de CAPTCHA pour prendre en charge différents handicaps..
Cette directive s’appliquera largement aux développeurs de plug-ins, mais peut également s’appliquer à des thèmes. Si la couleur, la forme ou la position sont utilisées pour transmettre une signification qui ne se distingue pas du texte, cette signification est perdue pour les utilisateurs daltoniens ou aveugles..
Par exemple, un exemple typique pourrait être les boutons de formulaire de contact reposant uniquement sur une icône de la police de police populaire Font Awesome:
Le but de ces boutons est évident pour un utilisateur voyant, mais pour ceux qui utilisent des lecteurs d’écran, rien n’indique ce que font les boutons. Si, pour des raisons de conception, vous souhaitez éviter d’utiliser du texte, vous devez spécifier l’étiquette à l’aide de la touche aria-label
attribut.
Ceci n'est qu'un exemple du protocole ARIA, que nous verrons plus en détail dans le prochain article..
C'est une exigence presque évidente. Même pour une personne bien voyante, un site Web avec un faible contraste entre le texte et l'arrière-plan est difficile à lire et peut causer une fatigue oculaire. Pour les malvoyants, un contraste encore plus important est nécessaire, raison pour laquelle le WCAG stipule que le contraste et la couleur du texte doivent avoir un rapport de contraste de 4,5: 1..
La signification et la signification de ce rapport ne sont pas immédiatement évidentes, mais de nombreux outils vous aident à vérifier le rapport:
Le texte plus volumineux a une exigence inférieure de 3: 1, et les logos, le texte qui est purement décoratif ou non visible, et le texte / boutons "désactivés" ne nécessitent pas de contraste.
Bien que la plupart des thèmes offrent à leurs utilisateurs la possibilité d'ajuster les couleurs utilisées sur le site Web, il est judicieux de s'assurer qu'au moins les couleurs par défaut (ou les «palettes» disponibles) respectent l'exigence de contraste minimale. Plus tard dans cette série, nous examinerons l’intégration d’une fonctionnalité dans votre thème qui avertit l’utilisateur s’il sélectionne des couleurs avec un contraste insuffisant..
La British Dyslexia Association recommande d’éviter les fonds sur fond blanc pour le texte et d’utiliser plutôt une couleur blanc cassé, crème ou pastel. Le raisonnement derrière cela est que la luminosité d'une page blanche peut "éblouir" le lecteur.
Pour ceux qui souffrent du syndrome de sensibilité Scotopic (ou syndrome d'Irlen), un contraste trop élevé entre l'arrière-plan et le texte peut exacerber des symptômes tels que:
Ces symptômes rendent la lecture difficile et inconfortable et peuvent causer de la fatigue oculaire, de la fatigue oculaire, de la somnolence et des maux de tête..
Au vu de la section précédente, le meilleur conseil est d’assurer un bon contraste, mais pas trop contraste. Comme les préférences varient d'un individu à l'autre, ce qui constitue "trop" sera dû à un jugement personnel.
Une mise en page structurée, avec une utilisation appropriée des en-têtes, permet aux utilisateurs de comprendre plus facilement les informations qui leur sont présentées. Les utilisateurs de lecteurs d'écran s'appuient quelque peu sur une structure «sensible» pour les aider à se repérer dans une page..
Un moyen rapide de tester cela consiste à afficher votre thème avec CSS et JavaScript désactivés. UNE meilleur manière est d’utiliser Lynx qui est un navigateur textuel. Si la structure de votre site entraîne une désorganisation du contenu, il sera difficile pour les utilisateurs de Lynx ou d'autres technologies d'assistance de lire votre site Web. Les utilisateurs de ces technologies ne bénéficiant pas des avantages que CSS et JavaScript apportent à l'orientation de la page et du flux de contenu, il est important que la séquence de lecture correcte soit évidente sans eux..
C'est assez simple à réaliser: assurez-vous que le balisage HTML reflète l'ordre visuel prévu. Ceci est tout à fait naturel, et si vous constatez que votre site Web ne lit pas bien sans CSS, vous l'avez probablement volontairement dévié. En règle générale, votre site Web devrait suivre le modèle:
Celui-ci est assez facile à obtenir. Les règles sont simples:
étiquettes pour en-têtes seulement-pas seulement appliquer un style particulier à un texte.
devrait être imbriqué dans un
et
à l'intérieur d'un
. (Cela découle de (2)).Une question qui est souvent posée est: Le titre de mon site doit-il figurer dans un étiquette? Les recommandations du W3C indiquent que même si, dans certains cas, il serait judicieux de le faire, dans le contexte des thèmes WordPress, il est probablement préférable de ne pas utiliser
balises pour le titre du site. Il y a plusieurs raisons:
étiquette. Bien que cela soit souvent négligé et un peu moche pour les utilisateurs visuels, c'est la première chose que lisent les lecteurs d'écran. Par conséquent, envelopper le titre du site dans
donne une visibilité redondante aux utilisateurs de lecteurs d'écran, tout en rendant le titre plus évident pour les utilisateurs voyants peut être obtenu sans utiliser la balise d'en-tête.Indépendamment de ce que vous décidez, les en-têtes suivants sur votre page doivent apparaître en dessous. Ainsi, les articles de "The Loop" ou les titres de vos pages doivent avoir balises si vous avez utilisé le
balise pour le titre de votre site, et
balises autrement.
Après le contenu de l'article, la plupart des thèmes affichent les commentaires de l'article. Il est naturel que l'en-tête "Commentaires" corresponde à une logique, mais comme il est lié au contenu de l'article, le niveau de l'en-tête doit en tenir compte. La chose la plus logique à faire est de placer l'en-tête "Commentaires" à un niveau sous le titre de l'article..
Voici un extrait d'un single.php
:
>
Dans mon exemple, j'ai utilisé un balise pour le titre de l'article, donc le modèle de commentaires (
commentaires.php
) pourrait alors ressembler à quelque chose comme:
//…
Certains utilisateurs ayant une déficience visuelle légère peuvent compter sur l’agrandissement de la taille des polices plutôt que sur des technologies d’aide telles que les loupes d’écran. Dans cette optique, les directives WCAG spécifient que votre site ne doit pas "casser" lorsque le texte est agrandi jusqu'à 200%. "Pause" signifie ici que le texte disparaît, entre en collision, déborde de ses conteneurs ou, plus généralement, que la présentation du site est perturbée, ce qui rend sa lecture difficile ou déroutante..
Étant donné que les navigateurs modernes maîtrisent mieux le texte, l'utilisation de tailles de police relatives n'est plus aussi importante qu'auparavant (bien que IE9 ne redimensionne pas les tailles de police définies en pixels). Quoi qu'il en soit, il est toujours recommandé d'utiliser des tailles de police relatives (pourcentages, ems ou rems). L'unité rem résout certains des problèmes liés à l'unité em. Bien que le système ait été introduit uniquement avec CSS3, vous pouvez l'utiliser de manière rétrocompatible avec les anciens navigateurs. Les détails sur la manière d'implémenter les polices relatives sont légèrement hors de portée, mais vous pouvez en savoir plus ici:
Cependant, le redimensionnement du texte peut entraîner des problèmes de mise en page. Le texte peut être déplacé hors de l'écran, ce qui oblige l'utilisateur à faire défiler l'écran, ou le texte peut couler de son conteneur, éventuellement dans un autre texte, rendant ainsi des parties de la page Web illisibles. Ce où un sensible (ou fluide) mise en page peut aider. Les sites "réactifs" sont conçus pour s'adapter à tout appareil sur lequel ils sont visualisés; En tant que tels, ils utilisent rarement des pixels fixes pour la hauteur / largeur ou la taille de la police. Par conséquent, ces sites se comportent généralement bien lorsque la taille des polices est modifiée: leur mise en page ne se casse pas..
Les directives du WCAG recommandent non seulement que le texte puisse être agrandi de 200% maximum, mais également que le site Web puisse accueillir une taille de texte accrue. Une conception Web réactive peut aider cela parce que:
Cependant, il est important de noter que conception réactive et accessibilité ne sont pas la même chose: bien qu'elles puissent se compléter, elles ont finalement des objectifs différents. Un site responsive n'est pas nécessairement accessible, et inversement.
L'utilisation de tableaux comme aides dans la mise en page est (espérons-le) une chose du passé. Il y a aussi des ramifications liées à l'accessibilité des tables de mauvaise utilisation. Les tableaux sont conçus pour représenter des données ou des informations, et en tant que telles lignes et colonnes ont une signification inhérente, et les lecteurs d’écran le supposent lors de la lecture de données..
Un lecteur d’écran, par exemple, lira le numéro de la ligne et de la colonne avant de lire le contenu de la cellule. Étant donné que la position des cellules dans les tableaux utilisés à des fins purement de présentation est sans importance, ces informations peuvent être source de confusion ou être tout au moins irritantes..
La plupart des développeurs de thèmes n'auront pas besoin de produire de tableaux (et le calendrier des publications WordPress est déjà accessible). Cependant, les plugins peuvent afficher des tables via des codes courts ou des widgets. Il y a un certain nombre d'éléments à prendre en compte lors de la production de la majoration de table:
Le cas échéant, fournissez un
élément en haut d'un tableau, décrivant ce que le tableau montre:
pour la table en-têtes et pour données de table. les cellules ne doivent jamais être vides. - Fournir une portée pour
cellules, indiquant s'il s'agit d'un en-tête de ligne ou de colonne: ou . Bien que la portée soit souvent déterminée par le lecteur d'écran, le fait d'être explicite ne fait pas de mal. - Vous pouvez utiliser
, et , mais ils n'offrent aucun avantage en termes d'accessibilité. -
Utilisez le Titre
attribut d'en-tête pour expliquer une abréviation utilisée dans la cellule:
Février 2014 M T W T F S S …
ARIA & Formulaires
Applications Internet riches accessibles Les attributs (ARIA) sont utiles pour identifier l'objectif d'une partie particulière de la page, toutes les propriétés (par exemple, l'étiquetage d'une entrée de formulaire requise comme telle) et l'état (par exemple, l'étiquetage d'un bouton comme étant désactivé). Leur utilisation peut aider les technologies d'assistance à mieux comprendre votre site Web et à présenter votre page plus clairement à l'utilisateur final. Nous examinerons ARIA dans le prochain article de cette série. Plus tard dans la série, nous examinerons également le bon marquage des formulaires et des commentaires accessibles..