Input type="text" associé à un input type="submit" contenant une img

Bonjour,

Cette discussion fait suite à cette discussion.

Quelle est la meilleure stratégie pour rendre accessible un code de ce genre qui est très fréquent ?

<form>
<p><input type="text" id="fab" /><button type="submit"><svg><!-- contenu du SVG --></svg></button></p>
<p>Recherche par référence fabricant</p>
</form>

Raphaël conseille :

<button>
  <svg aria-hidden="true">
    <!-- contenu du SVG -->
  </svg>
  <span class="visually-hidden">Nom accessible masqué à l'écran</span>
</button>

Agrémenté d'un CSS trouvé sur ce site.

.visually-hidden:not(:focus):not(:active) {
    clip-path: inset(50%);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;

}

Peut-on alléger avec un simple aria-label dans le bouton ?

<form>
<p><input type="text" id="fab" /><button type="submit" aria-label="Recherche par référence fabricant"><svg><!-- contenu du SVG --></svg></button></p>
<p>Recherche par référence fabricant</p>
</form>

Je sais que ce dernier code ne crée pas d'alerte dans PageSpeed Insights, rubrique Accessibilité.
Modifié par boteha_2 (03 Mar 2024 - 14:57)

boteha_2 a écrit :

Peut-on alléger avec un simple aria-label dans le bouton ?

La réponse courte est : oui on peut tout à fait remplacer par un `aria-label` sur le bouton.

J'ai conseillé la version span masqué pour les raisons suivantes :
- c'est ce que nous avons adopté dans notre agence (et que j'aime quand on reste cohérent entre nos projets)
- aria-label n'est pas traduit dans les navigateurs, ce qui peut être problématique si le site est multilingue
- les textes masqués à l'écran mais lus par les AT (.visually-hidden ou .sr-only) sont extrêmement courants au sein de nos projets, donc cette classe utilitaire est de toute façon utilisée chez nous

Bonjour Raphaël,

Merci de ton,suivi, ta réponse courte me convient bien.

Le site en question n'est pas multilingue, je vais sans doute me contenter d'un aria-label.

Autrement, si je peux me permettre, Alsacréations n'a pas de feuille de style pour mode DARK.

Ni la Fnac, ni Darty, ni même Amazon.
Pour eux je devine que leur code est tellement compliqué qu'il faudrait sans doute tout refaire pour pouvoir styler le mode Dark.
Modifié par boteha_2 (03 Mar 2024 - 19:19)

Que vous ayez les compétences je n'en doute pas.

Même sans mode DARK votre site est très beau, pas démodé.

Et de toutes façons son contenu est juste admirable.

Bonjour,

Veuillez m'excuser de revenir sur le sujet mais cet article conseille de labelliser l'élément input type="text".

Cet article est donné en lien par PageSpeed Insights, donc on peut supposer que c'est un peu sérieux.

Dommage qu'il n'indique pas ce qu'il faut faire avec le bouton de soumission.

Faut-il cumuler ?

<form>
<p><input type="text" id="fab" /><button type="submit" aria-label="Bouton de soumission recherche par référence fabricant"><svg><!-- contenu du SVG --></svg></button></p>
<p><label for="fab">Recherche par référence fabricant</label></p>
</form>

Raphaël considère le label sur input type="text" comme inutile, voire nuisible.

Mais sans ce label PageSpeed Insights retire des points...
Modifié par boteha_2 (24 Mar 2024 - 12:33)

Bonjour,

a écrit :
Raphaël considère le label sur input type="text" comme inutile, voire nuisible.

Ah non ! Au-secours ! Raphael a dit ça ? Mais qu'est-ce qui se passe ! Rien ne va plus !

Le label est absolument [font size=72][color=red][b]INDISPENSABLE[/i][/color][/font][/blink] !

Tous les champs de formulaire doivent avoir un label.
Si vous voulez, vous pouvez le masquer à l'écran et utiliser visually-hidden / sr_only. Mais il doit être présent.
S'il n'est pas possible d'utiliser <label>, vous pouvez utiliser aria-label, mais il faut toujours privilégier <label>.

C'est obligatoire car sans cela, un utilisateur de lectteur d'écran ne peut pas savoir à quoi sert le champ, même si c'est évident pour vous.

Bonjour,

QuentinC a écrit :
Tous les champs de formulaire doivent avoir un label.
Si vous voulez, vous pouvez le masquer à l'écran et utiliser visually-hidden / sr_only. Mais il doit être présent.
S'il n'est pas possible d'utiliser <label>, vous pouvez utiliser aria-label, mais il faut toujours privilégier <label>.

C'est obligatoire car sans cela, un utilisateur de lecteur d'écran ne peut pas savoir à quoi sert le champ, même si c'est évident pour vous.

Peut-on dire qu'il faut un label (ou équivalent) pour chaque champ d'un formulaire ET AUSSI pour le ou les boutons de soumissions ?

