ARCHIVÉ - Rendre les contrôles de formulaires accessibles

Avertissement Cette information est archivée parce qu'elle est désuete et n'est plus pertinente.

Contenu archivé

Information archivée dans le Web à des fins de consultation, de recherche ou de tenue de documents. Cette dernière n’a aucunement été modifiée ni mise à jour depuis sa date de mise en archive. Les pages archivées dans le Web ne sont pas assujetties aux normes qui s’appliquent aux sites Web du gouvernement du Canada. Conformément à la Politique de communication du gouvernement du Canada, vous pouvez obtenir cette information dans un autre format en communiquant avec nous.

Table des matières

1.0 Introduction

On utilise souvent des formulaires en direct pour permettre aux clients de soumettre des renseignements ou des demandes à des institutions. Même si les formulaires peuvent procurer une grande interactivité et un bon contrôle aux clients, ils peuvent aussi causer d'importants problèmes d'accessibilité et d'utilisation s'ils sont mal conçus.

Le présent document fournit des conseils et des solutions pour concevoir des formulaires en direct qui sont accessibles, conviviaux et conformes à la Normalisation des sites Internet (NSI).

2.0 Conception de formulaires

Afin de veiller à ce que tous les formulaires en direct soient disponibles pour tous les clients et qu'ils soient faciles à utiliser, les exigences en matière d'accessibilité et d'utilisation doivent être prises en considération dès l'étape de la conception. Les directives qui suivent aideront à concevoir des formulaires accessibles et faciles à utiliser :

  1. L'ordre des onglets doit être logique et intuitif. L'ordre doit permettre la bonne focalisation à l'utilisateur qui parcourt les onglets du formulaire.

  2. Les formulaires ne doivent être activés qu'au moyen d'un bouton « Envoyer ».

  3. Les formulaires ne doivent pas être tributaires du type d'unité. Ils doivent être clairs et leur style doit être élégant, peu importe l'unité de saisie utilisée..

  4. Les cases de saisie de texte doivent être organisées intuitivement et doivent permettre la saisie de tous textes raisonnables. La forme de saisie à privilégier doit être précisée sur l'étiquette (« label »), mais d'autres formes de saisie doivent aussi être acceptées au moyen de la validation du formulaire.

  5. Les formulaires doivent être fonctionnels quand le script côté client (p. ex., JavaScript) est désactivé.

  6. Les tableaux ne doivent pas être utiliser pour formater des formulaires. Le CSS doit être utilisé plutôt.

  7. Le bouton « Reprendre / Rétablir » doit suivre le bouton « Envoyer ».

  8. Tous les boutons et contrôles de formulaires doivent être adaptables.

  9. Une étiquette (« label ») pertinente et associée par programmation doit correspondre à chacun des champs du formulaire.

  10. Un champ de formulaire doit être associé par programmation à tout le texte contenu sur un formulaire.

  11. Les champs obligatoires et optionnels doivent être clairement indiqués au moyen d'un texte.

  12. Un accusé de réception doit être fourni pour chaque formulaire soumis avec succès.

  13. La validation des formulaires doit être effectuée côté serveur.

Vous trouverez un exemple de formulaire accessible à la section 5.0 (Exemple de formulaire accessible).

3.0 Contrôles de formulaires accessibles

3.1 Qu'est-ce qu'un contrôle de formulaires?

Un contrôle de formulaires est un élément qui accepte l'entrée de l'utilisateur et qui doit être placé entre les balises <form> et </form>. Exemples de contrôles de formulaires : zone de texte, surface de saisie, sélection, case à cocher et bouton « Envoyer ».

