[Resolu]DOM ET CSS: création de flottant

Salut à tous,

Une petite question sans un interet crucial mais si quelqu'un sait ça me plairait assez.
J'ai une fonction dans laquelle j'insére via le DOM un bouton dans une div qui en contient déja un.

J'applique une classe en même temps à la div pour positionner mes deux boutons cotes à cotes mais comme ils sont en flottant, ça me produit un effet assez moche:
le bouton inséré passe d'abord sous le premier, (comme si la div était trop petite), avant de se mettre en place. Voila du code pour mieux illustrer le propos:

****HTML DE BASE****
		<div>
			<input type="button" class="bouton ajouterSocieteEtiquette" onclick="addEtiquette(depart, this)" />
		</div>


****Le SCRIPT****
/*Bouton est le bouton déja présent*/
		bouton.parentNode.setAttribute('class', 'click');
		suppr = document.createElement('input');
		suppr.setAttribute('type','button');
		suppr.setAttribute('onclick','removeEtiquette(this)');
		suppr.setAttribute('class','bouton supprimerSocieteEtiquette');
		bouton.parentNode.appendChild(suppr);

/*Le CSS*/
#tabEtiquette .click input[type=button]:first-child{float: left; margin-left:200px;}
#tabEtiquette .click input[type=button]:last-child{float: right; margin-left:-800px; margin-right:200px;}

input[type=submit], .bouton
{
  width:200px;
  height:30px;
  background-color:transparent;
  font-size: 0px;
  border: none;
  margin: 5px auto;
  display: block;
  cursor: pointer;
}

La deuxième classe sur mes bouton ne sert à rien, c'est juste une image de fond.
Voilou, si ça inspire quelqu'un merci d'avance
Modifié par coccimaster (07 Aug 2006 - 09:17)

Bonjour,

coccimaster a écrit :

La deuxième classe sur mes bouton ne sert à rien, c'est juste une image de fond.

Apparemment, cette classe ajoute le pseudo-contenu du bouton avec une image-texte.

Totalement inaccessible, ça. Sans compter le onclick et l'absence de formulaire.

Je suis assez gêné par ces demandes sans aucun rapport avec les critères et les préoccupations de ce forum en matière d'accessibilité, pour tout te dire.

Autant pour moi, je n'ai pas été précis. En fait ce site est un site intranet pour une PME. C'est pour ça que je ne me préoccupe pas des histoires d'accessibilité et que je déclare des boutons graphiques dans le css, on m'a demandé pour des besoins de maintenances que les déclarations d'images soient dans un fichier unique.

a écrit :
Sans compter le onclick et l'absence de formulaire

Il n'y a pas non plus absence de formulaire, je n'ai juste pas reprodui le code en entier. Mais cela veut dire que si on modifie les éléments de la page via le DOM, les modifications ne sont pas prises en compte par les lecteurs vocaux???
Cela bannirait le javascript alors? J'avoue ne plus suivre

J'essaie malgré tout de rester le plus standart possible, mais dans la limite du cahier des charges (pas trop le choix).
Modifié par coccimaster (04 Aug 2006 - 13:20)

Bonjour

Laurent Denis a écrit :
Je suis assez gêné par ces demandes sans aucun rapport avec les critères et les préoccupations de ce forum en matière d'accessibilité, pour tout te dire.

Je suis assez surpris par cette réflexion pour tout te dire.
Peut-être faudrait-il supprimer le salon DOM, JavaScript, ECMAScript ?

Comme l'a justement souligné coccimaster, le cahier des charges auquel on est confronté ne permet pas toujours de coder accessible, et le client s'en fout la plupart du temps...

Bonsoir,

Tout d'abord, une précision: ce forum accueille des gens de tous horizons, et il n'est pas possible de savoir a priori, devant un morceau de code problématique, s'il est issu d'un choix réfléchi face à un cahier des charges, d'une méconnaissance quelconque, ou s'il s'agit de quelqu'un qui se préoccupe résolument de la question comme de son premier caleçon