Bonjour QuentinC,

Merci de faire ainsi le tour du sujet.

Test d'accessibilité, connais-tu de bons outils à part PageSpeed Insights ?

Ou encore mieux un simulateur de navigateur sonore ?

Bonsoir,

JE suis assez mal placé pour parler des outils automatiques. Comme j'utilise moi-même un lecteur d'écran, je n'ai pas vraiment besoin d'outil de test d'accessibilité. JE peux constater immédiatement ce qui ne va pas sans avoir besoin de ça.
De ce que j'en sais et de ce que j'ai pu un peu tester rapidement, il ne te trouveront que les trucs les plus simples et les plus évidents, et passeront à côté de 60%, 70% des véritables problèmes et des questions à se poser.

Quant à "un simulateur de lecteur sonore" comme tu l'appelles, autant le dire sans détour, ça n'existe pas. Ce que tu peux éventuellement trouver dans le genre extension pour navigateur est tellement éloigné des lecteurs d'écran réels que ça ne te servira à rien, à part te donner une idée complètement fausse de notre façon de fonctionner.

Le meilleur moyen de tester, c'est d'installer NVDA ou lancer VoiceOver, et expérimenter par soi-même. C'est pas forcément facile ! Mais terriblement formateur. Après coup, tu ne verras plus les choses comme avant.

Bonjour,

concernant les label, il y a probablement confusion, assez naturelle : "label" c'est plusieurs concepts.
Avant de détailler, bien distinguer 2 types d'éléments de formulaire : les champs et les boutons.
D'un côté input type text, email, etc les select et textarea et un peu différent mais ça reste un choix de l'utilisateur les boutons (erf) radio et cases à cocher.
D'un autre les boutons pour déclencher des actions dont valider le formulaire : les éléments button et input de type submit, button (et reset) (edit: et uniquement pour input le type image).

Label donc :
Label est la traduction d'étiquette mais aussi d'intitulé et c'est facilement utilisé dans une discussion sans trop de précisions... Si je demande à un développeur "tu lui as mis un label ?", il faut comprendre complètement autre chose avec un champ ou avec un bouton. Ce sera utilisé pour un lien mais ça devrait pas... Les joies de la communication et des à peu près.

L'étiquette d'un champ texte (et email, password, etc), de radios, de cases à cocher, d'un select, d'un textarea est balisée par un élément <label>.
Au plus simple et recommandé, on garde cette étiquette visible, proche de son champ ("accolée") et on l'associe au "champ" via les attributs for et id (guide de l'intégrateur, une bonne base).

aria-label est un attribut ARIA qui pemet de donner un nom accessible à un élément (du genre plutôt interactif donc lien A, boutons et champs ou genre structure comme nav, header, etc. Sur une div tu oublies et tu évites).
Le nom accessible c'est du jargon pour dire "le texte, l'information qui sera retransmise par le navigateur et le lecteur d'écran à l'utilisateur". Le plus souvent, c'est l'intitulé du bouton comme <button>Envoyer</button>, dans le cas des champs c'est le contenu de son label s'il en a un correctement associé.
aria-label a la priorité sur l'intitulé : pratique si le bouton n'a pas d'intitulé, très dangereux si son contenu est différent d'un intitulé déjà présent. Un malvoyant ou l'utilisateur de commande vocale va voir un truc mais le lecteur d'écran dira autre chose ou bien c'est la commande vocale qui ne va pas trouver ce que son utilisateur lui dit... Grosse confusion.
Il y a aussi aria-labelledby qui est une variante : il pointe vers l'id d'un élément présent par ailleurs quelque part dans la page et son contenu devient le nom accessible avec une priorité encore plus forte.
Ne pas confondre avec aria-describedby qui est la description d'un élément, une info en plus du nom accessible (ouuuf).
Modifié par Felipe (04 Apr 2024 - 19:15)

Bonjour,

Merci de votre suivi.

QuentinC a écrit :
Le meilleur moyen de tester, c'est d'installer NVDA ou lancer VoiceOver, et expérimenter par soi-même. C'est pas forcément facile ! Mais terriblement formateur. Après coup, tu ne verras plus les choses comme avant.

C'est noté.

Felipe, merci pour tes explications, ce sujet est assez ardu.

Bonsoir,

C'est vrai que le terme label, intitulé ou étiquette désigne des choses différentes selon le cas. Felipe a bien résumé l'essentiel que je n'ai pas explicité moi-même car c'était encore trop évident pour moi.

C'est pour cette raison que la spec préfère parler de nom accessible (accessible name). Mais c'est pas plus simple.

Encore une fois, la théorie est bien compliquée et on apprend bien plus vite en expérimentant soi-même.

Bonjour,

Je pense pouvoir signaler cet article sur Web;dev.

Un peu ardu comme tous les articles mal traduits de l'anglais mais au cœur du sujet des tests.