Accessibilité (a) Règles - 5

Vidéo et audio

• Quatre principaux types de médias alternatifs : les sous-titres, les transcriptions, les descriptions audio et l'interprétation en langue des signes doivent être inclus avec les fichiers audio et multimédias. Ces alternatives doivent être basées sur :

  • Le type de média pris en charge : audio uniquement, vidéo uniquement ou vidéo avec formats audio (multimédia)
  • Que le média soit en direct ou préenregistré
  • La version et le niveau de ciblage de conformité WCAG
  • Tout besoin supplémentaire des utilisateurs liés aux médias

Formulaires

Champs

• Utilisez des éléments et des modèles HTML standard autant que possible, plutôt que de créer des composants personnalisés avec ARIA.

Non recommandé – HTML personnalisé avec ARIA

<div role="form">



<h4>
  
  
  Recommandé – HTML standard
</h4>



<pre class="brush:php;toolbar:false"><formulaire>

• Devrait ajouter des attributs de saisie semi-automatique HTML aux champs.

• Les champs de formulaire ne doivent pas produire de changements contextuels lorsqu'ils reçoivent le focus ou une entrée de l'utilisateur, sauf si l'utilisateur a été averti du comportement avant d'utiliser le composant (par exemple, un formulaire ne doit pas être automatiquement soumis lorsqu'un champ reçoit le focus ou une fois qu'un l'utilisateur ajoute du contenu au champ.)

Étiquettes

• Assurez-vous que chaque champ de formulaire possède une étiquette claire, précise et associée par programme.

Descriptions

• Les descriptions de champs ne sont pas requises pour l'accessibilité si les étiquettes ou les instructions du formulaire sont suffisamment descriptives.

• Ajoutez des descriptions de champs lorsque des informations supplémentaires sont nécessaires pour éviter les erreurs des utilisateurs. Par exemple, incluez des exigences de saisie telles que la longueur du mot de passe ou des formats de date spécifiques (par exemple, MM-JJ-AAAA).

• Utilisez l'attribut aria-describeby pour lier les descriptions de champs aux éléments de formulaire. Cela garantit que les lecteurs d'écran lisent à la fois l'étiquette et la description, améliorant ainsi la clarté pour les utilisateurs.

Erreurs

• Lorsqu'une erreur de formulaire se produit, signalez-la immédiatement. Identifiez clairement le champ dans lequel l'erreur s'est produite et fournissez un texte concis et descriptif expliquant l'erreur à l'utilisateur.

• Il existe différentes méthodes pour afficher les messages d'erreur, telles que :

  • Un modal, en ligne près de l'endroit où l'erreur s'est produite
  • Une collection d'erreurs regroupées dans un message plus grand en haut de la page

• Assurez-vous de faire attention au focus du clavier et aux options de région en direct ARIA lorsque vous annoncez des erreurs.

• Dans la mesure du possible, proposez à l'utilisateur une suggestion détaillée sur la façon de corriger l'erreur. Deux attributs sont disponibles pour informer les utilisateurs des erreurs.

  • Vous pouvez utiliser l'attribut HTML requis. Le navigateur fournira un message d'erreur générique basé sur les paramètres de validation déposés.
  • Ou vous pouvez utiliser l'attribut aria-required pour partager un message d'erreur personnalisé avec les AT. Seuls les AT recevront le message, sauf si vous ajoutez un code supplémentaire pour rendre le message visible à tous les utilisateurs.

Critères de réussite supplémentaires

Taille cible (minimum)

Aide cohérente

Authentification accessible

Entrée redondante

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!