1174 sujets

Accessibilité du Web

Bonjour,

Je poste dans le forum accessibilité, j'espère que c'est le bon endroit. Ca concerne surtout la désactivation de javascript (qui peut aussi être volontaire pour des raisons de sécurité)


Je bute sur un conflit entre deux notions que je veux respecter à priorité égale: l'utilisation sans javascript et avoir un site Restful

Actuellement je suis Restful. Pour simplifier par rapport à ce qui concerne la question, je respecte bien la règle GET = consultation, POST = modification.

Je suis en train de spécifier le travail à fournir pour rendre mon application utilisable sans javascript.

Prenons une liste d'utilisateurs, avec en face de chaque utilisateur un ensemble d'actions possibles qu'on va limiter à 2: consulter et supprimer

Dugenou Marcel consulter supprimer
Mortadelle Raymonde consulter supprimer
...

La consultation est une action en lecture sur la ressource, j'ai donc un GET. Je m'en sors avec un anchor. Jusqu'ici c'est parfait.

La modification est par contre une action en écriture. Je dois faire un POST.

Comment ça marche actuellement? (avec javascript)

Et bien j'ai le code suivant pour l'action de suppression de l'utilisateur d'id 123:


<form id="mainform" method="POST" action="">
	...
	<a href="#" onclick="postAction('/suppr/123/')">Supprimer</a>
	...
</form>


La fonction postAction affecte l'action demandée au formulaire et soumet ce formulaire. Je récupère bien côté serveur une requête de type POST pour ma demande de suppression, c'est ce que j'attends.

Pour rendre ça accessible sans javascript, on pense tout de suite à remplacer l'anchor par un submit et mettre l'action là où elle doit se trouver, c'est à dire dans l'attribut action du form.


<form method="POST" action="/suppr/123/"><input type="submit" value="Supprimer" /></form>


On se retrouverait avec autant de formulaires que d'actions. C'est un peu crado et très lourd si c'est multiplié par 100 mais au moins ça règlerait le problème en apparence.

Là où ça se complique... c'est que j'ai aussi des champs cachés dans mon formulaire principal (je passe sur leur signification) C'est à dire qu'en vrai j'ai:


<form id="mainform" method="POST" action="">
	<input type="hidden" name="unparametre" value="blabla" />
	...
	<a href="#" onclick="throwAction('/suppr/123/')">Supprimer</a>
	...
</form>


Il est bien sûr inconcevable de recopier ce champ caché dans 100 formulaires.

Je ne peux pas non plus changer la gestion de ces champs cachés (par exemple en les mettant en session) car je veux qu'ils soient enregistrés si je bookmark ma page ou si je joue avec l'historique.

Je refuse bien sûr toute gestion en GET du type: <a href="/suppr/123/">Supprimer</a> (je veux rester Restful et je veux mes champs cachés)


Bref! Je suppose que ce n'est pas une problèmatique si rare et en fait je ne trouve pas de solution propre donc je m'en remets à vous: Quelles sont les best practices sur le sujet?

Merci pour votre aide! Smiley smile
Bonjour,

Je pense que c'est un problème de conception. Normalement on créer le site de façon à ce qu'il marche sans javascript. Le javascript est là pour l'habillage à la fin. Ce qui fait que tu ne perds pas de temps. Malheureusement tu as conçu ton site à l'inverse.

Sans en connaitre plus sur ton site je ne vois malheureusement pas qu'elle piste pouvoir te donner.

Pour ce qui est du Restful, je crois que tu as mal compris le principe. Les navigateurs utilisateurs utilisant mal le http le principe du REST ne peut s'appliquer uniquement que d'un serveur à un autre. exemple lien supprimer en GET -> serveur front de réception des message (schema routing et compagnie, vérification des droits) -> requete POST vers serveur gérant la base de donnée.

C'est plus comme ça que je le vois, c'est là que le REST est utile et pas autrement. Il faut pas faire du REST juste pour un effet de mode comme le XML il y a 5 ans (il y a eu vraiment de tout est n'importe quoi à l'époque), base de donnée XMl sur un système non natif xml et blablabla...

Bon courage Smiley cligne
masseuro a écrit :
Je pense que c'est un problème de conception. Normalement on créer le site de façon à ce qu'il marche sans javascript. Le javascript est là pour l'habillage à la fin. Ce qui fait que tu ne perds pas de temps. Malheureusement tu as conçu ton site à l'inverse.

