Images-textes dans CSS ou balise <img> ?

Bonjour,

Je conseille, à titre bénévole, une petite collectivité dans la conception de son futur site web : depuis l'établissement du cahier des charges, jusqu'aux vérifications des maquettes et du produit fini livré par le prestataire professionnel retenu.

Nous avons bien entendu intégré très tôt, dès la rédaction du cahier des charges, les exigences d'accessibilité. J'ai suivi avec attention les publications des WCAG 2.0 et du RGAA avec lequel je base mon travail sur l'accessibilité du site.

Mes compétences de dev web sont celles d'un amateur éclairé : bonne connaissance pratique du HTML, je comprends les CSS, j'ai les bases en Javascript, la connaissance des bases du DOM, pratique la programmation php, le balisage sémantique... Bref, même si je n'ai sûrement pas le niveau d'un pro, je suis capable d'en comprendre le langage, ce qui me permet de dialoguer avec le prestataire et d'analyser les techniques qu'il emploie dans la réalisation du site.

Pour analyser les pages web livrées (encore en phase de conception), j'utilise les outils suivants :
- Extension Web developper pour FF
- Firebug
- La Firefox Accessibility Extension
- Un outil d'analyse de contraste de couleurs
- L'extension Fangs (FF)

Comme la page d'accueil qu'on nous a livré pèse au total 974 Ko (oui, oui, et c'est fait par des pros...), j'ai essayé de voir comment est structurée la présentation de la page :
- 712 Ko rien que pour les images (au nombre de 57 !)

comme je ne veux pas être long, je vais tout de suite au but :
Sur les 57 images, on trouve 17 images-textes (!), 6 boutons graphiques, 5 images-textes pour les titres des onglets, 9 images pour le fond pour la page, le fond de certains blocs..., je ne détaille pas le reste.

Sur les 17 + 5 images-textes, on a :
- Les liens d'évitement
- Les liens de navigation principaux (onglets)
- Des titres de rubriques pour le bloc contenu de la page
- Des titres d'articles (!)
- La date de publication des articles (!)

Le problème en plus du poids lié à des images dont on pourrait se passer à mon avis (à condition de pouvoir réaliser l'équivalent en CSS) est que l'alternative textuelle est représentée dans le code par quelque chose qui me semble bizarre et pour lequel je voudrais votre avis :

Voici un exemple :

<ul id="menu-principal">
<li class="element-menu-principal-1">
<a title="Votre Mairie" href="-Votre-Mairie-">
<span> Votre Mairie </span>
</a>
</li>
</ul>

Un extrait CSS

#menu-principal li.element-menu-principal-1 a {
background-image:url(header_menu1.png);
width:145px;

a span {
display:none !important;
}

Pour moi, premier problème :
- Pas de balise <img> dans le code HTML donc pas d'attribut alt
- Le texte "alternatif" dans le span est rendu invisible par la CSS

Du coup, si on désactive les images en laissant la feuille de style, on perd l'information du span (puisque masqué par CSS) en même temps que l'image. Donc un internaute qui déciderait de désactiver les images (en laissant la feuille de style) ne perçoit plus les liens de navigation principale.
Si c'est un non-voyant, la feuille de style étant désactivée, le span apparaît dans le code et le lien est perceptible.

Cette façon de procéder me paraît mauvaise (j'ai le même genre de chose pour les liens d'évitement)... Qu'en pensez-vous ?

Salut,

Cette façon de procéder EST mauvaise, html portant le contenu, css portant la forme, il est aberrant de faire porter le contenu par css. Donc oui, une image dans le code html avec un attribut alt dûment renseigné est bien mieux, même en terme d'accessibilité.
Comme exemple :
Que se passe-t-il selon toi si tu n'affiche pas les images ? Tu n'as pas l'image de ton bouton et la partie textuelle étant masqué, il est impossible de voir le lien, et encore moins de cliquer dessus.
Ils ne doivent pas beaucoup se soucier de l'accessibilité pour faire des choses pareilles.

974ko, c'est un peu énorme, je pense qu'ils n'ont pas pris la peine de compresser les images pour le web, et qu'il devrait être possible de le faire sans qu'optiquement le site n'en soit altéré. Tu parle du site encore en phase de conception, il faudrait en discuter avec le prestataire, peut être qu'il ne l'a pas fait justement parce que le site n'est pas fini ?

Bonjour et bienvenue,

HS : être pro signifie être rémunéré pour son travail, c'est différent d'un travail de mauvaise qualité (et dans ce cas il faut argumenter sinon ce serait de la diffamation si tu citais le prestataire) /HS

Le poids de la page (1 Mo !) est un problème général, pas spécifiquement un problème d'accessibilité.

Les titres d'article en image et les dates vont immédiatement empêcher toute mise à jour ou création du contenu, encore que les dates avec 31+12+xx images on peut les reconstruire en images . J'espère qu'il y a dans le CdC une ligne "le client doit pouvoir mettre à jour le contenu lui-même" ... ou que le bon sens prévaudrat.
Les liens d'évitement euh est-ce une fonte particulière hors des 7-8 fontes "websafe" (qu'on trouve sur Mac, Linux et Win) ? Verdana, Arial ou Times dans un bloc flottant et c'est jamais plus compliqué que ça.
Les rubriques et surtout les onglets en images c'est pas choquant par contre.

Pour plâtrer la situation actuelle sans résoudre le fond du problème tu as des outils d'optimisation d'images (YSlow, OptiPNG) mais bon là il faut vraiment résoudre d'autres problèmes de fond avant de s'intéresser à ça (d'où ton sujet pleinement justifié).
Modifié par Felipe (25 Oct 2009 - 17:01)

a écrit :
Si c'est un non-voyant, la feuille de style étant désactivée, le span apparaît dans le code et le lien est perceptible.

NON ! IL n'est pas perceptible. Display:none s'applique à tout le monde, y compris les lecteurs d'écran.
Par contre, ce manque est compensé par un title sur le lien. C'est pas génial génial, mais ça marche.
De ce fait, ce span devient complètement inutile avec son display:none...

Merci pour vos avis.

Je vais en discuter avec le prestataire. Le site étant encore en dev c'est le moment d'avancer des arguments.
Je vais pousser pour obtenir des textes à la place des images-textes comme les titres d'articles ou de rubrique dans le contenu principal de la page.
Je pense garder les onglets en images ainsi que les titres de rubriques dans la colonne droite de la page. Par contre, je vais leur demander si les images sont déjà compressées au maximum sans altération visible du rendu.

En ce qui concerne le problème des <span> rendues invisibles par CSS et représentant l'alternative textuelle, j'ai trouvé une solution ici :

http://www.ideose.eu/documents-accessibilite/utilisation-des-css-rendre-invisible-un-contenu-necessaire-aux-utilisateurs-de-lecteurs-decrans/printpage/

Il suffit de positionner le contenu hors de l'écran, ainsi un lecteur d'écran le lira. Qu'on désactive les images et/ou la feuille de style, le contenu reste perceptible en toutes circonstances.

Pour les liens d'évitement, voici le rendu d'un d'entre eux :


Et pour une des images-titres :

Vu le nom de l'image (5375aa98ff0115394bf6983e43d17f0e.png), c'est sûrement généré à la volée ?

Pour un titre de section (dans la partie droite) :

Là, je comprends mieux qu'on travaille avec une image, surtout pour le background

La même chose ou à peu près (pour les liens d'évitement et les images titres) est-elle réalisable avec les CSS (juste une image de background à mettre pour l'agenda et définir la police et la couleur, le texte étant dans le code HTML)? ç'est très proche de la police georgia il me semble ?

<span> : sans les images mais avec les CSS rien n'est visible dans un navigateur standard. Mais c'est la moins pire des solutions puisque cela reste lisible par les non-voyants et fonctionne dans tous les autres cas).

images générées à la volée : oui on dirait bien.
Syndrome du "ohlala il y a 1px de décalage entre Photoshop et le navigateur, c'est horriiiible".
Ça arrange l'accessibilité si les alt sont correctement renseignés (et attention aux caractères sortis de Word ou les accents, autant pour la génération du titre que pour le alt) mais il reste un problème de performance (nombre de hits sur le serveur lors de l'affichage d'une page, poids de la page) et de "pourquoi faire simple quand on peut faire compliqué"
Modifié par Felipe (26 Oct 2009 - 16:41)

sgod51 a écrit :
La même chose ou à peu près (pour les liens d'évitement et les images titres) est-elle réalisable avec les CSS (juste une image de background à mettre pour l'agenda et définir la police et la couleur, le texte étant dans le code HTML)? ç'est très proche de la police georgia il me semble ?

C'est ultra-simple et comme tu l'as décrit :

#menu {
background: white url(fond_degrade.png) left top repeat-x;
font-family: georgia,serif;
}

