Aller au contenu

Accessibilité d'un formulaire


Guest Hellway

Sujets conseillés

Guest Hellway

Bon, je suis toujours entrain de développer mon CMS et comme il se veut axé sur l'accessibilité, j'aurais besoin de quelques conseils (au passage, si des personnes sont intéressées pour se joindre à moi, message privé...) :

Premièrement, au sujet des formulaires :

J'utilise les balises <fieldset> et <legend> pour une meilleure accessibilité, mais je m'intérroge sur le contenu de ces derniers.

Pour l'instant, ne sachant trop comment faire, j'ai fais mes formulaires de cette manière (ici, pour ajouter une entrée):

<fieldset>

<legend>Informations sur l'article</legend>

<p><label for= etc...>Auteur :</label><br />

<input type="text" etc....><br />

<label for= etc...>Contenu :</label><br />

<textarea etc...

</p>

</fieldset>

Mais ça me pose un problème. Cela a-t-il vraiment un sens de faire des paragraphes pour un formulaire ??? Si non, y a-t-il une façon de faire plus concise ?

Deuxièmement, pour les acceskey :

Comment générer un acceskey qui a du sens quand on sait que les formulaires sont générés automatiquement ? Et pour un menu généré dynamiquement ?

Troisièmement, l'attribut title :

Imaginons que dans une rubrique, je liste un certains nombre d'articles :

Dois-je mettre dans l'attribut title des liens vers ces articles :

Lire cet article

ou carrément :

Lire l'article : Titre de l'article

Car si le titre fait 100 caractères, je risque d'avoir des problèmes et si je met pas le titre dans l'att title, le visiteur risque de se gourrer de lien (ou alors, je me trompe ?).

Voilà, merci aux pros qui sauront me répondre...

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

L'explication de l'utilisation de la balise <p> se trouve sur Openweb :

