Bonjour Samia, bonjour à tous, Je trouve qu'il s'agit d'un cas d'école, qui illustre parfaitement les limites, et donc l'étendue, de l'intervention d'un vérificateur de la conformité aux référentiels.
Romain a parfaitement raison: il y a des situations où le recours à un attribut class n'est pas possible; ou alors au prix de contorsions tellement poussées que le coût (mesurable) n'en compense pas les bénéfices (intangibles). Dit autrement: une décision projet factuelle amènerait à rejeter la proposition. Outre l'exemple cité par Romain: le cas où les CSS sont mutualisées entre plusieurs sites, et toute modification passe par une revue de code pointue, avec comité et tout le fatras. Ou, plus fréquent hélas: les CSS sont tellement alambiquées que toute modfication devient périlleuse. Laurent a également raison. On aura des situations utilisateur où l'attribut class nous facilitera la vie par rapport à l'attribut style. Néanmoins, ceci ne sera vrai que si la CSS est correctement utilisée par ailleurs. Imaginons que ton développeur, zélé mais peu habile en CSS, colle une classe différente sur chaque élément, plus des id, et qu'il combine class et id pour styler séparément chaque élément. Nous voilà bien avancés: c'est encore plus compliqué à personnaliser... Pourtant on a bien respecté cette bonne pratique. Moralité: prendre une BP isolée ne répond pas forcément au problème. Il faut embarquer toutes les autres, relatives aux CSS. Là on commence à apercevoir l'engrenage. C'est bien beau de pointer du doigt cet attribut style qui défigure le code HTML. Mais sait-on accompagner efficacement notre développeur aux doigts gourds dans sa quête de la CSS idéale? Pour avoir codé de la CSS à la mimine une paire d'années, je sais que je ne sais rien, ou presque, dans ce domaine. Une vraie bonne CSS n'est pas à la portée de tout le monde. Ce pourrait être un métier à part, tant c'est complexe et spécifique. Une fois que tu auras moqué son approche, sauras-tu auditer avec autant d'efficacité la solution qu'il aura adoptée? Sauras-tu défendre d'autres corrections, qui cette fois dépassent largement la seule question binaire "style vs. class"? D'ailleurs, je me moque (gentiment) de ton développeur, mais rien ne dit qu'il ne sait pas ce qu'il fait: cf. les exemples où l'attribut style se justifie. Personnellement, je ne me risque pas à apprendre leur métier à des gens qui ont une vision bien plus large que ce que le trou de serrure du test d'accessibilité m'autorise à voir. Par ailleurs, en préconisant ce type de modification pour des raisons d'accessibilité, et Laurent l'exprime très justement: on sort du cadre douillet de la conformité pour s'aventurer dans les grands espaces de l'optimisation. D'ailleurs cette parenté sonore entre "confort" et "conformité" n'est peut-être pas le fruit du hasard, après tout. Et j'applaudis des deux mains! Je rêve que l'on puisse faire ça pour tout le monde, tout le temps. Car pourquoi s'arrêter en si bon chemin? Pourquoi se limiter à chouchouter les quelques utilisateurs qui personnalisent leurs styles? Elargissons les zones de clics! Renforçons les indicateurs de prise de focus! Peaufinons les alternatives d'images, les textes de liens, pour être bien sûrs que les mots importants soient regroupés au début... Plus les mille autres optimisations ciblées que l'on peut imaginer. Je rêve d'un monde où l'on peut faire ça. Mais dans le monde où je vis, on passe beaucoup de temps à négocier pour, déjà, mettre un attribut alt; à quémander un sous-titrage qui ne représente pourtant qu'1% du coût réel de la vidéo; à réclamer un titre de page qui ne soit pas juste le nom du site sur toutes les pages. Tout ça pour dire qu'avant d'optimiser, il faut s'être assuré que l'essentiel est bien là. Sinon c'est comme mettre de la dorure sur des planches pourries. Donc (et je reclarifie car par expérience mon propos sera déformé et mal interprété, statistiquement c'est inévitable): oui à l'optimisation, mille fois oui. Mais pas avant d'avoir fait l'essentiel. Autre question à se poser: en tant qu'auditeur, suis-je armé pour aller sur ce terrain? Le certificat EAE, aussi exigeant et prestigieux soit-il, n'est pas en soi un sésame pour cela. Il faut un bagage technique et une expérience qui vont bien au-delà. De plus, on peut avoir toute la compétence nécessaire, certains l'ont; ils sont rares, mais ils existent. Mais pour autant, on n'a pas forcément le budget pour ça. Un audit de conformité, de nos jours, est compétitif, et donc vendu, pour 2-3 j/h, maxi. Si on se pique d'optimisation, il va falloir multiplier ce temps pour bien couvrir tous les cas. Inventer ses propres tests. Convoquer des utilisateurs en situation de handicap. Faire du test A/B. Evaluer les compromis pied à pied. Et ça ce n'est rien: que dire du temps que passeront les développeurs à embarquer cette couche d'optimisation, surtout s'ils sont déjà loin du premier seuil de conformité... Encore une fois: je vote pour, tant que ce n'est pas au détriment de l'essentiel. Et cet essentiel, c'est ce que l'on doit aux utilisateurs. JPV l'a très justement rappelé dans une discussion-fleuve sur cette liste: un référentiel est un compromis. Par définition, un compromis est imparfait, puisque c'est le croisement des exigences, et donc la recherche du moins pire. Mais ce moins pire est toujours préférable à la recherche d'un mieux pour certains au désavantage d'autres. Cordialement, *Olivier Nourry* Twitter: @OlivierNourry <http://twitter.com/#!/OlivierNourry> Le 4 décembre 2012 16:05, Romain Gervois <[email protected]> a écrit : > Bonjour Laurent, > > Je te l'accorde, j'ai évacué un peu vite le problème des styles > utilisateur. D'ailleurs ça ne me semble pas forcément problématique (tant > que la priorité aux styles utilisateur reste possible ; le seul souci de > l'attribut style étant lié à la priorité). > > La bonne pratique Opquast que tu cites me laisse assez perplexe, je > l'avoue. Dans le sens, où il est tout à fait possible de toujours se passer > de l'attribut style (même sur des données calculées via Javascript) en > déportant vers un élément style placé dans head (après si il y a besoin de > conserver côté serveur comme évoqué ça peut se faire assez aisément via > AJAX ou même lors d'un retour formulaire). Je ne dois pas encore bien > comprendre le concept de qualité mais j'y travaille :P. > > Romain > > > Le 4 décembre 2012 15:27, Laurent Denis <[email protected]> a > écrit : > > Bonjour, >> >> Si je peux risquer un avis disons plus large ? >> >> S'il ne s'agit en effet pas d'accessibilité au sens normatif (WCAG), >> ce n'est pourtant pas étranger à cette problématique. >> >> D'une part, l'adaptation d'un rendu à un contexte et à des besoins >> utilisateur est une des clé de l'accessibilité. Un rendu géré autant >> que possible via des classes CSS au lieu de style inline facilite et >> étend considérablement cette adaptation. On le voit aisément par >> exemple quand on adapte des rendu à des demandes d'utilistaurs via des >> CSS locales gérées à l'aide d'une extension comme Stylish pour >> Firefox. >> >> D'autre part, au delà de l'accessibilité au sens strict, c'est un >> atout pour la réutilisabilité des contenus et leur adaptation au sens >> plus large selon les médias. >> >> C'est d'ailleurs pourquoi cela a été retenu parmi les bonnes pratiques >> du référentiel Opquast : >> BP 156 : Les styles en ligne sont utilisés de manière appropriée. >> Précision apportée dans le moyen de contrôle de la BP : la bonne >> pratique doit être invalidée en présence de tout attribut style, sauf >> si les valeurs des propriétés CSS qu'il contient sont calculées à la >> volée par un script Javascript (par exemple, la valeur d'un width, >> celle d'un top dans le cas d'un positionnement, etc.). Si cette valeur >> ne peut pas être écrite à l'avance dans une CSS externe et appliquée à >> l'aide d'une classe ou d'un identifiant, le test est validé. >> https://checklists.opquast.com/fr/opquastv2 >> >> >> Un exemple : la prise en compte de cette bonne pratique lors de la >> réalisation de plugins ou d'éléments de frameworks js est >> particulièrement utile (qui n'a jamais pesté devant l'obligation de >> faire du lourd en js pour adapter les CSS inline d'un plugin au lieu >> de se contenter d'une simple surcharge CSS, faute de classe appropriée >> ?) >> >> S'il n'y a effectivement pas lieu d'en faire une exigence >> d'accessibilité au sens le plus strict (dans le cadre des méthodes >> d'application WCAG), je dirais cependant que c'est loin d'être une >> question à exclure. C'est aussi un exemple intéressant du besoin, dans >> certains cas au moins, de contextualiser l'accessibilité normative en >> la replaçant dans le grand bain de la qualité Web ;-) >> >> Cordialement, >> Laurent Denis >> -- >> Temesis >> http://temesis.com >> >> Le 3 décembre 2012 18:46, Romain Gervois <[email protected]> a >> écrit : >> > >> > Bonjour, >> > >> > Bon rien à voir avec l'accessibilité comme dit précédemment. Par >> contre, je >> > suis très curieux de la déclaration : "l'usage de l'attribut style est >> une >> > mauvaise pratique (ou n'est pas une bonne pratique)". >> > >> > Si, je vous suis l'idéal c'est un élément avec attribut class. Hum soit. >> > Donc en contexte outil de gestion de contenus techniquement ça veut >> dire : >> > >> > - générer via DOM un élément style dans l'élément head avec une classe >> > (sélecteur + propriétés) pour l'aperçu direct ; >> > - appliquer cette classe à l'élément sélectionné par le rédacteur ; >> > - passer par XmlHttpRequest pour fournir cette nouvelle règle et >> impacter la >> > feuille CSS concernée ; >> > - gérer les évolutions (suppression des classes n'étant plus utilisées >> - ça >> > doit être de la bonne pratique ça...). >> > >> > PS : on peut aussi imaginer la gestion des classes en base de données >> si on >> > aime jouer avec SQL. >> > >> > Sérieusement, vous préconiseriez une telle conception juste pour une >> > position de "Oh, des propriétés de style dans la source HTML, c'est >> sale !" >> > ? Moi pas. Même si ça fait un joli développement à réaliser. >> > >> > La seule question à se poser est "Est-ce que je laisse la possibilité à >> mon >> > rédacteur de personnaliser tout et n'importe quoi ?" . Si la réponse >> est oui >> > alors l'attribut style est tout à fait adapté et répond exactement au >> besoin >> > exprimé. >> > >> > Bonne soirée. >> > Romain >> > >> > Le 3 décembre 2012 18:06, Victor Brito <[email protected]> a >> écrit : >> > >> >> Du point de vue des bonnes pratiques, encore une fois, nous sommes >> >> d'accord. >> >> >> >> Victor >> >> >> >> Victor Brito Intégrateur XHTML / CSS – Expert Accessiweb en évaluation >> >> >> >> 39 rue Charles Laffitte 92200 Neuilly-sur-Seine Tél. : 06 03 15 89 57 >> >> >> >> Consulter le site Web professionnel de Victor Brito >> >> >> >> Sur les réseaux sociaux >> >> >> >> Suivre Victor Brito sur Identi.ca >> >> Suivre Victor Brito sur Twitter >> >> Suivre Victor Brito sur FriendFeed >> >> Suivre Victor Brito sur Diaspora >> >> >> >> Sans oublier >> >> >> >> La fiche de membre du Groupe de Travail Accessiweb >> >> Halte à la balkanisation du Web ! >> >> Un seul Web >> >> Profession intégrateur (X)HTML / CSS >> >> >> >> Le 03/12/12 18:04, [email protected] a écrit : >> >> >> >> Merci. >> >> Bien failli exiger "à tort". >> >> Mais je trouve cette pratique plutôt "amatrice", sur le plan strict des >> >> bonnes pratiques et du savoir-faire web. >> >> Samia >> >> >> >> ----- Mail original ----- >> >> De: "Victor Brito" <[email protected]> >> >> À: "liste gta" <[email protected]> >> >> Envoyé: Lundi 3 Décembre 2012 17:31:10 >> >> Objet: Re: [Liste GTA] CSS/html >> >> >> >> >> >> >> >> >> >> >> >> Bonsoir, Samia, bonsoir, la liste, >> >> >> >> >> >> Les critères d'accessibilité n'interdisent pas le recours à des styles >> CSS >> >> en ligne (déclarations CSS contenues dans l'attribut HTML style), même >> s'il >> >> est toujours préférable de déclarer les règles CSS dans des fichiers >> CSS >> >> externes (factorisation du code, maintenabilité, mise en cache, etc.). >> >> >> >> >> >> L'exemple que tu cites est parfaitement valide du point de vue >> >> accessibilité (pas de détournement d'éléments ni de recours à des >> éléments >> >> ou attributs HTML de présentation pour créer les marges). >> >> >> >> >> >> Victor >> >> >> >> >> >> >> >> Victor Brito Intégrateur XHTML / CSS – Expert Accessiweb en évaluation >> >> >> >> >> >> 39 rue Charles Laffitte 92200 Neuilly-sur-Seine Tél. : 06 03 15 89 57 >> >> >> >> Consulter le site Web professionnel de Victor Brito Sur les réseaux >> >> sociaux >> >> >> >> >> >> * Suivre Victor Brito sur Identi.ca >> >> * Suivre Victor Brito sur Twitter >> >> * Suivre Victor Brito sur FriendFeed >> >> * Suivre Victor Brito sur Diaspora >> >> Sans oublier >> >> >> >> >> >> * La fiche de membre du Groupe de Travail Accessiweb >> >> * Halte à la balkanisation du Web ! >> >> * Un seul Web >> >> * Profession intégrateur (X)HTML / CSS >> >> Le 03/12/12 17:27, [email protected] a écrit : >> >> >> >> >> >> Bonjour la liste, >> >> >> >> Avant d'aller enquiquiner le presta web, qui commence à me trouver bien >> >> "chipoteuse" (!!)... >> >> >> >> Lorsque l'on a ça (la possibilité de générer des marges via l'éditeur >> >> html/insertion d'image): >> >> >> >> <img class="media-image" width="675" height="250" alt="" src= >> >> "http://nomdusite.net/sites/default/files/nom-image.jpg"; >> style="margin-top: >> >> 10px; margin-bottom: 10px;"> >> >> >> >> ...on ne peut pas prétendre travailler dans les bonnes pratiques, ni >> dans >> >> le respect des critères d'access. >> >> . >> >> Les marges doivent être stylées côté CCS. Et ils doivent supprimer les >> >> fonctionnalités inutiles dans l'éditeur. >> >> >> >> Merci pour le retour. >> >> >> >> Samia >> >> >> >> _______________________________________________ >> >> liste_gta mailing list [email protected] >> >> >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> >> >> >> _______________________________________________ >> >> liste_gta mailing list >> >> [email protected] >> >> >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> >> >> >> _______________________________________________ >> >> liste_gta mailing list >> >> [email protected] >> >> >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> >> >> >> >> >> >> >> _______________________________________________ >> >> liste_gta mailing list >> >> [email protected] >> >> >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> >> >> > >> > >> > _______________________________________________ >> > liste_gta mailing list >> > [email protected] >> > >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> > >> >> _______________________________________________ >> liste_gta mailing list >> [email protected] >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> > > > _______________________________________________ > liste_gta mailing list > [email protected] > http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org > >
_______________________________________________ liste_gta mailing list [email protected] http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
![http://nomdusite.net/sites/default/files/nom-image.jpg"](http://nomdusite.net/sites/default/files/nom-image.jpg"){kind=link}