Dans le premier cas, pas de problème bien entendu. Vous vous vous verrez très souvent proposer des alternatives plus accessibles (c'est le but de ce forum), mais, pour ma part, je n'ai pas de problème s'il faut vous aider à coder non accessible et non standard en cas de nécessité.

Dans le second cas, en revanche, il est important de pouvoir dire "pause" et d'informer avant de recommencer à coder.

Et dans le dernier cas, eh bien... pour tout dire, il y a quantité d'autres ressources plus appropriées sur le Web.

N'hésitez pas, donc, à préciser d'entrée de jeu dans quelle cadre vous vous placez, cela fera gagner du temps



Concernant la gestion des images: le choix initial est très discutable (sic) indépendamment de l'accessibilité, pour la robustesse de la solution. Mais ce n'est manifestement pas celui de coccimaster, et il est évident qu'il doit "faire avec", en effet.

Concernant le DOM: la prise en charge est variable, et la règle essentielle à retenir est, en effet, de ne pas s'y fier. C'est pourquoi les alternatives aux scripts restent prioritaires.

Enfin, pour le problème évoqué dans le post initial: l'application doit être relativement lourde, pour que le rendu progressif des flottants soit perceptible. Quoi qu'il en soit, cette sorte de "FOUQ" est inévitable avec float. Un recours au positionnement absolu permettrait sans doute de l'éviter, c'est à voir...

Salut,

coccimaster a écrit :
Mais cela veut dire que si on modifie les éléments de la page via le DOM, les modifications ne sont pas prises en compte par les lecteurs vocaux???

Je ne suis pas très au fait des lecteurs vocaux mais je doute qu'il y en ait beaucoup qui comprenne le DOM. C'est pourquoi ton application ne doit jamais reposer dessus pour être fonctionnelle. Le DOM n'est là que pour étendre les possibilités, améliorer l'ergonomie, etc... Cà doit rester optionnel. Par ailleurs, il vaut mieux poser des tests sur les méthodes que tu utilises afin qu'en cas d'interprétation partielle du code, il n'est pas accès à ce script.

Aussi, la bonne question à te poser, c'est:
"ce bouton est-il indispensable ?"
A priori, non. Vu qu'en plus il ne fonctionne qu'avec javascript, il n'a pas à apparaître dans la page HTML. Autrement dit, le premier bouton qui génère le second devrait lui aussi être ajouté en DOM.

coccimaster a écrit :
Cela bannirait le javascript alors? J'avoue ne plus suivre

Ericf a écrit :
Peut-être faudrait-il supprimer le salon DOM, JavaScript, ECMAScript ?

Ola... N'exagérons rien. Etre accessible ne veut pas dire qu'on dispose forcémment de toutes les fonctionnalités mais celles qui sont présentes doivent être toutes opérationnelles. Encore une fois, le javascript est un plus, çà ne doit pas être fondamental.

koala64 a écrit :
Salut,

Je ne suis pas très au fait des lecteurs vocaux mais je doute qu'il y en ait beaucoup qui comprenne le DOM.

Voir en particulier http://juicystudio.com/article/dom-screen-readers.php

koala64 a écrit :

C'est pourquoi ton application ne doit jamais reposer dessus pour être fonctionnelle. Le DOM n'est là que pour étendre les possibilités, améliorer l'ergonomie, etc... Cà doit rester optionnel.

Oui... et non
Voir http://www.boxofchocolates.ca/archives/2005/06/12/javascript-and-accessibility pour un excellent résumé de cette question, et http://www.webstandards.org/action/dstf/ pour plus de détails.
Modifié par Laurent Denis (05 Aug 2006 - 08:10)

Laurent Denis a écrit :
Oui... et non

mmh... Je ne suis pas sûr d'avoir bien compris le pourquoi du non.

Je précise avant de développer que mon niveau en anglais est excécrable mais que je m'exerce.
Va me falloir du temps pour déchiffrer tous ces articles, surtout les derniers.

A priori, si j'ai bien compris, les lecteurs font des progrès et interprètent une partie des codes JS mais ils ont actuellement besoin d'avoir les déclarations d'événements en ligne et non ajoutés via DOM. En fait, ce que je ne cerne pas bien, c'est pourquoi je suis dans le faux. En dehors de cette spécificité technique, il suffit soit d'implémenter une fonction PHP pour donner un rôle au bouton en cas de désactivation du JS soit d'ajouter le bouton via DOM auquel cas il n'apparaît pas lorsqu'on coupe le JS. Dans le premier cas, on perd un peu d'un point de vue sémantique mais on garde quand même l'ensemble des fonctionnalités même si ce n'est pas tout à fait sous la même forme... Dans le second cas, on considère que le bouton et sa fonction sont optionnels à l'application.

... donc, quelquesoit l'option choisie, le JS reste optionnel. On améliore voire on ajoute même de nouvelles fonctions mais l'application reste intègre sans. Je n'ai pas d'exemple en tête où çà me semble réellement indispensable mais, de toute façon, il reste nécessaire de prévoir une utilisation sans JS.

Où ai-je tort là dedans ? Je n'ai pas dû tout comprendre.
Modifié par koala64 (05 Aug 2006 - 14:55)

Aprés un p'tit week-end pour se reposer, je vais commencer par remercier tous les intervenants pendant mon absence.
Ensuite :

Laurent Denis a écrit :

Concernant la gestion des images: le choix initial est très discutable (sic) indépendamment de l'accessibilité, pour la robustesse de la solution. Mais ce n'est manifestement pas celui de coccimaster, et il est évident qu'il doit "faire avec", en effet.

Cette solution ne m'a pas été imposée. Ce qui m'a été demandé, c'est un fichier ou soit déclarée toute les images. Pour répondre à cette contrainte, je n'ai trouvé que deux solutions : celle-ci ou un fichier PHP avec des define. J'ai préféré la css, car elle m'évitait de déclarer autant de variables que d'images dans toutes mes pages quand il m'en fallait au plus une ou deux. J'avoue que je n'ai pas non plus creusé la question plus que ça, mais si quelqu'un à une autre méthode plus standart, je reste preneur...

Ericf a écrit :
Comme l'a justement souligné coccimaster, le cahier des charges auquel on est confronté ne permet pas toujours de coder accessible, et le client s'en fout la plupart du temps...

Je suis actuellement stagiaire
et je fais de l'intranet, les questions d'accessibilité ne se pose pas. Je vais par contre à réaliser des sites online, et j'avoue que :

1)Les premiers vont être pour moi ou des amis donc avec le temps et 0 contrainte, apprendre à faire du full-accessible me plairait bien, étant donné que je n'ai aucune expérience dans le domaine.

2)Par la suite, je risque d'avoir un client en face de moi, comme tout un chacun ici, et que si il s'en fout, même si il à le dernier mot, je ne vais pas m'empecher de lui expliquer pourquoi il faut que ce soit accessible et standart, sans angélisme car se serait inutile, mais du seul point de vue qui l'intéresse : le sien, car les avantages qu'il peut en retirer ne sont pas moindres.

Autre point, inspiré par d'autres métiers accomplis dans d'autres secteurs d'activités : nous ne sommes pas les commerciaux, mais la cheville ouvrière. Personnellement, quand le client se fourvoie par ignorance des contraintes techniques, je préfére le brusquer un peu pour le ramener à la réalité plutot que me plier à certaines lubies. Nous ne sommes pas là pour le garder sur son petit nuage. Encore une fois, c'est le rôle des commerciaux...

Enfin bref, encore une petite question de culture générale qui m'en aura plus appris que je ne l'aurais pensé, je classe le sujet comme résolu.

Merci à tous
Modifié par Laurent Denis (07 Aug 2006 - 09:44)