Guide AccessiWeb
- Accueil
- Mode d'emploi
- Structure d'une fiche
- Fiches AccessiWeb
- 1) Images
- 2) Cadres
- 3) Couleurs
- 4) Multimédia
- 5) Tableaux
- 6) Liens
- 7) Code exécutable
- 8) Eléments obligatoires
- 9) Structuration de l'information
- 10) Présentation de l'information
- 11) Formulaires
- 12) Navigation
- 13) Consultation
- Glossaire
- Aide à l'évaluation
- Référentiel AccessiWeb
- Tables de correspondance
- Moteur de recherche
- Références
- Remerciements
- Plan du guide
Critère 11.10 : Pour chaque formulaire, le contrôle de saisie est-il accessible ?
Carte d'identité du critère 11.10 [niveau AccessiWeb : Bronze]
Test(s) AccessiWeb permettant de vérifier le critère 11.10
Note : le(s) test(s) suivant(s) sont issu(s) de AccessiWeb v1.1 [Déployé].
- Test 11.10.a [Bronze] : Pour chaque formulaire, les champs obligatoires sont-ils signalés de manière pertinente ?
- Test 11.10.b [Bronze] : Pour chaque formulaire, les erreurs de saisie sont-elles indiquées de manière accessible ?
Correspondances avec des critères d'autres référentiels sur l'accessibilité du Web
- Référentiel AccessiWeb 1.0 (19/12/2003) [version utilisée dans le Référentiel Accessibilité ADAE 2004] : 11.7 [Bronze]
- WCAG 1.0 (05/05/1999) : pas de correspondance.
- UWEM 1.0 (05/07/2006) : pas de correspondance.
- WCAG 2.0 (30/04/2008) : 3.3.1 [A], 3.3.2 [A]
- mobileOK 1.0 (02/11/2006) : pas de correspondance.
- RGAA : pas de correspondance (aucune version datée du RGAA n'est disponible en ligne à la date de publication de ce guide).
Comprendre
Comprendre le critère
Tous les formulaires doivent avoir un contrôle de saisie accessible.Bénéfices pour les utilisateurs
- Un contrôle de saisie accessible permettra à n'importe quel utilisateur de valider le formulaire, quelle que soit l'interface dont il se sert : navigateur graphique, navigateur gérant ou non les scripts, souris, clavier ou autre dispositif de pointage.
Valeur ajoutée pour le site
- Les actions côté serveur vont réduire la lourdeur du code.
Comment évaluer
Note : de manière générale, il est conseillé de faire l'évaluation d'un critère via l'analyse de son code source. Ce procédé d'évaluation par le code source est détaillé ci-après quand il est possible : procédé d'évaluation en 3 étapes via le ou les tests associés au critère. Les procédés d'évaluation par différents outils sont donnés en complément de l'évaluation par le code source.
Par le code source
- Sélectionner le(s) élément(s) à tester :
- Identifier dans un navigateur graphique tous les formulaires.
- Valider chacun des formulaires.
- Appliquer le(s) test(s) suivant(s) :
- Test 11.10.a [Bronze] : Pour chaque formulaire, les champs obligatoires sont-ils signalés de manière pertinente ?
- Test 11.10.b [Bronze] : Pour chaque formulaire, les erreurs de saisie sont-elles indiquées de manière accessible ?
- Valider le critère : le critère est validé si vous répondez oui à tous les tests applicables précédents.
Par l'utilisation d'outils
Pour une liste complète des outils utilisés pour évaluer l'accessibilité des pages web et un résumé de leurs principales fonctionnalités, reportez-vous à la page Outils d'aide à l'évaluation.
Evaluer avec la Barre d'outils Accessibilité du Web pour Internet Explorer (version 2.0 beta en français) :
Pour le test 11.10.a [Bronze] et le test 11.10.b [Bronze] :- Ces tests ne sont pas évaluables par la Barre d'outils Accessibilité du Web (version 2.0 beta).
Evaluer avec la Barre d'Outils Web Developper pour Firefox (version 1.1.4 en français) :
Pour le test 11.10.a [Bronze] et le test 11.10.b [Bronze] :- Ces tests ne sont pas évaluables par la Barre d'Outils Web Developper (version 1.1.4).
Comment mettre en oeuvre
Avertissement : les informations du paragraphe "Comment mettre en oeuvre" sont données à titre indicatif. Les contenus des sous-paragraphes Implémentation et Exemple de bonne pratique ne présentent pas tous les codes d'implémentation.
Qui est concerné ?
Ce critère est implémenté par le développeur HTML.
Implémentation
Quelques spécificités d'un contrôle de saisie accessible d'un formulaire :
- il est important de spécifier les champs obligatoires de manière explicite (Exemple : les champs précédés d'une étoile sont tous obligatoires.) et mettre cette mention de préférence en préambule du formulaire
- il faut éviter de faire ressortir les champs obligatoires par le seul intermédiaire d'une couleur par exemple.
- en cas d'erreur de saisie, ne pas effacer les champs déjà remplis par l'utilisateur.
- la page qui renvoie les erreurs de saisie doit indiquer clairement les champs où se situent les erreurs. Cette indication doit apparaître avant le champ désigné.
Exemple de mauvaise pratique
Voir le paragraphe "Implémentation".
Exemple de bonne pratique
Voir le paragraphe "Implémentation".
Illustrations
Avertissement : le contenu du paragraphe "Illustrations" est donné à titre indicatif. Il ne présente pas tous les cas possibles.
Cette copie d'écran présente un message d'erreur au-dessus du formulaire contenant un champs "Texte" vide et un bouton "Valider la recherche".
Le message précise directement dans la page à l'internaute qu'il doit indiquer son critère de recherche.
Il est également inclus dans une balise FIELDSET nommé erreur et apparait en rouge afin de le différencier clairement du reste du formulaire.
Références
- WAI Curriculum (section 1.1) : a text equivalent for scripts
- WAI Curriculum (section 6.3, 6.4 et 6.5) : Ensure that pages are usable when scripts [...] are turned off
Copyright © 2008 Association BrailleNet. Tous droits Réservés.