#menu h2.agenda {
/*line-height et padding */
}

#menu h2.agenda a {
color: blue;
background: url(picto_calendrier.png) left top no-repeat;
padding-left: 30px;
text-decoration: none;
}

#menu h2.agenda a:hover {
text-decoration: underline;

En mettant le fond sur le lien et pas le titre, le picto est cliquable, pas que le texte.
Et pas grand monde ne remarquera si c'est Georgia, Times ou autre serif ...
Modifié par Felipe (26 Oct 2009 - 16:49)

sgod51 a écrit :
En ce qui concerne le problème des <span> rendues invisibles par CSS et représentant l'alternative textuelle, j'ai trouvé une solution ici :

http://www.ideose.eu/documents-accessibilite/utilisation-des-css-rendre-invisible-un-contenu-necessaire-aux-utilisateurs-de-lecteurs-decrans/printpage/

Il suffit de positionner le contenu hors de l'écran, ainsi un lecteur d'écran le lira. Qu'on désactive les images et/ou la feuille de style, le contenu reste perceptible en toutes circonstances.

périmé. La problématique n'est pas d'opposer simplement affichage CSS et lecteurs d'écrans. Les paramétrages de navigateurs et les aides techniques ont différents moyens de masquer une image CSS tout en continuant à masquer un contenu en le déplaçant en dehors de l'écran.

