Décryptage des WCAG 2.1 #1 : critère de succès 1.3.5 « Identifier la fonction du champ »

Pourquoi un nouveau critère ? Et pour qui ?

Ce nouveau critère a pour objectif d’aider les utilisateurs à mieux reconnaître et comprendre la fonction des champs ainsi qu’à automatiser la saisie de certaines informations personnelles.

Dans le RGAA, le critère 11.2 demande déjà à ce que les étiquettes de champs de formulaire soient pertinentes, c’est-à-dire qu’elles permettent de comprendre l’utilisation et la fonction du champ. Dans WCAG, il s’agit plus particulièrement du critère de succès 3.3.2. Néanmoins, le critère n’impose pas de règles de vocabulaire, de dénomination ou de représentation graphique des champs de formulaire. Ainsi par exemple, pour un champ qui attend le nom de famille de l’utilisateur, l’étiquette peut avoir plusieurs valeurs :

• Nom
• Votre nom
• Inscrivez votre nom
• Quel est votre nom
• Nom de famille
• Nom d’usage
• Etc.

Pour des utilisateurs avec un handicap mental, être confrontés à des expressions ou termes non familiers pour désigner des champs pourtant familiers peut être un obstacle à la compréhension de la fonction du champ, et donc entraîner l’échec de la tâche.

Mais d’une part, il n’est pas envisageable d’imposer aux auteurs de sites web des termes et expressions pour la création d’étiquettes de champs de formulaire. D’autre part, un label explicite pour un utilisateur ne l’est pas forcément pour un autre. Pour ces raisons, il est préférable de laisser l’adaptation des contenus (éditoriaux et graphiques) au libre choix de l’utilisateur.

Pour que ce soit possible, il faut donc décrire, à l’aide de données exploitables par un programme informatique, la nature de l’élément à adapter. Une technologie d’assistance ou une extension de navigateur (ou encore un script) vont alors pouvoir exploiter ces données afin d’adapter la présentation des formulaires. Ainsi, il sera possible de modifier le texte de l’étiquette des champs, ou encore d’appliquer la présentation d’un symbole à proximité du champ, pour une meilleure compréhension.

Mais aujourd’hui, aucun outil ne permet réellement d’exploiter ces informations pour personnaliser les interfaces utilisateurs. Seule la mise à disposition d’un script par l’auteur du site pour adapter les présentations des champs est pour l’instant envisageable. Le critère de succès indique bien qu’il s’agit d’un critère mis en place pour une compatibilité future avec des outils qui seront capables d’exploiter ces données à des fins de personnalisation.

Conditions d’application du critère

Informations personnelles

De niveau double A (AA), ce nouveau critère concerne tout particulièrement les champs de formulaire. Il demande à ce que chaque champ qui collecte des informations personnelles puisse être déterminé par un programme informatique, c’est-à-dire que le code source possède les propriétés nécessaires à décrire la nature de la saisie attendue.

Les champs concernés sont listés dans une section dédiée « Input Purposes for User Interface Components ». On y trouve le nom, le prénom, le titre honorifique, l’adresse e-mail, l’adresse postale, l’URL d’un site personnel, l’URL d’une photographie et beaucoup d’autres informations. Pour chaque champ qui attend l’une des données listées dans cette section, le critère est applicable. Pour tous les autres champs, qui ne visent pas des données personnelles, comme par exemple un champ de saisie de commentaire, le critère ne s’applique pas.

Champs de formulaire compatibles

Ce critère ne peut donc s’appliquer qu’aux champs de formulaire qui disposent des attributs nécessaires pour pouvoir définir ces informations. Comme nous allons le voir à la section suivante, les cases à cocher (input type checkbox) et boutons radios (input type radio) par exemple, ne disposent pas d’une telle capacité.

En résumé

Ce critères s’applique si :

• Le champ de formulaire attend une information personnelle (nom, prénom, adresse, etc.) ;
• Le champ de formulaire possède les attributs nécessaires pour définir la nature de la saisie attendue.

Comment mettre en œuvre ce critère ?