La balise de formulaire n'est qu'un délimiteur, elle est destinée à recevoir des éléments de niveau bloc et non du contenu dit "en-ligne" (pour plus d'informations, voir l'article Boîtes bloc, boîtes en ligne et propriété display). Elle est donc elle même une balise de type bloc, et à ce titre ne peut pas être incluse dans un paragraphe (ou autre élément qui n'accepte que le contenu en-ligne).

Pour pouvoir y insérer des éléments comme des cases à cocher ou du texte (qui sont du contenu en-ligne), vous devrez les regrouper dans une balise comme <p> (paragraphe), <li> (élément de liste) ou <div> (balise de type bloc qui accepte le contenu en-ligne).

Cette balise est donc obligatoire.

Pour deuxième question... je sèche :(

Quant au contenu de l'attribut title d'un lien, pour être efficace, il doit être significatif.

Si tu renseignes cinq fois "Lire cet article", cela ne sera d'aucune aide pour l'utilisateur.

Si le titre complet est trop long, tu peux limiter à quelques mots reflétant le contenu de la page vers laquelle le lien est fait.

Lien vers le commentaire
Partager sur d’autres sites

Le accesskey n'a de sens que si tu sais où le placer. Si tu ne sais pas comment sera ton formulaire après création dynamique, alors il ne te sers à rien de t'en servir, a priori. Sinon de mettre une valeur par défaut. Non ?

Anonymus.

Lien vers le commentaire
Partager sur d’autres sites

Balisage des éléments de formulaire : les listes de définitions (voir article récent traduit par pompage.net) offrent une solution élégante sur le modèle :

<dl>

<dt><label for="...">...</label></dt>

<dd><input id=..." name="... ></dd>

</dl>

(Non, ce n'est pas un détournement de balise : revoir la spécification HTML4.01 qui invite explicitement à étendre l'usage de ces listes au-delà des définitions proprement dites)

Accesskeys : inutile d'encombrer tes formulaires avec des accesskeys systématiques. Le sujet sera bientôt traité sur OpenWeb. Disons simplement que ce mécanisme d'accessibilité nécessiterait une sérieuse remise en question.

Mieux vaux soigner l'ordre de tabulation (tabindex) et les labels, plus pertinents.

Enfin, l'attribut title ne doit être utilisé que

- s'il apporte une information pertinente en complément de l'intitulé du lien,

- s'il est bref (il sera éventuellement lu par jaws, IBM HPR...)

- et s'il contribue à identifier la cible du lien.

Autrement dit, si l'intitulé des liens donne clairement le titre de l'article. le title peut être exploité pour donner la date de parution, l'auteur, le site-cible...

Mais en aucun cas "Lire cet article" qui serait identique pour tous les liens (inutile des points de vue sémantique et ergonomique et gênant du point de vue accessibilité). Ni "Lire cet article : titre de l'article" puisque l'info est déjà dans le contenu du lien.

Au passage, ne pas oublier hreflang pour les liens.

Lien vers le commentaire
Partager sur d’autres sites

Guest Hellway

Heu, je croyais que l'attribut hreflang était néccessaire uniquement si le contenu de la page pointée n'était pas dans la même langue que le contenu de la page courante ?

Je vais faire un petit tour sur pompage et hésites pas à me dire quoi dès qu'il y a du neuf sur OpenWeb.

Sinon, merci pour les astuces et à charge de revanche ;)

Lien vers le commentaire
Partager sur d’autres sites

Heu, je croyais que l'attribut hreflang était néccessaire uniquement si le contenu de la page pointée n'était pas dans la même langue que le contenu de la page courante ?

Personnellement, je le spécifie toujours, même si la destination (l'URL) est dans la même langue que la provenance (la page Web). Comme je n'ai jamais trouvé aucune documentation nulle part à cet effet me disant le contraire et que l'attribut hreflang a définitivement sa raison d'être, je me suis toujours refusé à prendre la liberté de l'utiliser seulement lors de changements de langue. J'aime mieux prévenir que guérir. <_<

Quelqu'un détient-il une information complémentaire à ce sujet ?

Lien vers le commentaire
Partager sur d’autres sites

Hum...

D'un côté, la permissivité toujours possible en HTML:

- la langue par défaut du contenu étant définie par lang="fr" (au niveau de l'en-tête par exemple)

- on peut raisonnablement supposer que la langue par défaut des cibles de lien sera la même, en l'absence d'hreflang=fr

- et on peut se contenter de signaler les changements à l'aide de hreflang="en" etc.

- et j'ai un gros doute sur le fond : je ne suis pas tout à fait sûr que Jaws et HPR implémentent hreflang ;) Quelqu'un peut confimer/infirmer ?

En tout cas, omettre les hreflang="fr" est la pratique la plus fréquente, parce que la plus simple.

Mais d'un autre côté, en XHTML :

- rien ne le justifie dans les specs car rien ne lie lang (xml:lang en XHTML) et hreflang, document source et cibles.

- c'est une source de problème à la moindre erreur (oubli d'un hreflang="en"), si l'on fait par exemple une transformation via xslt de la page source pour un tri des liens.

Comme souvent, la permissivité a un prix, celle de favoriser les erreurs en cascades et de compliquer un traitement sémantique de la page. Donc, malgré la tentation de l'économie, je serais plutôt de ton avis : hreflang "devrait" être systématiquement employé au moins en XHTML.

Modifié par LaurentDenis
Lien vers le commentaire
Partager sur d’autres sites

J'aurais dû être plus clair sur un point... quand je me prononce sur la question, je parle effectivement de XHTML, pas de HTML qui gère le tout différemment. Donc quand je déclare un lien en XHTML 1.1 (qui est mon langage de prédilection), j'utilise l'attribut hreflang avec la valeur appropriée (fr, en, es, it, etc.). Quand j'utilise un mot en anglais dans un document français par exemple, je l'entoure généralement d'un <em xml:lang="en"></em>, simplement parce que sémantiquement j'aime bien le spécifier comme ayant une emphase par rapport au reste du texte. C'est évidemment l'autre façon de spécifier le changement de langue. :idea:

Lien vers le commentaire
Partager sur d’autres sites

Guest Hellway

Oki, par contre, j'ai un petit doute. Dans mon site, il y a des articles en français, anglais, espagnol etc... Mais il n'empêche que pour un surfeur français, afficher un article en anglais n'implique pas que le menu et autres soient en anglais.

Un article en anglais peut-être signalé dans le corps du document par un ch'ti lang=fr, mais le problème, c'est que si je fait un lien vers cet article, j'ai à faire un choix entre mettre la langue du "contenu" à proprement parler (l'article en langue étrangère) ou alors, l'ossature qui elle se comporte comme pour un article français et "parle" français si j'ose m'exprimer ainsi...

Bref, encore un problème qu'il faudrait pouvoir résoudre tout en gardant un sens pour l'attribut hreflang...

:rolleyes:

Lien vers le commentaire
Partager sur d’autres sites

Oui, c'est vrai que tu marques un point là-dessus. Dans la mesure ou tu pourrais avoir une page multilingue, il y a forcément des décisions à prendre. Puisqu'il faut trancher, à ta place je me poserais la question suivante : vers quoi pointes-tu ? La structure du site ou son contenu ? Voilà qui devrait te donner une réponse pour la valeur du hreflang de ton hyperlien. :hypocrite:

Parce que honnêtement, je ne crois pas qu'il y est de vérités absolues dans un tel cas... il n'y a que des choix amenés par des réflexions éclairées.

Lien vers le commentaire
Partager sur d’autres sites

Guest Hellway

J'aurais plutôt dis l'inverse... Parceque le contenu est une partie du document et le document en lui-même est en français.

C'est un peu comme si tu pointais vers un script PHP en disant que la langue c'est PHP. Et puis, le contenu reste consultable sur le site en français et sur le site en anglais, quelquesoit la langue de l'utilisateur.

Bref, encore un mystère comme les standards et l'accessibilité savent le faire... :(

Pour amener la discussion sur une theme plus général, je pense que quitte à faire des tandards, autant les faire complets et bien descriptifs. Je trouve qu'à ce niveau, le W3C à baclé le travail. En réalité, xhtml, c'est bien, mais uniquement pour la compatibilité avec d'anciens navigateurs. Personnellement, j'aurais quand même plus penché pour un dévelloppement parallèlle d'un language beaucoup plus dévelloppé que le html standard mais qui resterai compatible xhtml.

Je pense qu'il aurait été beaucoup plus intéressant de faire des architectures de contenu entièrement standardisées. Après, les CSS auraient fait le reste. Car, personnellement, je trouve un peu idiot de procéder par étapes lorsqu'il est possible de fixer une fois pour toute un language définitif et totalement descriptif.

Lien vers le commentaire
Partager sur d’autres sites

L'oeuf ou la poule, la poule ou l'oeuf... peu importe comment on regarde le problème, on pourra toujours faire valoir nos opinions. :)

La force du Web, c'est justement d'être un médium auquel il est relativement facile de s'initier. Prendre la décision de passer directement à un langage complexe et complet aurait pour effet de purifier le Web certes, mais surout d'en exclure la presque totalité des concepteurs de pages Web. La progression par étape n'est pas seulement importante, elle est essentielle pour que le Web demeure le médium du peuple et non celui des mégacorporations.

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...