28173 sujets

CSS et mise en forme, CSS3

Pages :
(reprise du message précédent)

Laurent Denis a écrit :


une sorte de g... ? si c'est moi qu'on cherche, demain, j'afficher le bas.

<edit>edre... où est passé cette image que je la redécoupe ? sinon, j'aussi celle de ma pipe, l'interdiction de mourir du cancer du poumon en payant ses taxes à l'Etat comme tout bon citoyen m'agace aussi beaucoup, surtout que j'adore mes derniers tabacs anglais)
</>

Ne serait ce pas plutôt une sorte de Laurent horror picture show? Smiley biggol

Pour revenir sur les iframe, on peut se demander alors pourquoi cet élément
à été supprimé d'XHTML strict.
Modifié par Hermann (12 Jan 2008 - 18:47)
Laurent Denis a écrit :
Faut arrêter, là.

Vouloir éviter les iframes quand ils sont une réponse pertinente à un besoin de production est en effet stupide, sachant qu'un iframe géré en ce sens ne pose aucun problème d'accessibilé, et que cette gestion est triviale (renseigner le title, ne pas bloquer le noresize,, ni le scrolling, bref, des choses basiques du RGAA)


Tu as mal du lire ma remarque. J'ai évoqué le titre et le scrolling (oups, oublié le resize). Si le web se cantonnait à ces trois paramètres, se serait plus simple. Je le répète (je suis de bonne humeur Smiley smile ) : l'accessibilité n'est pas le principe fondamental de web, il y en a d'autres.

Mais bon, c'est pas grave.
Administrateur
bretau a écrit :
Merci pour la piste que m'a donné Felipe au sujet du reset CSS (cf. reset de E. Meyer).

Je vais étudier de près cette technique qui semble assez délicate à utiliser.

J'ai effacé mon message parce que j'avais oublié un 'détail': il est impossible d'être certain que ces règles CSS auront une priorité plus forte que celles en vigueur dans la page. Même en rajoutant 15 div imbriquées avec des id, la page pourrait en avoir 16 et la règle avec 16 id successifs ( Smiley biggol ) prendrait le dessus ...
Dans le reset CSS, c'est l'inverse: ces règles ont une priorité basse qui forment un socle sur lequel viennent se rajouter le reste des règles.
Bonsoir à tous,

Hermann a écrit :

Pour revenir sur les iframe, on peut se demander alors pourquoi cet élément
à été supprimé d'XHTML strict.


Parce qu'en mode strict iframe devrait être remplacé par object dont il n'est qu'un avatar, introduit dans Html pour des raisons de compatibilité avec les usages.

Sinon je suis comme Laurent, l'Iframe ne pose pas de problème d'accessibilité dans le cadre d'une utilisation raisonnée, malgrès une contrainte supplémentaire pour certains modes de restitution.

En tout cas, faute de pouvoir utiliser, ce qui semble être le cas, un véritable process de web services, c'est la solution la plus robuste, particulièrement en terme de maintenance.

talvins a écrit :
Un "expert" en accessibilité , c'est une personne :


Qui, au delà de l'expertise elle-même, à intégré que produire du contenu accessible c'est, avant tout, se donner les moyens de rester raisonnable.

Pour le dire autrement, plus c'est simple et raisonnable, plus c'est robuste et donc, in fine, plus ça tends vers l'accessibilité.

Ce qui exclus d'emblée, dans une perspective de production, toute improvisation technologique.

La question n'est donc pas vraiment de savoir si l'iframe est plus ou moins favorable à l'accessibilité.

Posé comme ça, ça ne veut pas dire grand chose, une iframe sera évidemment moins favorable qu'un process crédible de web services.

La bonne question est plutôt de savoir quel est le procédé le plus adapté à vos conditions de production.

De ce que je crois en comprendre l'iframe semble, dans votre cas, le plus simple et le plus raisonnable.

Et donc le plus robuste, et le plus apte à vous permettre de tendre vers l'accessibilité des contenus.

bretau a écrit :

Pour Laurent Denis, qui m'a 'brutalement' renvoyé sur les iframes, j'ai des contraintes d'accessibilité, niveau AA ou argent, donc exit les iframes.


Aucun problème de quoi que ce soit, ni pour Accessiweb Argent, ni, à fortiori, pour WCAG AA.

talvins a écrit :

Je ne parle même pas du contenu alternatif puisque, si l'iframe est vraiment nécessaire, il ne pourra peut-être pas y avoir de contenu alternatif.


On se contenteras raisonnablement, au titre de contenu alternatif, d'un lien vers la page source, surtout destiné, d'ailleurs, à la jouer "ceinture et bretelle".

Jean-Pierre
Modifié par jpv (12 Jan 2008 - 21:46)
allez pour la route j'en rajoute une couche :
Oui l'iframe peut parfaitement être accessible Smiley cligne

Pour ce qui est de l'expert accessibilité, juste une remarque, la formation accessiweb ne prétend pas former des experts accessibilité mais des "experts accessiweb en évaluation", c'est à dire des personnes normalement à même d'évaluer un site selon les critères accessiweb, pas d'en développer un ou de garantir l'obtention du label accessiweb.

a écrit :
Qui, au delà de l'expertise elle-même, à intégré que produire du contenu accessible c'est, avant tout, se donner les moyens de rester raisonnable.

Oui ou carrément de trouver la solution la moins pire quand le client lui impose des solutions incongrues (clavier virtuel, menu déroulant)
Modifié par goetsu (13 Jan 2008 - 11:29)
Hop, je rajoute aussi ma petite couche.

Je suis pour ma part pour quelque chose de raisonnable, de raisonné, d'équilibré (si si).
Ca n'est pourtant pas toujours possible.
Sur certains projets, ok cela manque de recul, mais cela vient parfois de contraintes toutes autres, de problématiques politiques ou de communication. Objectif ? avoir un tampon 'accessibilité'.
Il faut atteindre un niveau, point.
Donc certes la question est mal posée ou inversée mais c'est l'objectif qui rest important.
Bref, il faut gérer avec toutes ces contraintes et se confronter à la question de la labellisation.
J'ai vu des sites régresser, perdre de la plus-value tant ergonomique, qu'artistique ou même de fond pour arriver à obtenir ce tampon, coûte que coûte.

Ceci dit et je l'ai bien noté, correctement utilisée l'iframe est accessible.
N'empêche, c'est fou comme elle suscite de débat et de polémique.


Je finis :
pour valider en strict il faut donc utiliser la balise object mais du coup on est obligé de spécifier hauteur et largeur (sous IE) et ça c'est pas bon.

Et termine : il faut ensuite mettre en place les solutions pour le référencement.

Rebref, j'adore les frames.
bretau a écrit :
Je finis :
pour valider en strict il faut donc utiliser la balise object mais du coup on est obligé de spécifier hauteur et largeur (sous IE) et ça c'est pas bon.

Le fait d'avoir à intégrer des éléments externes via un mécanisme de type iframe est une très bonne raison pour ne pas valider en strict mais en transitional... non?
Pages :