Associer des libellés aux champs de saisie, c'est facile !Mais qu'en est-il des champs obligatoires, des messages d'erreur et du focus clavier ?
Dans cette série d'articles en trois parties, nous allons apprendre à créer des formulaires accessibles à l'aide de HTML5, WAI-ARIA et jQuery Validation. Notre stratégie consistera tout d'abord à tester la validation avec HTML5 dans les navigateurs récents prenant en charge ces attributs de formulaire, puis nous utiliserons WAI-ARIA, compatible avec les lecteurs d'écran les plus récents, et enfin, pour les utilisateurs qui ne peuvent tout simplement pas mettre à jour leur navigateur, nous ajouterons le plugin jQuery Validation afin que même les utilisateurs d'IE6 puissent valider leurs formulaires de manière accessible.
Notions de base
Les principes fondamentaux de l'accessibilité des formulaires sont parfois négligés ; je vais donc les rappeler ici.
Chaque. Champ. Doit. Avoir. Une. Étiquette.
C'est assez facile à retenir, non ? La seule méthode infaillible pour garantir l'accessibilité d'un champ de formulaire consiste à lui associer explicitement une étiquette à l'aide des attributs «for» et «id».
Pour vérifier rapidement si un libellé est explicite, il suffit de cliquer avec la souris sur le texte du libellé : si le focus passe alors sur le champ de saisie, cela signifie qu’ils sont liés. Cela agrandit la zone de clic et aide vraiment tout le monde à cocher ces minuscules cases à cocher et boutons radio.
Technique relative aux WCAG 2.0 – Critères de succès 1.1.1 (Contenu non textuel), 1.3.1 (Informations et relations), 3.3.2 (Étiquettes ou instructions) et 4.1.2 (Nom, rôle, valeur)
H44 : Utilisation des éléments « label » pour associer des libellés à des contrôles de formulaire
HTML
<label for="fname">First Name *</label> <input required type="text" name="fname" id="fname">
Résultat
Faites-le pour chaque champ ! Si vous ne souhaitez pas que le libellé s'affiche, masquez-le hors de l'écran à l'aide de CSS.
Les boutons radio et les cases à cocher nécessitent un élément « fieldset » et une légende
HTML
<fieldset> <legend>Gender *</legend> <input type="radio" name="gender" value="male" id="male"> <label for="male">Male</label> <input type="radio" name="gender" value="female" id="female"> <label for="female">Female</label> </fieldset>
Résultat
Technique relative aux WCAG 2.0 – Critères de succès 1.3.1 (Informations et relations) et 3.3.2 (Libellés ou instructions)
Toutes les instructions sont-elles données à voix haute ?
Les formats de saisie sont-ils prononcés ? Avez-vous indiqué le format correct pour les dates, les numéros de téléphone, etc. ? Encore une fois, la meilleure façon de transmettre les instructions du formulaire aux lecteurs d'écran est de les inclure dans le libellé.
HTML
<label for="bday">Birthday * MM/DD/YYYY</label> <input type="text" name="bday" id="bday">
Résultat
Technique relative aux WCAG 2.0 – Critères de succès 3.3.2 (Libellés ou instructions) et 3.3.5 (Aide)
G89 : Indication du format de données attendu et d'un exemple
Champs obligatoires
Personne n'aime remplir des formulaires ! Si vous souhaitez obtenir des données utiles sans faire fuir vos utilisateurs, ne demandez que le strict minimum de champs nécessaires. Indiquez qu'un champ est obligatoire en ajoutant un * rouge dans le libellé ou en ajoutant la mention « obligatoire ».
Technique relative aux WCAG 2.0 – Critère de succès 3.3.2 (Libellés ou instructions)
H90 : Indiquer les champs obligatoires d'un formulaire à l'aide d'une étiquette ou d'une légende
Messages d'erreur
Aidez les utilisateurs en leur fournissant des messages d'erreur utiles et des suggestions pour y remédier. En plaçant l'erreur dans une étiquette, le lecteur d'écran lira chaque erreur à voix haute lorsque l'utilisateur se déplacera d'un champ à l'autre à l'aide de la touche Tab.
Focalisation du clavier
L'une des principales erreurs commises avec les formulaires consiste à ne pas déplacer le focus du clavier sur le champ comportant une erreur ou sur la liste des messages d'erreur. Les utilisateurs de technologies d'assistance ne se rendront pas compte qu'il y a un problème si le lecteur d'écran affiche un écran vide ou si leur loupe ne déplace pas le focus vers l'erreur. Lorsqu'il ne se passe rien après avoir cliqué sur le bouton « Envoyer », ils supposeront que votre formulaire ne fonctionne pas.
Techniques relatives aux WCAG 2.0 – Critères de succès 3.3.1 (Identification des erreurs), 3.3.2 (Libellés ou instructions), 3.3.3 (Suggestions en cas d'erreur) et 3.3.4 (Prévention des erreurs (juridiques, financières, liées aux données))
- G83 : Fournir des descriptions textuelles permettant d'identifier les champs obligatoires qui n'ont pas été remplis
- G85 : Fournir une description textuelle lorsque la saisie de l'utilisateur ne respecte pas le format ou les valeurs requis
- SCR18 : Mise en place d'une validation et d'alertes côté client
- SCR32 : Mise en place d'une validation côté client et ajout de messages d'erreur via le DOM
HTML5
Maintenant que vous maîtrisez les bases, ajouter la validation HTML5 et des améliorations en matière d'ergonomie est un jeu d'enfant !
Champ obligatoire
Grâce à l'attribut « required » de HTML5 et aux types d'éléments « input » de HTML5, vous pouvez confier au développeur du navigateur la responsabilité de la validation accessible des formulaires.
HTML
<label for="lname">Last Name *</label> <input type="text" name="lname" id="lname" required> <input type="checkbox" name="tos" id="tos" required> <label for="tos">* I agree to terms of service.</label>
Bien sûr, l'attribut « required » ne fonctionne pas sur tous les navigateurs ; Safari et Mobile Safari sont les deux sur lesquels son absence me dérange le plus. Pour en savoir plus sur la prise en charge des formulaires HTML5 par les navigateurs, rendez-vous sur « L'état actuel des formulaires HTML5 – L'attribut required » par Chris Coyier (@chriscoyier) de CSS-Tricks . Cette ressource est un peu dépassée, car la prise en charge s'est améliorée dans de nombreux navigateurs.
Types de données d'entrée
Les types d'entrée HTML5 améliorent considérablement la convivialité et l'accessibilité des formulaires sur les appareils mobiles. Sous iOS (iPhone, iPad et iPod Touch), la plupart des types d'entrée affichent un clavier adapté à ce format de données. Il est très rare de voir des formulaires en situation réelle tirer parti de ces améliorations simples en matière de convivialité. Par défaut, le type d'entrée « input type=text » affiche le clavier alphabétique standard. Si vous devez saisir des chiffres, le symbole @ dans une adresse e-mail ou l'extension .com d'une URL, des pressions supplémentaires sont nécessaires.
| Type | type=texte | type=e-mail | type=tel |
|---|---|---|---|
| HTML |
<label for="text">Text:</label> <input type="text" name="text" id="text"> |
<label for="email">Email:</label> <input type="email" name="email" id="email" /> |
<label for="tel">Tel:</label> <input type="tel" name="tel" id="tel" /> |
| Résultat | |||
input type=date sur iPad et iPhone
HTML
<label for="date">Date:</label> <input type="date" name="date" id="date" />
Résultat
Comme ces différents claviers et ces commandes de type « spinner » sont natifs d'iOS, ils sont accessibles par défaut. Apple s'est chargé de tout pour vous.
Attribut de modèle
HTML
<label for="zip">Zip Code 5 Digits</label> <input type="number" pattern="[0-9]*" maxlength="5" min="0" name="zip" id="zip">
Résultat
L'utilisation de l'attribut « pattern » avec la valeur « pattern="[0-9]*" » pour le type de champ « number » permet d'afficher un pavé numérique à 10 touches, similaire à celui d'un téléphone. Cette solution est bien plus pratique que le clavier numérique standard, qui affiche de nombreuses touches inutiles pour une simple saisie numérique, comme un code postal. Nous avons les doigts épais et les claviers des mobiles ont des touches minuscules. Tout ce que vous pouvez faire pour agrandir la surface de clic d'une touche est vraiment utile !
HTML5Pattern.com propose des modèles d'expressions régulières pouvant être utilisés pour valider des types de données complexes. Ces modèles sont disponibles en ligne et peuvent être testés dans les navigateurs pris en charge.
Vous pouvez consulter la page consacrée à la prise en charge des éléments et attributs HTML5 dans un navigateur pour tester la prise en charge des formulaires HTML5 et parcourir tous les types de champs de saisie. Une autre excellente page pour tester la prise en charge des attributs de formulaires HTML5 est celle de documentation jQuery Mobile – Champs de saisie de texte inputs Docs. J'adore la section projet jQuery Mobile car il combine deux domaines qui me passionnent : le mobile et l’ l’accessibilité, et ce, avec brio !
Les types de données d'entrée impliquent une validation plus stricte
En ajoutant « type=email » au champ de saisie, le navigateur exigera un format de saisie plus précis afin de s'assurer que l'utilisateur saisit bien une adresse e-mail au format name@domain.com.
Si l'on ajoute l'attribut « required » à un champ de saisie de type « number », Firefox demandera des données numériques correspondant à l'attribut « pattern » spécifié.
Améliorations en matière d'ergonomie et d'accessibilité pour « Simple Mobile » et l'agrandissement de l'écran
Placer l'étiquette au-dessus du champ de saisie
En plaçant le libellé directement au-dessus du champ de saisie, vous améliorez l'expérience des utilisateurs d'appareils mobiles et de ceux qui utilisent un outil d'agrandissement d'écran. Lorsque le focus est sur le champ de saisie, le libellé ne sera plus tronqué, comme dans l'exemple ci-dessous du formulaire d'inscription à Gmail, où le libellé est placé à gauche mais apparaît tronqué lorsqu'on le consulte sur un iPhone.
Instructions de mise en forme du texte situé sous le champ de saisie à l'aide de CSS
Grâce au CSS, vous pouvez placer les instructions de mise en forme dans une balise `span` et les positionner directement sous le champ de saisie afin qu'elles restent visibles même en cas de zoom.
HTML
<p class="instructions-container"> <label for="zip">Zip Code <span class="instructions">5 Digits</span></label> <input type="number" pattern="[0-9]*" maxlength="5" min="0" name="zip" id="zip"> </p>
CSS
.instructions {
position:relative;
top: 1.6em;
display:block;
}
.instructions-container {
margin-bottom:2em;
}
.instructions-container label {
margin-bottom:-1.2em;
}
Masquer des étiquettes à l'aide du CSS
Vous souhaiterez peut-être masquer visuellement certaines étiquettes lorsque le contenu saisi est évident pour la plupart des utilisateurs voyants. Pour ce faire, nous pouvons utiliser le positionnement CSS. Le code correspondant provient du site article de WebAIM intitulé CSS en action : du contenu invisible réservé aux utilisateurs de lecteurs d'écran.
HTML
<label for="areacode">Phone * <span class="hidden">Area Code</span></label> <input required type="tel" name="areacode" id="areacode" maxlength="3"> - <label for="threedigits" class="inline"> <span class="hidden">First Three Phone Digits</span> *</label> <input required type="tel" name="threedigits" id="threedigits" maxlength="3"> - <label for="fourdigits" class="inline"> <span class="hidden">Last Four Phone Digits</span> *</label> <input required type="tel" name="fourdigits" id="fourdigits" maxlength="4">
CSS
.hidden
{position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;}
Vous pouvez désactiver le CSS pour que les libellés s'affichent.
Prochaines étapes – Ajouter WAI-ARIA
Dans le prochain article de blog, nous nous appuierons sur le travail effectué ici pour ajouter des améliorations ARIA concernant les formulaires et la validation, qui ne seront visibles que par les lecteurs d'écran.
Liens vers les trois articles de cette série :
- Validation accessible des formulaires côté client avec HTML5
- Validation accessible des formulaires côté client avec HTML5 et WAI-ARIA
- Validation accessible des formulaires côté client avec HTML5, WAI-ARIA et le plugin jQuery Validation
Des commentaires ? Des questions ?
Alors, que pensez-vous de la validation des formulaires HTML5 ? S'agit-il d'une option viable compte tenu de la prise en charge limitée de l'attribut « required » par les navigateurs ? Devons-nous continuer à nous appuyer sur la validation JavaScript, voire sur la validation côté serveur, étant donné qu'un petit pourcentage d'utilisateurs désactive JavaScript ?
N'hésite pas à me faire part de tes suggestions d'amélioration ou à me signaler les éventuelles erreurs que tu pourrais repérer.
