(reprise du message précédent)
Ah... il y avait sans doute une part d'humour dans ton premier message qui m'a échappée hier soir. Je te prie de m'en excuser. A ma décharge, je dirais cependant que l'illusion, malheureusement très répandue chez les convertis aux "standards", selon laquelle "XHTML1.0+CSS+tableless=accessible" est parfois exaspérante, surtout lorsque la fatigue s'en mêle. D'autant que cette séparation "pour le principe" perd une large partie de son utilité quand l'accessibilité n'est pas prise en compte.
L'accessibilité tient à une démarche à la fois spécifique et globale, dont la séparation du contenu et de sa présentation n'est qu'un préalable nécessaire, mais complètement insuffisant : un contenu très satisfaisant de ce point de vue peut être totalement inaccessible. Ici, sans aller jusqu'à être inaccessible, le site reste nettement en deça d'une accessibilité minimale.
Pour répondre (un peu en vrac) à tes questions :
L'utilisation des lecteurs d'écran ne doit pas être confondue avec les seuls personnes aveugles (et encore moins avec les personnes maîtrisant le braille et disposant d'une tablette braille). Dans mon cas, le lecteur d'écran vient en renfort de la navigation visuelle dont je dois autant que possible faire l'économie. Elle peut également venir se substituer à une navigation visuelle possible, mais difficile (utilisateurs d'agrandisseurs et de loupes d'écran). Et on peut penser que leur utilisation touchera un public de plus en plus large au fur et à mesure que les technologies vocales deviendront elles-mêmes plus "accessibles" techniquement et économiquement, avec les projets de lecteurs "libres" liés à des navigateurs comme Firefox, ou avec des navigateurs vocaux comme Opera. Si on y ajoute les utilisations émergentes de la synthèse vocale de confort (mobiles, "verticals"), le rendu non visuel des sites Web est de plus en plus à prendre en compte.
J'utilise personnellement un peu de tous les lecteurs disponibles, avec une nette préférence pour IBM HPR, moins puissant que Jaws, mais peut-être plus adapté à mes besoins, et pour Opera en mode vocal pour les pages anglo-saxonnes.
D'une manière générale, ce site a un contenu très abondant, difficile à appréhender sans le support visuel ( voir http://blog-and-blues.org/weblog/2005/02/02/386 ) . A ce sujet, l'utilisation des titres <h1> est à revoir, au moins en page d'accueil : cette structure "plate" presque uniquement en <h1> n'a pas de sens, et cela se ressent très fortement lorsqu'on navigue dans la page avec Jaws en mode "lecture des titres seulement" : il est impossible de comprendre l'organisation de la page en sections et sous-sections, puisque tous les titres sont au même niveau. Pour de (mauvaises) raisons liées au référencement, peut-être ?
<edit>Petite remarque amusante : l'organisation en sections serait en fait nettement plus perceptible, à défaut d'un titrage correct... si la mise en page reposait sur des tableaux minimaux, entre lesquels Jaws permettrait de naviguer facilement
</>
L'attribut title des liens peut effectivement être lu par jaws et d'autres lecteurs d'écran. Mais c'est une option qui n'est pas activée par défaut. Il faut savoir que configurer Jaws est une chose complexe, que de nombreux utilisateurs ne font pas (d'ailleurs, je ne suis pas un bon exemple d'utilisateur handicapé, étant plutôt un "powered handicaped user", alors que les utilisateurs les plus nombreux de dispositifs d'aide s'en tiennent en général par la force des choses à un usage très "élémentaire" de leurs outils.)
En outre, la lecture systématique de cet attribut peut s'avérer, selon les habitudes de chacun, plus gênante qu'autre-chose tant il est souvent mal employé. Enfin, la bonne pratique me semble ici de se conformer au rôle de cet attribut tel qu'il est définit en HTML : il apporte une information additionnelle, qui doit donc pouvoir être omise. Ce n'est pas un équivalent textuel, contrairement à l'attribut alt qui sera, lui, systématiquement pris en compte par les dispositifs de rendu.
Dans le même ordre d'idée, d'ailleurs, ta page d'accueil utilise un lien "Lire la suite" et 3 liens "Suite" : rien ne les différencie lorsqu'ils sont extraits de leur contexte, c'est à dire par exemple lorsqu'on navigue avec un lecteur d'écran de lien en lien dans la page. Un lien qui m'est lu "lien : suite" est inutilisable
Les meilleures solutions consistent :
- soit à expliciter ces intitulés, comme on le fait (trop rarement hélas) sur certains weblogs (voir le mien)
- soit à les déplacer sur les titres de news (comme dans les pages de sommaires d'Openweb) .
Faute d'employer l'une ou l'autre de ces 2 solutions, force est de se rabattre sur le title du lien pour expliciter celui-ci. Mais en sachant, comme expliqué ci-dessus, que l'efficacité de cette précision sera très limitée.
Plus généralement, les intitulés de liens de ce site sont souvent mal restitués par Jaws, en raison de leur texte lui-même un peu ésotérique (Voir la recommandation de base d'accessibilité sur l'emploi d'un langage simple et clair). Mais on atteint sans doute les limites de ce qu'il est possible d'expliciter sans remettre complètement en question le "vocabulaire culturel" lié au sujet du site.
Un détail plus amusant sur les intitulés de liens explicites : parmi les liens vers les items du forum, "WeSh Tro D Bel Go vIeNdEz sUr mOn siTe" est encore plus dénué de sens dans un rendu vocal que pour le malheureux visiteur "voyant" non adepte du SMS Mais, là, c'est le très délicat problème des contenus créé par les visiteurs... qu'on ne maîtrise donc que très difficilement, à moins de pouvoir leur imposer une discipline très stricte, comme nous pouvons le faire sur ce forum. Ce serait évidemment beaucoup trop rébarbatif sur le forum de ton site. Le problème est donc tout simplement insoluble.
Pour en finir avec les liens, le problème de ton menu d'accès direct au contenu et au menu principal du site : étant donné que le "contenu" est précédé d'un long menu, ces liens d'accès direct sont très appréciables. Ou plutôt, seraient très appréciables s'ils étaient restitués par Jaws En effet, l'utilisation du "display:none" a des effets souvent mal maîtrisés sur les lecteurs d'écran, dépendant du navigateur graphique, et qu'on peut résumer en disant : cacher une information à l'écran revient dans de très nombreux cas à la cacher aux lecteurs d'écran.
Deux solutions à envisager :
- au minimum, utiliser une des techniques de masquage supposée plus accessible telle que la technique de Bohman (voir http://blog-and-blues.org/weblog/2004/06/10/239 ) Mais en sachant qu'elles peuvent à leur tour des problèmes aux handicapés moteur navigant par tabulation, à cause de la perte de focus visuel lorsque celle-ci atteint le lien "sorti de l'écran".
- mieux, ne pas masquer ce lien ; solution simple, mais qui fait hélas souvent grimper le graphiste aux rideaux.
Merci pour les attributs alt corrigés Mais attention : il ne faut pas hésiter à "abstraire" complètement une image avec un alt="" lorsqu'elle n'apporte pas d'information "fonctionnelle" et qu'une description brève mais précise serait sans doute difficile à gérer systématiquement. Le fait, par exemple, de savoir qu'il y a dans cette page une "photo de la une" n'est pas obstructif ni bien gênant, mais prête à sourire : me voilà bien avancé en ayant "entendu" cela !
En revanche, "retourner à la page d'accueil" est bien approprié. De même, "get firefox" et "download opera" décrivent bien l'action que je peux accomplir... mais le feront beaucoup mieux en français Au moins, ajouter la mention lang="en" sur l'élément image, afin de faciliter le changement de langue pour les lecteurs d'écran (bien qu'ils n'exploitent pas tous cet attribut). Idem pour les liens en fin de page.
Je ne suis pas allé très avant dans le reste du site, mais une remarque sur les formulaires : les <labels> perdent une très grande partie de leur utilité en l'absence de lien explicite avec les champs concernés, via l'attribut for= . Voir la FAQ du forum à ce sujet.
D'autres problèmes devraient être corrigés pour que le site atteigne un niveau minimal d'accessibilité : les contrastes de couleur très insuffisants (le graphiste va encore nous faire une syncope, je sais ), l'absence de plan de site, etc. Voir le référentiel accessiweb qui te donnera les pistes nécessaires : http://www.accessiweb.org/fr/Label_Accessibilite/criteres_accessiweb/92_accessiweb_lineaire/
Enfin, une remarque sur la validité HTML :
Cette structure, qui n'est curieusement pas relevée par le validateur W3C (en raison de l'<object> d'ailleurs inutile), est invalide : contrairement à <script>, <noscript> est un élément de niveau bloc qui ne peut être placé dans un élément <a>, pas plus que <div>. Il faut séparer script et noscript en deux sections totalement indépendantes.
En espérant que ce petit (
) hors-sujet te soit utile
Modifié par Laurent Denis (01 Aug 2005 - 09:28)
Ah... il y avait sans doute une part d'humour dans ton premier message qui m'a échappée hier soir. Je te prie de m'en excuser. A ma décharge, je dirais cependant que l'illusion, malheureusement très répandue chez les convertis aux "standards", selon laquelle "XHTML1.0+CSS+tableless=accessible" est parfois exaspérante, surtout lorsque la fatigue s'en mêle. D'autant que cette séparation "pour le principe" perd une large partie de son utilité quand l'accessibilité n'est pas prise en compte.
L'accessibilité tient à une démarche à la fois spécifique et globale, dont la séparation du contenu et de sa présentation n'est qu'un préalable nécessaire, mais complètement insuffisant : un contenu très satisfaisant de ce point de vue peut être totalement inaccessible. Ici, sans aller jusqu'à être inaccessible, le site reste nettement en deça d'une accessibilité minimale.
Pour répondre (un peu en vrac) à tes questions :
L'utilisation des lecteurs d'écran ne doit pas être confondue avec les seuls personnes aveugles (et encore moins avec les personnes maîtrisant le braille et disposant d'une tablette braille). Dans mon cas, le lecteur d'écran vient en renfort de la navigation visuelle dont je dois autant que possible faire l'économie. Elle peut également venir se substituer à une navigation visuelle possible, mais difficile (utilisateurs d'agrandisseurs et de loupes d'écran). Et on peut penser que leur utilisation touchera un public de plus en plus large au fur et à mesure que les technologies vocales deviendront elles-mêmes plus "accessibles" techniquement et économiquement, avec les projets de lecteurs "libres" liés à des navigateurs comme Firefox, ou avec des navigateurs vocaux comme Opera. Si on y ajoute les utilisations émergentes de la synthèse vocale de confort (mobiles, "verticals"), le rendu non visuel des sites Web est de plus en plus à prendre en compte.
J'utilise personnellement un peu de tous les lecteurs disponibles, avec une nette préférence pour IBM HPR, moins puissant que Jaws, mais peut-être plus adapté à mes besoins, et pour Opera en mode vocal pour les pages anglo-saxonnes.
D'une manière générale, ce site a un contenu très abondant, difficile à appréhender sans le support visuel ( voir http://blog-and-blues.org/weblog/2005/02/02/386 ) . A ce sujet, l'utilisation des titres <h1> est à revoir, au moins en page d'accueil : cette structure "plate" presque uniquement en <h1> n'a pas de sens, et cela se ressent très fortement lorsqu'on navigue dans la page avec Jaws en mode "lecture des titres seulement" : il est impossible de comprendre l'organisation de la page en sections et sous-sections, puisque tous les titres sont au même niveau. Pour de (mauvaises) raisons liées au référencement, peut-être ?
<edit>Petite remarque amusante : l'organisation en sections serait en fait nettement plus perceptible, à défaut d'un titrage correct... si la mise en page reposait sur des tableaux minimaux, entre lesquels Jaws permettrait de naviguer facilement
</>L'attribut title des liens peut effectivement être lu par jaws et d'autres lecteurs d'écran. Mais c'est une option qui n'est pas activée par défaut. Il faut savoir que configurer Jaws est une chose complexe, que de nombreux utilisateurs ne font pas (d'ailleurs, je ne suis pas un bon exemple d'utilisateur handicapé, étant plutôt un "powered handicaped user", alors que les utilisateurs les plus nombreux de dispositifs d'aide s'en tiennent en général par la force des choses à un usage très "élémentaire" de leurs outils.)
En outre, la lecture systématique de cet attribut peut s'avérer, selon les habitudes de chacun, plus gênante qu'autre-chose tant il est souvent mal employé. Enfin, la bonne pratique me semble ici de se conformer au rôle de cet attribut tel qu'il est définit en HTML : il apporte une information additionnelle, qui doit donc pouvoir être omise. Ce n'est pas un équivalent textuel, contrairement à l'attribut alt qui sera, lui, systématiquement pris en compte par les dispositifs de rendu.
Dans le même ordre d'idée, d'ailleurs, ta page d'accueil utilise un lien "Lire la suite" et 3 liens "Suite" : rien ne les différencie lorsqu'ils sont extraits de leur contexte, c'est à dire par exemple lorsqu'on navigue avec un lecteur d'écran de lien en lien dans la page. Un lien qui m'est lu "lien : suite" est inutilisable
Les meilleures solutions consistent :- soit à expliciter ces intitulés, comme on le fait (trop rarement hélas) sur certains weblogs (voir le mien)
- soit à les déplacer sur les titres de news (comme dans les pages de sommaires d'Openweb) .
Faute d'employer l'une ou l'autre de ces 2 solutions, force est de se rabattre sur le title du lien pour expliciter celui-ci. Mais en sachant, comme expliqué ci-dessus, que l'efficacité de cette précision sera très limitée.
Plus généralement, les intitulés de liens de ce site sont souvent mal restitués par Jaws, en raison de leur texte lui-même un peu ésotérique (Voir la recommandation de base d'accessibilité sur l'emploi d'un langage simple et clair). Mais on atteint sans doute les limites de ce qu'il est possible d'expliciter sans remettre complètement en question le "vocabulaire culturel" lié au sujet du site.
Un détail plus amusant sur les intitulés de liens explicites : parmi les liens vers les items du forum, "WeSh Tro D Bel Go vIeNdEz sUr mOn siTe" est encore plus dénué de sens dans un rendu vocal que pour le malheureux visiteur "voyant" non adepte du SMS
Mais, là, c'est le très délicat problème des contenus créé par les visiteurs... qu'on ne maîtrise donc que très difficilement, à moins de pouvoir leur imposer une discipline très stricte, comme nous pouvons le faire sur ce forum. Ce serait évidemment beaucoup trop rébarbatif sur le forum de ton site. Le problème est donc tout simplement insoluble.Pour en finir avec les liens, le problème de ton menu d'accès direct au contenu et au menu principal du site : étant donné que le "contenu" est précédé d'un long menu, ces liens d'accès direct sont très appréciables. Ou plutôt, seraient très appréciables s'ils étaient restitués par Jaws
En effet, l'utilisation du "display:none" a des effets souvent mal maîtrisés sur les lecteurs d'écran, dépendant du navigateur graphique, et qu'on peut résumer en disant : cacher une information à l'écran revient dans de très nombreux cas à la cacher aux lecteurs d'écran. Deux solutions à envisager :
- au minimum, utiliser une des techniques de masquage supposée plus accessible telle que la technique de Bohman (voir http://blog-and-blues.org/weblog/2004/06/10/239 ) Mais en sachant qu'elles peuvent à leur tour des problèmes aux handicapés moteur navigant par tabulation, à cause de la perte de focus visuel lorsque celle-ci atteint le lien "sorti de l'écran".
- mieux, ne pas masquer ce lien ; solution simple, mais qui fait hélas souvent grimper le graphiste aux rideaux.
Merci pour les attributs alt corrigés
Mais attention : il ne faut pas hésiter à "abstraire" complètement une image avec un alt="" lorsqu'elle n'apporte pas d'information "fonctionnelle" et qu'une description brève mais précise serait sans doute difficile à gérer systématiquement. Le fait, par exemple, de savoir qu'il y a dans cette page une "photo de la une" n'est pas obstructif ni bien gênant, mais prête à sourire : me voilà bien avancé en ayant "entendu" cela !En revanche, "retourner à la page d'accueil" est bien approprié. De même, "get firefox" et "download opera" décrivent bien l'action que je peux accomplir... mais le feront beaucoup mieux en français
Au moins, ajouter la mention lang="en" sur l'élément image, afin de faciliter le changement de langue pour les lecteurs d'écran (bien qu'ils n'exploitent pas tous cet attribut). Idem pour les liens en fin de page.Je ne suis pas allé très avant dans le reste du site, mais une remarque sur les formulaires : les <labels> perdent une très grande partie de leur utilité en l'absence de lien explicite avec les champs concernés, via l'attribut for= . Voir la FAQ du forum à ce sujet.
D'autres problèmes devraient être corrigés pour que le site atteigne un niveau minimal d'accessibilité : les contrastes de couleur très insuffisants (le graphiste va encore nous faire une syncope, je sais
), l'absence de plan de site, etc. Voir le référentiel accessiweb qui te donnera les pistes nécessaires : http://www.accessiweb.org/fr/Label_Accessibilite/criteres_accessiweb/92_accessiweb_lineaire/Enfin, une remarque sur la validité HTML :
<div id="xiti-logo"><p>
<a href="http://www.xiti.com/xiti.asp?s=133624" title="Mesurez votre
audience">
<script type="text/javascript">
...
</script>
[b]<object>
<noscript>
<div id="xiti-logo-noscript">[/b]
Mesure d'audience ROI frequentation par <img width="39" height="25"
src="http://logv24.xiti.com/hit.xiti?s=133624&p=" alt="Analyse
d'audience" />
</div>
</noscript>
</object>
</a>
</p></div>
Cette structure, qui n'est curieusement pas relevée par le validateur W3C (en raison de l'<object> d'ailleurs inutile), est invalide : contrairement à <script>, <noscript> est un élément de niveau bloc qui ne peut être placé dans un élément <a>, pas plus que <div>. Il faut séparer script et noscript en deux sections totalement indépendantes.
En espérant que ce petit (
) hors-sujet te soit utile Modifié par Laurent Denis (01 Aug 2005 - 09:28)