Rester simple: contenu = image HTML.
Modifié par Laurent Denis (26 Oct 2009 - 18:29)

a écrit :
Laurent Denis a écrit :
Rester simple: contenu = image HTML.

OK, mais comment puis-je faire pression sur le prestataire pour qu'il adopte ce principe, en évoquant le cahier des charges de l'accord de contrat par lequel il s'engage à respecter la séparation Forme/contenu ?

Je crains que le degré de séparation n'y soit pas suffisamment explicite (voici un extrait des conditions particulières) :

XXXXXXXX s'engage à respecter les points essentiels suivants :
1) la séparation contenu/forme
2) l'utilisation exclusive de langages et technologies recommandées par le W3C
3) le développement de CSS de compatibilité multi plate-formes
4) l'utilisation de langages particuliers, type javascript, par appel de fichier externe à la page
5) le respect des sémantiques web par balisage XHTML Transitional standardisé 1.0
6) la mise en place d'outlis de navigation clavier (tabindex, accesskey, etc.)
7) le respect des 47 critères Accessiweb niveau bronze
8) le respect des points décrits à la section XXX qui sont la mise en oeuvre du RGAA
9) la compatibilité avec les principaux systèmes d'exploitation et les navigateurs du marché ainsi qu'avec les principaux navigateurs d'appareils mobiles

D'après vos remarques, et vu les pages qu'on me propose actuellement, j'en déduis que nous n'avons pas été assez explicite dans le point n°1, il aurait fallu écrire (mais c'est hélas trop tard, car c'est signé) :

1) La séparation TOTALE du contenu et de la forme
En particulier, si une partie du contenu est présent sous forme d'images-textes :
- soit le contenu textuel véhiculé par ces images est transformé en texte (code HTML) et mis en forme (code CSS)
- soit l'image est inclue dans le code HTML (balise <img>) moyennant le renseignement d'un attribut alt conformément au RGAA dans sa version connue au jour de la mise à disposition en ligne du site

