Table des matières
- Le problème
- La solution
- Les règles qui s'appliquent à la prévention des erreurs
- L'évaluation de conformité
- La comparaison entre les standards SGQRI et WCAG 2.0
Le problème
Comme cette règle se situe sous le principe de compréhension, il est aisé de comprendre que les personnes ayant des limitations cognitives sont celles auxquelles on a d'abord pensé.
La prévention des erreurs intéresse toutefois toutes les personnes ayant des limitations fonctionnelles, quelle qu'en soit la nature. En effet, pour diverses raisons, ces personnes rencontrent des difficultés en ce qui a trait à leurs interactions avec les contenus Web, et en particulier avec les formulaires.
La prévention des erreurs est une façon de leur faciliter la tâche en leur permettant de réussir du premier coup, et d'éviter d'avoir à refaire des opérations qui, pour plusieurs, exigent plus de temps et plus d'efforts que pour les personnes sans limitations fonctionnelles.
Retour en haut de pageLa solution
Structure des formulaires
- Les étiquettes de formulaire doivent être placées à proximité immédiate des champs de formulaire correspondants :
- au-dessus ou à gauche des zones de texte ou de liste,
- à droite ou à gauche des cases à cocher et des boutons radio.
- Pour l'utilisateur d'un logiciel de grossissement, la disposition verticale d'un formulaire (étiquettes des champs de type texte et liste déroulante placées immédiatement au-dessus du champ correspondant) est l'idéal, parce que même en plus fort grossissement, l'utilisateur pourra voir à la fois l'étiquette et le champ, dans sa zone de visualisation.
- Les longs formulaires devraient être subdivisés en section à l'aide des en-têtes de section.
- Les groupes de boutons radio et les groupes de cases à cocher doivent être identifiés à l'aide des éléments <fieldset> et <legend>. Un lecteur d'écran comme JAWS répétera alors le contenu de l'élément <legend> pour chacun des champs inclus dans le <fieldset>.
- Il est aussi possible d'imbriquer des <fieldset>, mais il est important de tenir compte que JAWS ne redonnera que la <legend> hiérarchiquement la plus proche du champ actif.
- De plus, si le <fieldset> imbriqué se termine avant la fin du <fieldset> parent, c'est la <legend> du <fieldset> imbriqué qui sera répétée pour les champs restants dans le <fieldset> parent.
- Il faut donc être prudent et bien tester le résultat avec un lecteur d'écran afin d'éviter les mauvaises surprises.
Exemple de code
<fieldset>
<legend>Indiquez votre sexe :</legend>
<p><input id="masc" name=“sexe" type="radio" checked="checked" value="masculin" /> <label for="masc">Masculin</label> </p>
<p><input id="fem" name=“sexe" type="radio" value="féminin" /> <label for="fem">Féminin</label> </p>
</fieldset>
Erreurs dans les formulaires
- Il ne faut pas signaler les erreurs dans un formulaire qu'en utilisant un indice visuel, comme un encadrement différent, une couleur différente ou un surlignement.
- Les erreurs détectées doivent être expliquées en texte, et l’attention doit y être déplacée. Il est également utile de donner, pour chaque erreur, un lien vers le champ à corriger.
- Si la validation se fait champ par champ, on peut afficher un dialogue d’alerte pour aviser l’utilisateur des erreurs détectées.
- Un lien d'aide peut être offert sur chaque page de formulaire.
- Il est de bonne pratique de donner de l'information sur le format des données attendu, ainsi que des exemples. Ces consignes doivent être intégrées aux <label> même si on leur donne une apparence différente de l'étiquette.
- Il est possible de prévoir une période de temps, dont la durée serait déclarée, et où la transaction pourrait être mise à jour ou annulée par l'utilisateur suite à la soumission du formulaire.
- On peut aussi utiliser javascript pour offrir un rapport de validation, comme dans les techniques suivantes :
Les règles qui s'appliquent à la prévention des erreurs
| SGQRI 008-01 (site Web) |
SGQRI 008-02 (doc. téléchargeable) |
SGQRI 008-03 (multimédia) |
WCAG 2.0 |
|---|---|---|---|
| 21. Tout formulaire Web doit : g) si une erreur de saisie est détectée de façon automatique, indiquer tout élément erroné et décrire l’erreur sous forme de texte avec les suggestions de correction lorsqu’elles sont connues; | 17. Tout formulaire téléchargeable à remplir à l’écran doit : e) si une erreur de saisie est détectée de façon automatique, indiquer tout élément erroné et décrire l’erreur sous forme de texte avec les suggestions de correction lorsqu’elles sont connues. | 19. Tout formulaire doit : e) si une erreur de saisie est détectée de façon automatique, indiquer tout élément erroné et décrire l’erreur sous forme de texte avec les suggestions de correction lorsqu’elles sont connues; | 3.3.1 Identification des erreurs : si une erreur de saisie est détectée automatiquement, l'élément en erreur est identifié et l'erreur est décrite à l'utilisateur sous forme de texte. (Niveau A) |
|
21. Tout formulaire Web doit : d) être conçu pour que toute étiquette soit positionnée à proximité immédiate du champ auquel elle est associée; 21. Tout formulaire Web doit : f) être conçu pour que toute étiquette décrive clairement la fonction du champ auquel elle est associée; |
17. Tout formulaire téléchargeable à remplir à l’écran doit : b) être conçu pour que toute étiquette soit positionnée à proximité immédiate du champ auquel elle est associée; 17. Tout formulaire téléchargeable à remplir à l’écran doit : d) être conçu pour que toute étiquette décrive clairement la fonction du champ auquel elle est associée; |
19. Tout formulaire doit : c) être conçu pour que toute étiquette soit positionnée à proximité immédiate du champ auquel elle est associée; 19. Tout formulaire doit : d) être conçu pour que toute étiquette décrive clairement la fonction du champ auquel elle est associée; |
3.3.2 Étiquettes ou instructions : des étiquettes sont présentées ou des instructions sont fournies quand un contenu requiert une saisie utilisateur. (Niveau A) |
| 21. Tout formulaire Web doit : g) si une erreur de saisie est détectée de façon automatique, indiquer tout élément erroné et décrire l’erreur sous forme de texte, avec les suggestions de correction lorsqu’elles sont connues. | 17. Tout formulaire téléchargeable à remplir à l’écran doit : e) si une erreur de saisie est détectée de façon automatique, indiquer tout élément erroné et décrire l’erreur sous forme de texte avec les suggestions de correction lorsqu’elles sont connues. | 19. Tout formulaire doit : e) si une erreur de saisie est détectée de façon automatique, indiquer tout élément erroné et décrire l’erreur sous forme de texte avec les suggestions de correction lorsqu’elles sont connues; | 3.3.3 Suggestion après une erreur : si une erreur de saisie est automatiquement détectée et que des suggestions de corrections sont connues, ces suggestions sont alors proposées à l'utilisateur à moins que cela puisse compromettre la sécurité ou la finalité du contenu. (Niveau AA) |
| 21. Tout formulaire Web doit : h) être conçu pour qu’une personne qui engage sa responsabilité, exerce un droit ou effectue un paiement, puisse réviser et corriger, s’il y a lieu, l'information avant de confirmer son opération. | 19. Tout formulaire doit : f) être conçu pour qu’une personne qui engage sa responsabilité, exerce un droit ou effectue un paiement, puisse réviser et corriger, s’il y a lieu, l'information avant de confirmer son opération. | 3.3.4 Prévention des erreurs (juridiques, financières, de données) : pour les pages Web qui entraînent des engagements juridiques ou des transactions financières de la part de l'utilisateur, qui modifient ou effacent des données contrôlables par l'utilisateur dans des systèmes de stockages de données, qui enregistrent les réponses de l'utilisateur à un test ou un examen, au moins l'une des conditions suivantes est vraie : (Niveau AA)
3.3.5 Aide : une aide contextuelle est disponible. (Niveau AAA) 3.3.6 Prévention des erreurs (toutes) : pour des pages Web demandant à l'utilisateur de soumettre des informations, au moins l'une des conditions suivantes est vraie : (Niveau AAA)
|
L'évaluation de conformité
| SGQRI 008-01 (site Web) |
SGQRI 008-02 (doc. téléchargeable) |
SGQRI 008-03 (multimédia) |
WCAG 2.0 Grille AccessiWeb 2.1 de Braillenet (suivre ce lien pour voir les tests rattachés à chaque critère) |
|---|---|---|---|
Si une erreur de saisie est détectée de façon automatique, indique-t-on tout élément erroné (SW-21g.1) ? Si une erreur de saisie est détectée de façon automatique, décrit-on l’erreur sous forme de texte avec les suggestions de correction lorsqu’elles sont connues (SW-21g.2) ? |
Si une erreur de saisie est détectée de façon automatique, indique-t-on tout élément erroné (DT-17e.1) ? Si une erreur de saisie est détectée de façon automatique, décrit-on l’erreur sous forme de texte avec les suggestions de correction lorsqu’elles sont connues (DT-17e.2) ? |
Si une erreur de saisie est détectée de façon automatique, indique-t-on tout élément erroné (M-19e.1) ? Si une erreur de saisie est détectée de façon automatique, décrit-on l’erreur sous forme de texte avec les suggestions de correction lorsqu’elles sont connues (M-19e.2) ? |
Critère 11.10 [Bronze] Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ? ritère 11.11 [Argent] Dans chaque formulaire, le contrôle de saisie est-il accompagné, si possible, de suggestions facilitant la correction des erreurs de saisie ? |
Tout champ
Toute étiquette est-elle positionnée à proximité immédiate du champ auquel elle est associée (SW-21d) ? Toute étiquette décrit-elle clairement la fonction du champ auquel elle est associée (SW-21f) ? |
Tout champ, comporte-t-il : Toute étiquette est-elle positionnée à proximité immédiate du champ auquel elle est associée (DT-17b) ? Toute étiquette décrit-elle clairement la fonction du champ auquel elle est associée (DT-17d) ? |
Tout champ : Toute étiquette est-elle positionnée à proximité immédiate du champ auquel elle est associée (M-19c) ? Toute étiquette décrit-elle clairement la fonction du champ auquel elle est associée (M-19d) ? |
Critère 11.1 [Bronze] Chaque champ de formulaire a-t-il une étiquette ? Critère 11.2 [Bronze] Chaque étiquette associée à un champ de formulaire est-elle pertinente ? Critère 11.4 [Bronze] Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés ? Critère 11.5 [Bronze] Dans chaque formulaire, les informations de même nature sont-elles regroupées, si nécessaire ? Critère 11.6 [Bronze] Dans chaque formulaire, chaque regroupement de champs de formulaire a-t-il une légende ? Critère 11.7 [Bronze] Dans chaque formulaire, chaque légende associée à un groupement de champs de formulaire est-elle pertinente ? |
Tout formulaire est-il conçu pour qu’une personne qui engage sa responsabilité, exerce un droit ou effectue un paiement puisse réviser et corriger, s’il y a lieu, l'information avant de confirmer son opération (SW-21h) ? |
Tout formulaire est-il conçu pour qu’une personne qui engage sa responsabilité, exerce un droit ou effectue un paiement puisse réviser et corriger, s’il y a lieu, l'information avant de confirmer son opération (M-19f) ? | Critère 11.12 [Argent] Pour chaque formulaire, les données à caractère financier, juridique ou personnel peuvent-elles être modifiées, mise à jour ou récupérées par l'utilisateur ? Critère 11.13 [Or] Pour chaque formulaire, toutes les données peuvent-elles être modifiées, mises à jour ou récupérées par l'utilisateur ? Critère 11.14 [Or] Pour chaque formulaire, des aides à la saisie sont-elles présentes ? Critère 11.15 [Or] Pour chaque formulaire, chaque aide à la saisie est-elle pertinente ? |
La comparaison entre les standards SGQRI et WCAG 2.0
Les exigences des standard SGQRI correspondent aux critères de succès 3.3.1, 3.3.2 et 3.3.3 des WCAG 2.0. Toutefois, pour le critère de succès 3.3.4, les standards SGQRI ne retiennent que deux des trois options énoncées par les WCAG 2.0, celles sur la vérification et la confirmation. L'option de réversibilité a été écartée parce qu'elle a été jugée trop difficile d'application.
Un site Web qui applique les exigences des standards SGQRI est donc conforme aux critères de succès 3.3.1 à 3.3.4 des WCAG 2.0. Un site Web qui applique les critères de succès 3.3.1 à 3.3.3 est conforme aux standards SGQRI. Toutefois, s'il applique seulement l'option de réversibilité pour le critère de succès 3.3.4, ce site Web sera non conforme aux standards SGQRI. Rien n'empêce cependant un site conforme aux standards SGQRI d'appliquer les trois options prévues par les WCAG 2.0.
Voir aussi :
- Comprendre la règle 3.3 [Assistance à la saisie]
- Comprendre le critère de succès 3.3.1 [Identification des erreurs]
- Comprendre le critère de succès 3.3.2 [Étiquettes ou instructions]
- Comprendre le critère de succès 3.3.3 [Suggestion après une erreur]
- Comprendre le critère de succès 3.3.4 [Prévention des erreurs (juridiques, financières, de données)]
- Comprendre le critère de succès 3.3.5 [Aide]
- Comprendre le critère de succès 3.3.6 [Prévention des erreurs (toutes)]
Retour en haut de page