Les documents « Critère 10.2 du W3C - Contrôles de formulaire » et « Critère 12.4 du W3C - Étiquettes de contrôle » stipulent que chaque contrôle de formulaires doit être associé à une balise <label> (à l'exception des éléments « cachés »). L'utilisateur peut ainsi sélectionner l'étiquette (« label ») pour sélectionner le contrôle de formulaires qui y est associé. Cette fonction est très utile dans le cas des contrôles de formulaires puisqu'elle augmente la surface sélectable, ceci améliore l'accessibilité pour les personnes qui utilisent un logiciel à commande vocale ou qui ont un handicap moteur, à qui il est difficile de sélectionner une zone précise. Remarquez que les boutons ordinaires (Envoyer, Rétablir, etc.) n'ont pas besoin d'étiquette (« label ») puisque ceux-ci sont déjà intégrés.

Des étiquettes (« label ») peuvent être insérées n'importe où dans le conteneur <form></form>; elles doivent cependant être placées de manière à correspondre aux contrôles de formulaires connexes.

Pour associer explicitement une étiquette (« label ») à un élément, inscrivez « for="variable" » dans la balise initiale « label » et « id="variable" » dans le contrôle de formulaires connexe, « variable » étant une combinaison de caractères alphanumériques (le « - » est accepté).

Pour vérifier si l'élément fonctionne correctement, il suffit de sélectionner l'étiquette (« label »). Si le résultat est le même que sélectionner le contrôle de formulaires connexe, l'étiquette (« label ») fonctionne correctement.

Voici quelques exemples de contrôles de formulaires accessibles. Remarquez bien que les attributs « for » et « id » doivent contenir le même texte pour que les étiquettes (« label ») fonctionnent correctement. Vous trouverez un exemple d'un formulaire avec des contrôles de formulaires accessibles à la section 5.0 (Exemple de formulaire accessible).

Haut de la page

3.2 Des exemples de contrôles de formulaires accessibles

3.2.1 Zone de texte

<strong><label for="srch">Recherche</label></strong><br />
<input type="text" name="srch" id="srch" size="10" maxlength="80" />


3.2.2 Cases à cocher et boutons radio

Pour associer une question à plusieurs cases à cocher, il est nécessaire d'utiliser <fieldset> et <legend>.

<fieldset>
<legend>J'ai une connaissance approfondie du :</legend>
<input type="checkbox" name="q1" id="q1" value="c1" /><label for="q1">CSS</label><br />
<input type="checkbox" name="q2" id="q2" value="c2" /><label for="q2">XHTML</label>
</legend>
</fieldset>

I have significant knowledge of:

3.2.3 Surface de saisie

<label for="qt">Dans l'affirmative, décrivez les problèmes rencontrés.</label><br />
<textarea name="qt" id="qt" rows="5" cols="45"></textarea>


3.2.4 Sélections

Il existe des problèmes d'accessibilité pour les utilisateurs qui utilisent le clavier avec les sélections multiples (multiple="multiple"). Il est impossible de sélectionner plusieurs options séparées en utilisant seulement le clavier avec certains navigateurs. Par conséquent, n'utilisez pas l'option pour activer les sélections multiples (multiple="multiple").

<label for="sprt">Sélectionnez le sport auquel vous souhaitez participer :</label><br />
<select name="sprt" id="sprt">
<option value=""><option>
<option value="Hockey">Hockey en hiver</option>
<option value="Baseball">Baseball en été</option>
<option value="Soccer">Soccer en été</option>
</select>


4.0 Messages d'erreur

Les messages d'erreur servent à expliquer au client les raisons pour lesquelles un formulaire n'a pu être envoyé. Si les messages d'erreur ne sont pas accessibles ou utilisables, les clients auront de la difficulté à corriger les formulaires invalides. Les directives qui suivent aideront à concevoir des messages d'erreur accessibles et utilisables :

  1. Les messages d'erreur doivent être incorporés au formulaire de saisie. Le formulaire et les messages d'erreur ne doivent pas être sur des pages distinctes.

  2. Les données du client doivent être conservées quand le message d'erreur est affiché. Les clients ne doivent pas être tenus de remplir de nouveau le formulaire quand celui‑ci ne peut être envoyé en raison d'erreurs de saisie du client.

  3. Un résumé doit figurer au début du formulaire. Ce résumé doit préciser en texte le total d'erreurs de saisie et inclure une liste de messages d'erreurs numérotés en séquence. Les messages d'erreur doivent être faciles à comprendre, ils doivent être précédés de la mention « erreur » et renvoyer l'utilisateur au contrôle de formulaires où est survenue l'erreur.

  4. Les messages d'erreur doivent être inclus sur les étiquettes (« label ») des contrôles de formulaires où sont survenues les erreurs. Les messages d'erreur inclus sur les étiquettes (« label ») doivent être conformes aux messages d'erreur à l'étape 3, l'explication des erreurs devant être facile à comprendre, les messages étant numérotés en séquence et précédés de la mention « erreur ».

  5. Pour faciliter la compréhension, il peut être utile d'établir une distinction visuelle du message au moyen de la couleur et du formatage du texte.

Vous trouverez un exemple de formulaire accessible à la section 5.0 (Exemple de formulaire accessible).

5.0 Exemple de formulaire accessible