Il me semble, à moins que j'ai mal interprété la chose ou mal lu, que le RGAA ne contre-indique pas la pratique du <span> mise en oeuvre dans mon cas (si bien sûr les problème de la visibilité est résolu comme indiqué dans les posts qui précèdent).

Dans ce cas, ça se résume à un conseil de bonne pratique (et de bon sens je le concède) mais qui n'oblige en rien mon prestataire à procéder de la sorte, si le contenu reste accessible fut-ce par une méthode périmée.

D'où ma question sur le moyen de pression...

Par contre, là où je peux davantage être en positon de force, c'est en ce qui concerne le javascript car j'en ai dans le code des pages fournies et il y a aussi des gestionnaires d'évènements définis par onclick (ce qui va à l'encontre du point 4 de l'accord...)

C'est pénible de devoir vérifier le code, mais nécessaire. Je dois vraiment passer pour un chiant, cela peut se comprendre : un amateur qui remet en cause le code fait par un pro, ça a du mal à passer... Mais je ne fais pas cela pour dénigrer le travail, simplement pour que le site soit conforme à ce qui a été prévu, on peut discuter technique quand même avec un prestataire, cela est bénéfique pour tout le monde quand c'est fait de façon constructive. Mais je ne peux pas imposer une bonne pratique si celle-ci n'est pas explicitement dans le contrat.

sgod51 a écrit :
6) la mise en place d'outlis de navigation clavier (tabindex, accesskey, etc.)

Accesskey, l’essai non transformé de l’accessibilité par Laurent Denis.
Et mieux vaut remettre en cause l'organisation d'un site ou d'une page plutôt que de commencer à utiliser les tabindex : au moindre faux pas dans la numérotation la page devient un peu incompréhensible, c'est le dernier recours ...

sgod51 a écrit :
7) le respect des 47 critères Accessiweb niveau bronze
8) le respect des points décrits à la section XXX qui sont la mise en oeuvre du RGAA

RGAA [Présentation] 3 correspondrait nan ?
AW 1.1 Critère 1.9 aussi mais c'est du niveau Argent (une police "websafe" transformée pour le plaisir en image, sans aucune fioriture, invalide le test 1.9.a puisque du texte irait aussi bien)

sgod51 a écrit :
C'est pénible de devoir vérifier le code, mais nécessaire. Je dois vraiment passer pour un chiant, cela peut se comprendre : un amateur qui remet en cause le code fait par un pro, ça a du mal à passer... Mais je ne fais pas cela pour dénigrer le travail, simplement pour que le site soit conforme à ce qui a été prévu, on peut discuter technique quand même avec un prestataire, cela est bénéfique pour tout le monde quand c'est fait de façon constructive. Mais je ne peux pas imposer une bonne pratique si celle-ci n'est pas explicitement dans le contrat.

Tu n'es pas là pour faire plaisir mais pour conseiller des non-spécialistes qui dépensent de l'argent public sur un truc censé durer plusieurs années. Tant que c'est constructif et que tu ne passes pas en mode gros lourd (non, non, c'est nul, non, ...) et reste poli ^^

sgod51 a écrit :

D'après vos remarques, et vu les pages qu'on me propose actuellement, j'en déduis que nous n'avons pas été assez explicite dans le point n°1, il aurait fallu écrire (mais c'est hélas trop tard, car c'est signé) :

1) La séparation TOTALE du contenu et de la forme
En particulier, si une partie du contenu est présent sous forme d'images-textes :
- soit le contenu textuel véhiculé par ces images est transformé en texte (code HTML) et mis en forme (code CSS)
- soit l'image est inclue dans le code HTML (balise <img>) moyennant le renseignement d'un attribut alt conformément au RGAA dans sa version connue au jour de la mise à disposition en ligne du site

L'intégration Web, comme beaucoup de choses, ne progresse pas de manière linéaire, mais plutôt selon un mouvement de balancier:
* dans un premier temps, on truffait le contenu de paramètres de présentation
* dans un second temps, on comprend qu'il faut utiliser CSS pour ne plus mettre de présentation dans le contenu
* mais le balancier va plus loin et on se met à sur-exploiter CSS en y mettant du pseudo-contenu (et puis cela semble très élégant et à première vue pratique)
* le balancier va petit à petit revenir vers l'équilibre et une utilisation correcte des différents formats

