Je ajoute actuellement une entrée de date à un formulaire. J'ai une entrée «Date de début» et «Date de fin», mais vous souhaitez uniquement utiliser une seule étiquette («dates») pour les deux entrées. p>
est-il possible de faire cela? Quelles sont les préoccupations d'accessibilité? P>
Ma pensée actuelle consiste à afficher une étiquette «dates» qui est affichée alors deux étiquettes cachées pour chaque entrée pour les lecteurs d'écran, etc. Est-ce la voie à suivre? Y a-t-il des exemples de grands sites Web qui font ce genre de chose (sites Web du gouvernement si possible)? P>
Il s'agit d'un projet qui peut être utilisé par une agence gouvernementale afin qu'il existe des règles strictes à ce sujet conformément à l'accessibilité. p>
3 Réponses :
Le problème ici est que vous ne pouvez spécifier qu'un pour code> pour chaque étiquette. Je l'imaginerais, pour des raisons d'accessibilité, il serait préférable de montrer deux étiquettes code> code> un pour chaque date. De cette manière, toute personne utilisant un lecteur d'écran, etc. obtiendra une étiquette valide pour chaque entrée.
<label for="x">x name</label><input name="x"/>
<label for="y">y name</label><input name="y"/>
Vous suggérez-vous d'utiliser des étiquettes cachées qui ne sont que pour les lecteurs d'écran?
Pas sûr à 100% des recommandations sur les étiquettes cachées. Je ne serais pas surpris si certains lecteurs ne liraient pas les valeurs cachées, je suppose que cela dépendrait de votre définition de cachée aussi!
C'est l'approche la plus accessible et conviviale et évite de créer le problème en premier lieu. Il est conceptuellement simple et compréhensible, ce qui est également une caractéristique d'accessibilité importante. Les personnes ayant des difficultés cognitives doivent avoir une association simple et compréhensible entre un texte qui explique l'entrée attendue et un contrôle pour l'entrée réelle. Pour cette raison, les étiquettes devraient pas i> être cachée dans le rendu visuel.
Je pense que votre meilleur choix serait d'inclure une étiquette à chaque entrée. Ensuite, pour l'étiquette que vous ne voulez pas afficher sur la page peut simplement être définie sur la page en utilisant CSS via
.hide { position: absolute; left: -9999em; }
Affichage: Aucun CODE> serait meilleur que
Position: absolu code>?
Vraiment? C'est une nouvelle pour moi. Avez-vous des exemples?
@AvreAgemarcus - Vous allez ici: CSS- Tricks.com/places-Its-tempter-to-Utilisation-Display-none-but-d Ont
Le lecteur (ou la personne utilisant le lecteur) serait confus si vous aviez des éléments montrés de manière dynamique. Comme il serait lu tous les éléments cachés s'ils étaient applicables ou non.
Wow. Merci, suppose que je pourrais avoir besoin de repenser cela un peu.
Je vais ajouter ce lien supplémentaire comme référence pour d'autres: alistatapart.com/article/now- vous-voyez-moi
N'est-ce pas le point d'affichage: aucun; Pour le cacher? Sûrement si vous ne voulez pas que la personne ait vue de le voir, vous ne voulez pas qu'un lecteur d'écran le lise non plus. Cela semble être un dépassement trop nécessaire dans l'accessibilité de ne pas cacher correctement quelque chose que vous voulez I> caché, car ... vous ne voulez pas cela caché pour certaines personnes? Ça n'a aucun sens.
Dans ce cas, je pense que la meilleure balise serait d'envelopper les entrées dans un code> code>, d'utiliser un violon ici p> Voir aussi: WCAG 2, H71: Fournir une description pour les groupes de commandes de formulaire à l'aide de champs et des éléments de légende p> p> légende code> pour "dates", utilisez
étiquettes Code> pour les deux
entrées CODE> et masquez les étiquettes:
Comment définissez-vous 'usage'? Voulez-vous dire que cliquer sur l'étiquette doit concentrer les deux champs (comme avec l'attribut
pour code>)?
Eh bien, l'attribut pour permettre à autoriser la technologie d'assistance à informer l'utilisateur de l'entrée correcte, etc.