Share
C'est le dernier principe que nous allons examiner. De manière générale, il est indiqué que le contenu et la navigation du site doivent être compréhensibles. Bien que la responsabilité de la mise en œuvre de beaucoup de ces recommandations incombe à l'utilisateur final du plugin ou du thème (ou à quiconque publie le contenu), il existe des recommandations que les développeurs de ces plugins et de ces thèmes peuvent implémenter..
La première directive indique que le contenu doit être "lisible et compréhensible". De nombreuses recommandations concernent le niveau de lecture du contenu et l'utilisation de mots inhabituels, d'abréviations et d'acronymes, dont aucun ne concerne les développeurs..
Une recommandation que nous pouvons mettre en œuvre est que le langage humain de la page Web puisse être identifié par programme. Pour ce faire, la langue doit être spécifiée sur le élément, via le lang attribut. De plus le dir Cet attribut doit être utilisé pour indiquer si le contenu est de droite à gauche..
WordPress rend cela facile en fournissant language_attributes (), qui affiche les attributs requis. dans le header.php de votre thème:
>
le language_attributes () function définit la langue du site et, si nécessaire, la direction, et filtre la sortie, permettant ainsi aux plugins (par exemple, les plugins multilingues) de modifier l'attribut comme il convient.
La deuxième directive stipule qu'un site Web doit être présenté et se comporter de manière prévisible. Un grand nombre des recommandations peuvent être remplies en s'assurant que la balise HTML du thème est bien structurée et logique. À cela s’ajoutent de nombreuses recommandations "ne pas faire" contre les modifications qui perturbent le comportement naturel et logique d’une page Web..
Nous avons mentionné ne pas utiliser Tabindex dans le quatrième article de cette série ("exploitable"). Cette recommandation s'appuie sur cela pour indiquer que lorsqu'un élément reçoit le focus, cela ne doit pas être considéré comme un déclencheur de certains changements d'état de la page..
Par exemple, un bouton de formulaire recevant le focus ne devrait pas entraîner l'envoi de ce formulaire, et un lien recevant le focus ne devrait pas provoquer l'activation de ce lien. C'est ne pas pour indiquer que les info-bulles ou, dans le cas des menus de navigation, les sous-menus ne doivent pas apparaître lorsque l'élément approprié est activé. Ces exemples ne constituent pas un changement d'état. En gros, vous pouvez assimiler les idées d’un élément recevant le focus et d’un élément survolé.
Vous devriez éviter de retirer le focus d'un élément qui le reçoit. Par exemple, vous ne devriez jamais faire quelque chose comme ce qui suit:
Accentsconagua
$ ('a'). on ('focus', function () $ (this) .blur (););Par défaut, les seuls formulaires pertinents pour les développeurs de thèmes sont les formulaires de connexion / enregistrement, de recherche et de commentaire. Parmi ceux-ci, seuls les deux derniers font l'objet d'une attention particulière de la part du développeur du thème. Comme les formulaires de recherche ne génèrent jamais d’erreur, nous nous intéresserons dans cette section aux formulaires de commentaires..
WordPress fait un très bon travail en informant les utilisateurs d'une erreur et en les informant exactement de la nature de cette erreur. Cependant, il le fait en permettant aux utilisateurs de quitter la page d'origine et en leur présentant une page d'erreur 'impasse'.
Si les utilisateurs reviennent à la page d'origine, le formulaire aura perdu le focus et devra le retrouver. Une meilleure solution serait d’empêcher les utilisateurs de soumettre le formulaire tant qu’ils n’ont pas correctement rempli le formulaire. Cependant, pour ce faire, il est essentiel de faire comprendre aux utilisateurs que la valeur entrée n’est pas valide, sinon vous les aurez piégés..
Il existe de nombreux scripts de validation côté client, et il est également très facile de créer votre propre script de validation simple. Ce qui est important c'est:
role = "alerte".Voici un exemple simple, basé sur le propre exemple de validation de formulaire accessible de WebAIM (que je vous encourage à lire), qui ajoute un message d'erreur si le champ du nom est vide..
jQuery (document) .ready (fonction ($) $ ('# auteur'). on ('flou', fonction (e) var valeur = $ (ceci) .val (); if (! valeur) if ($ ('# author-error'). length> 0) $ ('# author-error'). remove (); $ ('') .insertAfter ($ (' # auteur ')) .text (' Erreur de champ de nom: indiquez un nom '); else if ($ ('# auteur-erreur'). longueur> 0) $ ('# auteur-erreur'). remove (); ); );L'exemple WebAIM empêche également les utilisateurs de laisser le champ invalide et les renvoie au champ pour corriger l'erreur. Si vous faites cela, je vous recommanderais ne pas renvoyer l'utilisateur au champ si la valeur est vide, sinon vous frustrerez les utilisateurs qui ont accidentellement donné le focus du champ, mais n'ont aucune intention de soumettre le formulaire.
Comme indiqué précédemment dans cette série, vous ne devez pas vous fier uniquement à la couleur ou à la position pour transmettre un message. Dans ce contexte, les messages d’erreur devraient clairement provenir du texte, de même que le ou les champs auxquels ils se rapportent..
Les thèmes ne devraient utiliser que comment_form () pour afficher les formulaires de commentaires, ce qui permet de gérer les étiquettes de manière accessible. De même, le formulaire de recherche par défaut ne nécessite pas de travail supplémentaire. Toutefois, lors de la personnalisation ou du style de ces formulaires, vous devez:
Les étiquettes doivent être visibles à tout moment. Concrètement, cela signifie que les espaces réservés ne constituent pas une étiquette et ne doivent pas être utilisés comme recherche. Il y a plusieurs raisons à cela:
Si un champ de formulaire nécessite des instructions supplémentaires, celles-ci peuvent être fournies après le champ mais toujours explicitement liées à celui-ci à l'aide de l'option aria décrit par attribut. Le contenu de l'élément référencé par cet attribut est lu après l'étiquette du champ.
Par exemple, sur le site Web du W3C:
Cependant, vous devez savoir qu’il existe un support incohérent entre lecteurs d’écran..
Les champs obligatoires doivent être marqués comme tels avec le aria-required = "true" attribut. Le formulaire de commentaire WordPress par défaut tel que produit par comment_form () gère déjà cela, donc il n'y a aucune action que vous avoir besoin prendre ici. Cependant, vous devez être conscient de cela si vous choisissez de personnaliser les formulaires de commentaires..
Cet article conclut notre guide de développement de thème approximatif des principes d’accessibilité du W3C et de leur mise en œuvre. Dans le dernier article de cette série, nous examinerons quelques moyens simples d'aller encore plus loin et d'encourager activement et d'aider l'utilisateur final de notre thème (ou plugin) à produire un contenu accessible..