Pour l’instant, la seule technique identifiée dans les documents WCAG 2.1 est l’utilisation de la propriété autocomplete.

La propriété autocomplete HTML 5 indique au navigateur si oui ou non il doit suggérer des saisies à l’utilisateur sur la base de saisies antérieures (généralement enregistrées dans le navigateur via le cache).

La valeur par défaut est true ; c’est-à-dire que sans la définir, le navigateur va proposer des suggestions à l’utilisateur, sur la base des valeurs saisies précédemment et enregistrées dans le cache du navigateur. Si la valeur est à false, aucune suggestion ne sera faite à l’utilisateur.

Nom (autocomplétion active)

<label for="name">Nom</label>
<input type="text" id="name" autocomplete="true" />

Nom (autocomplétion désactivée)

<label for="name-false">Nom</label>
<input type="text" id="name-false" autocomplete="false" />

Définir le périmètre des suggestions

La propriété autocomplete permet également de décrire le type de saisie attendue, et ce de manière très fine.

En effet, l’attribut autocomplete peut recevoir plusieurs valeurs : des valeurs standards, définies dans les spécifications (que nous détaillons après), mais également des valeurs personnalisées définies par le préfixe section-* (pour identifier des regroupements par exemple). De même, autocomplete peut être utilisé sur des éléments en lecture seule ou des textes, afin de décrire la nature de la donnée.

<fieldset>
<legend>Adresse de livraison</legend>
<label for="adress1">Adresse :</label>
<input id="address1" autocomplete="section-delivery shipping street-address">
<label for="city1">Ville :</label>
<input id="city1" autocomplete="section-delivery shipping address-level2">
</fieldset>

<fieldset>
<legend>Adresse de facturation</legend>
<label for="adress2"> Adresse :</label>
<input for="adress2" autocomplete="section-invoice shipping street-address">
<label for="city2">Ville :</label>
<input for="city2" autocomplete="section-invoice shipping address-level2">
</fieldset>

Dans le cas qui nous intéresse, l’application du critère 1.3.5, nous nous limiterons à expliquer les mots clés arrêtés par la spécification.

Vous pouvez trouver la liste des mots clés standards « Autofill field » dans la documentation HTML 5. Ce document décrit, pour chaque mot clé, ce qu’il attend comme type de données, le format de données attendue (texte libre, chiffre, multiligne, etc.), un exemple réel de valeur possible et le type de champ pouvant recevoir cette valeur.

Par exemple, pour une valeur d’autocomplete « name » :

• La saisie attendue est le nom complet ;
• Le type de données est un texte libre sans retour à la ligne et sans mise en forme (les zones de texte ne peuvent donc pas recevoir cette valeur) ;
• Un exemple réel de saisie est : « Sir Timothy John Berners-Lee » ;
• Le type de champ pouvant recevoir cette valeur est un champ de type text.

<label for="ex-name">Nom</label>
<input id="ex-name" autocomplete="family-name" type="text" />

<label for="ex-surname">Prénom</label>
<input id="ex-surname" autocomplete="given-name" type="text" />

<label for="ex-title">Profession</label>
<input id="ex-title" autocomplete="organization-title" type="text" />

<label for="ex-url">Site web</label>
<input id="ex-url" autocomplete="url" type="text" />

<label for="ex-email">Courriel</label>
<input id="ex-email" autocomplete="email" type="text" />

<label for="ex-tel">Téléphone</label>
<input id="ex-tel" autocomplete="tel" type="text" />

Conclusion

Ce critère n’impose pas de complexité supplémentaire aux développements, il s’agit « simplement » de décrire certains champs de formulaire grâce à des attributs HTML. Il ne s’agit pas de gérer des scripts, etc. Mais simplement d’ajouter un attribut qui définit la nature de l’information attendue. Autrement dit, il semble qu’il fasse partie des nouveaux critères WCAG 2.1 relativement simples à implémenter. Il est même possible que certains d’entre vous, férus de sémantique produisent des formulaires déjà conformes à ce critère.