Il faut donc, actuellement, souvent mettre les prestataires en garde contre certains risques encourus de bonne foi.

sgod51 a écrit :

Il me semble, à moins que j'ai mal interprété la chose ou mal lu, que le RGAA ne contre-indique pas la pratique du <span> mise en oeuvre dans mon cas (si bien sûr les problème de la visibilité est résolu comme indiqué dans les posts qui précèdent).

Dans ce cas, ça se résume à un conseil de bonne pratique (et de bon sens je le concède) mais qui n'oblige en rien mon prestataire à procéder de la sorte, si le contenu reste accessible fut-ce par une méthode périmée.

Dans la quasi-totalité des cas (masquage du contenu textuel en déplaçant hors de la zone de visualisation, il invalidera le test RGAA 7.3.[Présentation] Lisibilité des informations affichées comme fond d'éléments via les styles CSS lorsque les styles et/ou les images sont désactivés : la désactivation des images laisse un grand grand blanc, le texte restant masqué.

sgod51 a écrit :

D'où ma question sur le moyen de pression...

A priori, vous l'avez via le RGAA.

Bonjour,

En amont:

1. Avant même de demander au prestataire d'utiliser des éléments IMG avec attribut alt qui vont bien, il faut voir si certains textes en images ne pourraient pas être passés en texte brut stylé en CSS. Il faudrait le faire pour le plus d'éléments possibles, et il faudrait également que les CSS gèrent l'agrandissement en hauteur de certains éléments en cas de changement de la taille du texte.

2. C'est bien d'identifier les moyens de pression contractuels pour amener un prestataire à corriger son travail. Mais dans un premier temps, demander les corrections sans user du bâton serait pas mal.

Et aussi: la séparation du contenu et de la mise en forme, c'est à mes yeux plus une méthodologie qu'un objectif en soi. On peut rappeler ce principe, mais les objectifs définis devraient être autres: référentiel d'accessibilité, référentiel qualité web, etc.

a écrit :
Florent V. a écrit :

C'est bien d'identifier les moyens de pression contractuels pour amener un prestataire à corriger son travail. Mais dans un premier temps, demander les corrections sans user du bâton serait pas mal.

Dans mon esprit, pas question d'utiliser le bâton d'emblée. Il s'agit simplement de pouvoir négocier de façon équitable pour les 2 parties dans le respect des exigences contractualisées de l'un et du travail de l'autre.
Savoir qu'on est parfaitement dans les clous dans la demande de correction par rapport au contrat permettra de mieux lever les réticences éventuelles. Il est en effet inutile d'essayer de demander un supplément de travail pour le même prix, dès lors que l'on dépasse ce qui a été explicitement écrit dans l'accord initial.
Il est bien sûr possible de faire des avenants moyennant une augmentation du coût lié à des prestations complémentaires, car c'est difficile de pouvoir tout prévoir au départ.

En tout état de cause, La négociation amiable est toujours à privilégier, et est d'autant plus facile à mener si on reste dans le cadre du contrat, sans que cela entraîne pour le client un coût supplémentaire.

a écrit :
Et aussi: la séparation du contenu et de la mise en forme, c'est à mes yeux plus une méthodologie qu'un objectif en soi. On peut rappeler ce principe, mais les objectifs définis devraient être autres: référentiel d'accessibilité, référentiel qualité web, etc.

Bien sûr. Mais la séparation entre contenu et forme (et comportement par la même occasion) est à mon sens un objectif qui est un élément (parmi tant d'autres) de la qualité web : un code de qualité est plus facile à maintenir et à faire évoluer, donc le coût lié à cette évolution sera moins élevé a priori.
Cela dit, faire du code propre en respectant les règles de l'art, ne signifie pas garantir pour autant un bon niveau d'accessibilité et de qualité de service, il faut évidemment orienter les développements du code en s'appuyant sur les référentiels dont vous faites état.