J'ai donc lu beaucoup d'articles qui disent que la validation de formulaire HTML 5 est accessible (les choses required l'attribut qui empêchera le formulaire d'être soumis est un champ laissé vide), pourtant quand j'ai testé mon formulaire sur NVDA sur Chrome et BackTalk sur Android, si je n'avais pas renseigné la saisie, il revient sur le champ de saisie (ce qui est bien !) n'annonce pas l'étiquette du champ.

Donc la validation HTML5 seule n'est pas accessible ? De plus, pouvez-vous combiner la validation HTML5 et le JS personnalisé ?

Devez-vous rédiger une validation personnalisée du site client afin de rendre les formulaires accessibles ?

4
Stefany Newman 24 janv. 2020 à 00:53

1 réponse

Meilleure réponse

Réponse courte

Oui, la validation HTML5 standard est accessible et passera WCAG2.1 AA, mais vous pouvez faire beaucoup mieux avec du JavaScript.

Longue réponse

Si vous devez prendre en charge Internet Explorer 9 ou une version antérieure, vous devrez utiliser JavaScript (qui, selon enquête WebAim - la section "Navigateurs" couvre encore environ 3,6% des utilisateurs de lecteurs d'écran).

La validation HTML5 native est un très bon point de départ, mais il y a des limitations (vous en avez donné une dans un commentaire, certains lecteurs d'écran (NVDA) n'annoncent plus le libellé, ce qui signifie qu'un utilisateur doit physiquement demander que le libellé soit lu via des contrôles ).

L'autre chose est qu'une fois que vous quittez un champ, il ne vous dit normalement pas que vous avez fait une erreur jusqu'à ce que vous ayez soumis le formulaire (c'est censé mais ce n'est pas toujours le cas en fonction de votre vitesse d'annonce, de vos paramètres et de votre navigateur) .

Par exemple, la mise à jour de aria-invalid est utile pour un retour immédiat (et prend en charge les navigateurs plus anciens, tout en étant plus robuste avec les lecteurs d'écran « inhabituels »).

L'utilisation d'une région aria-live pour fournir un retour immédiat onblur (ou étranglé / anti-rebond) est également utile et constitue une meilleure solution.

Une autre chose est que la validation native n'est en fait pas très efficace. Par exemple fff@fff s'affiche comme un e-mail valide et permettra à un formulaire d'être soumis sur un champ type="email", de même avec type="url" il permettra à https://fff d'être soumis (dans Chrome au moins) .

Je pourrais continuer avec d'autres choses telles que fournir de meilleures instructions sur la façon de corriger les erreurs (en particulier pour des choses comme les numéros de téléphone), mais vous voyez l'idée.

En gros, utilisez autant de fonctionnalités HTML5 natives que possible pour donner une base solide et une bonne solution de repli pour les erreurs JavaScript / les personnes n'utilisant pas JavaScript. Ensuite, utilisez CSS et JS pour améliorer l'expérience pour tout le monde.

De plus, pouvez-vous combiner la validation HTML5 et le JS personnalisé ?

Vous pouvez et vous devez être conscient que vous finissez par doubler la validation (ce qui n'est pas une mauvaise chose comme je l'ai dit pour le repli).

La beauté est que vous pouvez utiliser des pseudo-sélecteurs dans votre JavaScript pour cibler les champs par type, évitant ainsi d'ajouter des classes inutiles, etc.

Par exemple. document.querySelectorAll('input[type=email]') peut être utilisé pour sélectionner n'importe quelle entrée d'e-mail pour validation ou document.querySelectorAll('input[required]') pour trouver tous les champs requis.

Vous pouvez également utiliser des éléments tels que max="100" sur les entrées de curseur / numériques pour définir vos plages de validation « à la volée » et avoir toujours une solution de secours pour aucun JavaScript.

Comme vous pouvez l'imaginer, cela vous permet d'écrire une bibliothèque si vous ne pouvez pas en trouver une prête à l'emploi qui est réutilisable sur presque n'importe quelle forme.

9
Community 20 juin 2020 à 09:12