L'attribut « aria-required » étant pris en charge par les combinaisons de navigateurs et de technologies d'assistance les plus courantes, nombreux sont ceux qui considèrent son utilisation comme la méthode la plus simple et la plus adaptée pour indiquer qu'une saisie est obligatoire dans un champ. Cependant, recommander son utilisation n'est peut-être pas si évident du point de vue d'une conformité stricte aux WCAG 2.
Il n'est nécessaire d'indiquer de manière accessible qu'une saisie est obligatoire pour un champ que lorsqu'un indice visuel le signale. En d'autres termes, en l'absence d'indice visuel indiquant que les champs sont obligatoires, les WCAG 2 ne s'appliquent pas. Les critères de succès de niveau A applicables sont les critères SC 1.3.1 et SC 3.3.2.
Considérons les quatre cas suivants :
Cas n° 1 :
Un symbole textuel (comme un astérisque) ou un texte indiquant qu'une saisie est obligatoire peut être associé par programmation au champ à l'aide de l'élément `label` (ou `legend` pour un groupe de contrôles associés), d'un attribut `title` (en l'absence de `label`) ou de l'attribut `aria-labelledby` lorsque celui-ci est utilisé pour étiqueter le contrôle.
Si tel est le cas, aucune mesure supplémentaire n'est nécessaire du point de vue de la conformité aux WCAG 2.
Dans ces situations, l'utilisation de `aria-required=true` aura pour effet :
– Contribue à mettre en évidence la propriété « required » lorsqu'un astérisque ou un autre symbole textuel est utilisé… L'utilisation de l'attribut `aria-required` est facultative et peut s'avérer utile.
– Cela entraîne une duplication si le mot « required » est déjà associé au contrôle. L'utilisation d'`aria-required` est donc déconseillée.
Cas n° 2 :
Un symbole (comme un astérisque) ou un texte indiquant qu'une saisie est obligatoire est présent, mais n'est pas associé au champ au niveau du code.
Dans ce cas, on peut soit associer par programmation le symbole ou le texte au champ en tant que partie intégrante de son libellé. Cette solution peut s'avérer appropriée lorsque le texte du libellé du champ n'est pas non plus associé à ce dernier.
Sinon, on peut utiliser l'attribut `aria-required=true` pour indiquer que la saisie est obligatoire, afin de se conformer aux WCAG 2.
Cas n° 3 :
Le fait qu'une saisie soit requise est indiqué uniquement par la couleur, le style de police ou un symbole non textuel (y compris via CSS).
Dans ce cas de figure, définir « aria-required=true » aidera certainement certains utilisateurs qui dépendent d'agents utilisateurs compatibles avec ARIA ou de technologies d'assistance.
Se contenter d'utiliser la couleur ou la mise en forme visuelle pour signaler une propriété obligatoire n'aidera pas les utilisateurs qui, en raison d'un handicap visuel, ne peuvent pas distinguer les différences de couleur ou de mise en forme et qui n'ont pas systématiquement besoin d'une technologie d'assistance.
En réalité, le fait de se contenter d'utiliser des différences de couleur ou de mise en forme pour signaler les champs obligatoires devrait être considéré comme un manquement aux WCAG 2, tout comme l'utilisation d'images CSS pour afficher du contenu essentiel (Technique F3).
Cas n° 4 :
Il arrive parfois qu’une note figurant avant (ou après) un formulaire précise que tous les champs sont obligatoires, sauf s’ils sont signalés comme facultatifs. Cela peut constituer un moyen efficace d’indiquer les champs obligatoires lorsque seule une minorité d’entre eux est facultative. Le texte « facultatif » est associé par programmation aux champs pour lesquels la saisie n’est pas obligatoire.
Dans ce cas, l'utilisation de l'attribut `aria-required=true` n'est pas obligatoire pour respecter les WCAG 2. Si cet attribut est utilisé, certains utilisateurs pourraient le trouver utile, tandis que d'autres pourraient ne pas être d'accord. Tout dépend du contexte.
Si le terme « facultatif » n'est pas associé aux champs non obligatoires, la solution consiste soit à établir cette association, soit à utiliser l'attribut `aria-required=true` sur les champs qui nécessitent une saisie.
Conclusion :
Nous espérons que les informations ci-dessus aideront les auteurs de contenu à déterminer dans quels cas il est plus simple d'utiliser la technique H90 (utilisation de l'élément `label` ou `legend` pour indiquer les champs obligatoires) ou l'attribut `aria-required=true` afin de se conformer aux WCAG 2.
Il est vrai que le fait d’indiquer clairement les champs obligatoires permet de réduire au minimum les erreurs de validation des données saisies. Mais il s’agit là d’une question de fonctionnalité et d’ergonomie qui relève de la responsabilité de l’auteur du contenu. De plus, le respect des critères SC 3.3.1 niveau A (Indication d’erreur) et SC 3.3.3 niveau AA (Suggestion en cas d’erreur) sera moins contraignant s’il y a moins de violations liées à la saisie. Cependant, ces critères ne portent pas sur l’indication appropriée des champs obligatoires.
Références :
- Directives pour l'accessibilité des contenus Web
- H90 : Indiquer les champs obligatoires d'un formulaire à l'aide d'une étiquette ou d'une légende
- ARIA2 : Identification des champs obligatoires à l'aide de la propriété « aria-required »
- F3 : Non-conformité au critère de succès 1.1.1 due à l'utilisation de CSS pour intégrer des images véhiculant des informations importantes
Sailesh Panchang est consultant principal en accessibilité chez Deque Systems