Ca ne fait pas trop avancer le schmilblick et surtout c'est assez faux: Là je pars d'un site existant (en fait c'est une application web) mais je me poserais les mêmes questions en commençant un nouveau projet.

masseuro a écrit :
Sans en connaitre plus sur ton site je ne vois malheureusement pas qu'elle piste pouvoir te donner.

C'est une application web, pas un site. L'application a 5 ans et nous sommes en train de lui donner un bon coup de jeune. On pourrait penser que dans ce type d'application les utilisateurs sont bien maîtrisés et que l'accessibilité est secondaire. Ce n'est pas le cas, principalement lorsqu'on travaille avec les collectivités qui ont des exigences élevées.

J'ai volontairement ultra simplifié les exemples pour aller à l'essentiel mais ils suffisent à décrire le problème en l'état.

masseuro a écrit :
Pour ce qui est du Restful, je crois que tu as mal compris le principe

Là je suis vexé Smiley lol
Ce n'est pas parce que je simplifie pour aller à l'essentiel que je n'ai pas compris un truc. Je pense que je pourrais écrire longtemps sur le sujet, ou sur la manière d'implémenter l'absence de PUT et DELETE dans un navigateur mais ce n'est pas le but ici donc j'oublie que je suis vexé.

Alors, pour simplifier à outrance et aller à l'essentiel:

==> Je ne veux pas qu'un lien en GET pointe sur la modification d'une ressource.

Ce n'est pas vraiment un effet de mode étant donné que c'est un principe que j'applique depuis 10 ans. Les caches et autres bookmarks sous toutes leurs formes existent depuis toujours.
Modérateur
Bonjour,

J'imagine qu'en Javascript, avant que la suppression soit effective, il y a un message demandant confirmation à l'utilisateur? Si tel est le cas, je crois que pour respecter les mêmes conditions sans Javascript, c'est-à-dire :

- Demande de confirmation de suppression à l'utilisateur
- Suppression des données avec POST

Tu pourrais appliquer le principe suivant :

SOLUTION A
L'icône ou le lien pour supprimer amène l'utilisateur (en GET) dans une page secondaire avec un résumé des données qui seront supprimées. Dans cette page secondaire, il y aura un formulaire en POST pour supprimer l'enregistrement en question.

Reste à voir ce qui concerne les champs cachés qui se retrouvent dans la page principale. Je ne peux pas m'avancer, car je ne connais pas leur utilité dans ton projet. À la limite, tu pourrais les transmettre dans l'url pour faire les aller-retour (page principale et page secondaire) afin de les conserver.

SOLUTION B
Une autre solution serait d'englober ta liste dans un seul form, avec tes champs cachés et tout, et de donner des noms significatifs aux boutons submit qui permettent de supprimer chaque enregistrement. Vulgairement :


Données Ligne 1 : <input type="submit" id="Supprimer_Record_1" name="Supprimer_Record_1" ... />

Données Ligne 2 : <input type="submit" id="Supprimer_Record_2" name="Supprimer_Record_2" ... />


Lorsque le formulaire est soumis par l'un de ces inputs, ton script serveur scan avec une expression régulière les éléments envoyés (en POST) pour détecter l'action effectuée. Si le script détecte un "Supprimer_Record...", c'est qu'il y a eu une demande de suppression, et grâce au nom du input, tu peux récupérer le id à supprimer.

Je ne peux pas vraiment aller plus en détail, je dois retourner bosser. Smiley cligne

Bonne continuation!
@ Tony Monast

Merci pour tes propositions.

J'ai pensé à la solution A. En effet elle s'applique bien dans la grande majorité des cas et c'est celle sur laquelle je comptais me rabattre si je ne trouve pas mieux.

Dans le cas de mon exemple de suppression, elle est même la meilleure solution car je dois quoi qu'il arrive demander une confirmation avant suppression et je dois donc trouver une alternative au confirm javascript.

Pour un "site" ça serait d'ailleurs suffisant et j'appliquerais ça à toutes les actions. De plus j'aime l'idée qu'un utilisateur soit conscient que son action apporte une modification de données et que ça ne se passe pas dans son dos.

Malheureusement j'ai une appli avec de nombreuses interactions complexes du fait de règles métiers un peu lourdes (ça je ne le maîtrise pas) et dans l'optique de "gagner des clicks" et d'améliorer la fluidité d'utilisation, je ne peux pas mettre une confirmation derrière chaque action.
Un exemple que je trouve parlant: J'ai certains documents qui à l'ouverture sont notés comme étant lus par l'utilisateur en cours. C'est une action de modification (la base de données est mise à jour) mais si je mets un message de confirmation à l'ouverture de chaque document je me fais insulter quotidiennement par les utilisateurs.

Cependant, comme l'utilisation de javascript correspond malgré tout à un mode dégradé je ne rejette pas complètement cette éventualité. Mais ça pénaliserait vraiment les utilisateurs car ce genre d'action il y en a toutes les minutes.


Pour la solutions B:

Ca semble tout bête comme solution, je me demande même pourquoi je n'y ai pas pensé.
En fait je sais: c'est parce que je pars du principe qu'il doit n'y avoir qu'un submit par formulaire: Dans mon idée, le submit est le bouton qui déclenche un POST du formulaire lorsqu'on appuie sur Entrée. C'est peut-être là que j'ai tort.
Est-ce vraiment admis d'avoir plusieurs submit dans un même formulaire?
Si oui, effectivement ça règle mon problème en deux coups de cuillère à pot car je n'ai qu'à modifier le rendu HTML de mes actions sans toucher au fonctionnement général du formulaire.
Modérateur
saucissonsec a écrit :

Est-ce vraiment admis d'avoir plusieurs submit dans un même formulaire?


Oui, puisque c'est à la fois valide et les navigateurs le supportent bien. Il faut toutefois savoir qu'en appuyant sur ENTER lorsque le formulaire a le focus, c'est normalement le premier bouton Submit qui se trouve dans le code HTML du formulaire qui est envoyé. Pour éviter qu'une action non désirée soit déclenchée en appuyant sur Enter, tu peux mettre un input submit en haut du formulaire qui ne fait rien de particulier. À la limite, tu peux le cacher en CSS. Attention, de mémoire, si tu le mets en display:none, le navigateur agira comme s'il n'était pas là.
OK, là j'apprends un truc. Je pensais vraiment que ce n'était pas toléré.

Bref, ça répond parfaitement à mon problème. J'enverrai un feedback lorsque j'aurais vraiment implémenté le truc mais voila comme je compte finalement faire:

En mode javascript:
Comme avant: Je change en javascript l'action du formulaire et je mets éventuellement un message de confirmation avant.

En mode non javascript:
j'affiche un submit à la place de l'anchor avec le système que tu décris. Et pour la confirmation je rajoute une case à cocher sur la même ligne.

En faisant comme ça les modifications à apporter à l'existant sont légères et surtout très localisées, ce qui me va très bien. (bon, il y a un nouveau mécanisme de récupération de l'action déclenchée mais c'est pas la mort)

Merci beaucoup!
Modérateur
Une dernière chose. Tu peux sans problème mettre plusieurs <input type="submit" ...> dans un même formulaire, et il sera facile de savoir lequel a été utilisé lors de la soumission du formulaire. Par contre, si tu souhaites utiliser des <button type="submit" ...>, IE6 n'envoi pas seulement le button cliqué, mais aussi tous les autres <button> Donc aucun moyen de savoir lequel a été utilisé. Va savoir pourquoi... Smiley rolleyes
Modifié par Tony Monast (21 Jul 2009 - 16:47)
a écrit :
==> Je ne veux pas qu'un lien en GET pointe sur la modification d'une ressource.

Si tes craintes sont liés à la sécurité d'une telle manoeuvre, il y a moyen de sécuriser ça plus ou moins correctement. C'est courant aujourd'hui, je trouve que tu t'imposes une énorme limitation. Ton problème serait rapidement résolu si tu faisais sauter cette contrainte, qui ne joue absolument aucun rôle sur l'accessibilité, et qui est, à mon sens, superflue.


Sinon pour ton problème, je pense que le plus simple est une liste déroulante multiple ou pas, et deux boutons submit modifier et supprimer. L'avantage de la site déroulante multiple est que tu peux supprimer plusieurs enregistrements en une seule opération. Pratique pour faire le tri...

Et puis pour le confirm javascript, c'est pas dramatique si tu en utilises : si javascript est désactivé, il n'y aura pas de demande de confirmation mais il sera tout de même possible d'effectuer la suppression. Puisque le formulaire est utilisable sans javascript, il n'y a aucun problème. La confirmation est juste là pour le confort d'utilisation, ce qui correspond bien à la raison d'être théoriquement principale de javascript.