Maison > Article > interface Web > Comprendre l'accessibilité : partie 5
Comprendre l'accessibilité : partie 5
- PHPzoriginal
- 2023-08-31 20:33:02847parcourir
C'est le dernier principe dont nous souhaitons discuter. D'une manière générale, il stipule que le contenu et la navigation d'un site Web doivent être faciles à comprendre. Bien que la responsabilité de la mise en œuvre d'un grand nombre de ces recommandations incombe à « l'utilisateur final » du plugin ou du thème (ou à celui qui publie le contenu), certaines recommandations peuvent être mises en œuvre par les développeurs de ces plugins et thèmes.
Lisible (3.1)
La première ligne directrice stipule que le contenu doit être « lisible et facile à comprendre ». De nombreuses suggestions concernent le niveau de lecture du contenu et l’utilisation de mots, d’abréviations et d’acronymes inhabituels, qui ne sont pas pertinents pour les développeurs.
Une suggestion que nous pouvons mettre en œuvre est que le langage humain des pages Web soit identifiable par programme. Pour cela, indiquez si le contenu est de droite à gauche via l'attribut lang 属性在 元素上指定语言。此外，应使用 dir.
WordPress propulsé par language_attributes() 来简化此操作，它会打印所需的属性。在主题的 header.php dans :
<html <?php language_attributes(); ?>>
language_attributes() La fonction définit la langue et, si nécessaire, l'orientation du site Web, et filtre la sortie, permettant aux plugins (par exemple les plugins multilingues) de modifier les propriétés selon leurs besoins.
Prévisible (3.2)
La deuxième directive stipule que les sites Web doivent avoir une apparence et un comportement prévisibles. La plupart des recommandations peuvent être mises en œuvre en veillant à ce que le balisage HTML de votre thème soit bien structuré et logique. Au-delà de cela, il existe de nombreux conseils à ne pas faire : des recommandations contre les modifications qui brisent le comportement naturel et logique de la page Web.
Comportement de concentration
Nous avons abordé la non-utilisation de tabindex dans le quatrième article de cette série (« Actionable »). Cette recommandation s'appuie sur l'affirmation selon laquelle lorsqu'un élément obtient le focus, il ne doit pas être considéré comme déclenchant un changement dans l'état de la page.
Par exemple, un bouton de formulaire recevant le focus ne devrait pas entraîner la soumission du formulaire, et un lien recevant le focus ne devrait pas entraîner l'activation du lien. Cela ne veut pas dire que les info-bulles ou les sous-menus des menus de navigation ne doivent pas apparaître lorsque l'élément correspondant reçoit le focus. Ces exemples ne constituent pas un changement de statut. En gros, vous pouvez assimiler l’élément sur lequel le focus est placé avec l’élément survolé.
Ne bloquez pas la mise au point
Vous devez éviter de supprimer le focus de l'élément qui reçoit le focus. Par exemple, vous ne devriez jamais faire ce qui suit :
$('a').on('focus',function(){ $(this).blur(); });
Aider l'utilisateur lorsque sa saisie est requise (3.3)
Assurez-vous d'identifier les erreurs
Par défaut, les seuls formulaires pertinents pour les développeurs de thèmes sont les formulaires de connexion/inscription, de recherche et de commentaires. Parmi ceux-ci, les développeurs de thèmes se concentrent généralement uniquement sur les deux derniers. Puisque la recherche d’un formulaire n’aboutit jamais à une « erreur », nous concentrons cette section sur les formulaires de commentaires.
WordPress fait un excellent travail en informant les utilisateurs des erreurs et en leur indiquant exactement de quoi il s'agit. Cependant, il le fait en permettant aux utilisateurs de s'éloigner de la page d'origine et en leur présentant une page d'erreur « sans issue ».
Si l'utilisateur revient à la page d'origine, le formulaire perdra le focus et il devra le retrouver. Une meilleure solution serait d’empêcher l’utilisateur de soumettre le formulaire avant de l’avoir rempli correctement. Cependant, ce faisant, vous devez communiquer à l'utilisateur que la valeur saisie n'est pas valide, sinon vous l'aurez effectivement piégé.
Il existe des tonnes de scripts de validation côté client disponibles, et il est très facile de créer votre propre script de validation simple. L'important c'est :
- Le message d'erreur qui apparaît lorsque l'utilisateur quitte un champ avec une valeur invalide (ou tente de soumettre un formulaire) doit indiquer qu'une erreur existe et où elle se trouve (c'est-à-dire le champ d'identification).
- Les messages d'erreur doivent être identifiés comme des alertes à l'aide de l'attribut ARIA :
role="alert". - Le cas échéant, les messages d'erreur doivent informer l'utilisateur aussi clairement que possible pourquoi la valeur saisie n'a pas été acceptée.
Il s'agit d'un exemple simple, basé sur l'exemple de validation de formulaire accessible de WebAIM (que je vous encourage à lire), qui ajoute un message d'erreur si le champ de nom est vide.
jQuery(document).ready(function($) {
$('#author').on( 'blur', function( e ){
var value = $(this).val();
if( !value ){
if( $('#author-error').length > 0 ){
$('#author-error').remove();
}
$( '<p id="author-error" class="alert alert-error" role="alert"></p>' )
.insertAfter( $('#author') )
.text( 'Name field error: Please provide a name' );
}else if( $('#author-error').length > 0 ){
$('#author-error').remove();
}
});
});
L'exemple WebAIM empêche également les utilisateurs d'invalider les champs et les renvoie aux champs pour corriger les erreurs. Si vous faites cela, je vous recommande de ne pas renvoyer l'utilisateur au champ lorsque la valeur est vide, sinon vous frustrez les utilisateurs qui donnent accidentellement le focus au champ sans avoir l'intention de soumettre le formulaire.
Comme indiqué plus tôt dans cette série, vous ne devez pas vous fier uniquement à la couleur ou au placement pour transmettre un sens. Dans ce cas, les messages d'erreur doivent être évidents dans le texte, tout comme leurs champs associés.
Fournir des balises
Les thèmes ne peuvent utiliser que comment_form() pour afficher les formulaires de commentaires, et cela gère les balises de manière accessible. De même, le formulaire de recherche par défaut ne nécessite aucun travail supplémentaire. Cependant, lors de la personnalisation ou de la conception de ces formulaires, vous devez :
Assurez-vous que les étiquettes sont toujours visibles
L'étiquette doit être visible à tout moment. Plus précisément, cela signifie que les espaces réservés ne constituent pas des balises et ne doivent pas être utilisés comme recherches. Il y a plusieurs raisons à cela :
- 对屏幕阅读器的支持不一致。
- 占位符通常采用柔和的颜色，可能难以阅读。
- 由于当字段获得焦点时占位符会消失，因此可能会给有认知障碍的人带来可用性问题。
在适当的情况下提供进一步说明
如果表单字段需要进一步的说明，可以在字段之后提供这些说明，但仍然使用 aria-scribedby 属性显式链接到该字段。该属性引用的元素的内容在field的标签后面读出。
以 W3C 网站为例：
<form>
<label for="fname">First name</label>
<input name="" type="text" id="fname" aria-describedby="fname-description">
<p id="fname-description">A bit of instructions for this field linked with aria-describedby. </p>
</form>
但是，您应该注意，屏幕阅读器对此的支持并不一致。
确定必填字段
必填字段应使用 aria-required="true" 属性进行标记。由 comment_form() 生成的默认 WordPress 评论表单已处理此问题，因此您需要在此处执行任何操作。但是，如果您选择自定义评论表单，则应该注意这一点。
结论
本文总结了我们关于 W3C 可访问性原则的粗略主题开发人员指南以及如何实施这些原则。在本系列的最后一篇文章中，我们将研究一些简单的方法，以进一步推动并积极鼓励和帮助我们的主题（或插件）的最终用户生成可访问的内容。
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!