HTML5/CSS3 et lecteurs d'écrans

Bonjour,

Suite à l'excellent article sur le site et pour un projet personnel, je m'intéresse à une problématique toute bête, mais qui vaut son montant de cacahuète :
- HTML 5 est il compatible avec les lecteurs d'écrans ? en effet une problématique d'accessibilité est très importante dans notre projet

Merci,

HTML5 n'étant, du point de vue accessibilité, pas encore mûr, s'abstenir (hors projets expérimentaux sans obligation d'accessibilité) est un choix raisonnable.

Pour CSS3, le problème est identique à celui de CSS2.1 : ce n'est pas la technologie qui est éventuellement en cause, mais uniquement ses usages.

<humour>

Il n'est d'ailleurs pas nécessaire de recourir à HTML5 ou à CSS3 pour casser l'accessibilité minimale d'une page web. cela se fait très bien en XHTML1.0 et CSS2.1, avec par exemple http://www.jcommaret.fr/

(contenus générés CSS, inaccessibilité au clavier, utilisation impropre des niveaux de titrage, etc.)

</humour>

Plus sérieusement : si vous intéressez à l'accessibilité dans le cadre de vos projets, il vous faudra passer par une méthode d'évaluation du standard WCAG (Accessiweb, RGAA) et une montée en compétence dans ce domaine. Le chemin peut être long, mais il toujours riche en surprises intéressantes, et il est toujours profitable pour la qualité globale de vos projets. Il est a priori trop tôt pour expérimenter HTML5, à la fois en raison de l'inachèvement de celui-ci et de cette nécessaire montée en compétence préalable.
Modifié par Laurent Denis (10 Mar 2010 - 10:08)

a écrit :
- HTML 5 est il compatible avec les lecteurs d'écrans ? en effet une problématique d'accessibilité est très importante dans notre projet

Il n'est ni plus ni moins accessible que HTML4/XHTML1.0 et CSS2.

Par contre, si tu veux parler spécifiquement des innovations apportées par HTML5, comme la structuration qu'il propose (<header> <nav> <footer> etc), la réponse est que pour le moment, 10 mars 2010, cela n'apporte strictement rien par rapport à une page en HTML4 ou XHTML1.0 déjà accessible. En revanche, on peut espérer que d'ici quelques années, quand HTML5 se sera démocratisé, les lecteurs d'écran pourront aussi en profiter. Peut-être pour jaws 12, ou 13... IE 9, ou 10... firefox 4... l'avenir est trop incertain pour savoir.

On peut noter que parmi les nouvelles fonctionnalités apportées par HTML5, il y a:
- des fonctionnalités «sémantiques» qui sont un gain potentiel pour l'accessibilité (mais pas une amélioration concrète avec les outils actuels);
- des fonctionnalités dont l'accessibilité est problématique, comme Canvas.

et quid de la non obligation de l'attribut alt ? remplacé par <figure> peut être... ? Ca semble encore assez flou d'après ce que j'ai pu en lire.

Mikachu a écrit :
et quid de la non obligation de l'attribut alt ? remplacé par <figure> peut être... ? Ca semble encore assez flou d'après ce que j'ai pu en lire.

Figure ne défini pas la même chose et je pense que pour le moment, il est préférable de conserver le alt, d'autant plus que la spec HTML5 est encore en Working Draft, les choses peuvent encore changer (comme l'absence de l'attribut longdesc pour les images).
Modifié par Hermann (10 Mar 2010 - 14:04)

Hermann a écrit :
il est préférable de conserver le alt

D'autant plus qu'obligation ou non, cela restera une bonne pratique

a écrit :
et quid de la non obligation de l'attribut alt ? remplacé par <figure> peut être... ? Ca semble encore assez flou d'après ce que j'ai pu en lire.

Ce sont deux choses différentes. <figure> est un élément qui permet de regrouper une image et un texte qui lui est associé et qui complète l'image, alors qu'alt est un texte de remplacement. Le premier sera toujours visible, alors que le second n'est visible que dans certains cas bien particuliers.

Par contre, ce qu'il ne faudra pas faire, c'est mettre le même texte dans le alt que dans figure. C'est un doublon inutile voire exaspérant. Remarque, certains n'ont pas attendu figure pour déjà faire cette erreur : doublon entre le texte du alt et le même texte situé dans un p en-dessous de l'image... dans ce cas mieux vaut mettre un alt vide.
Modifié par Hermann (10 Mar 2010 - 16:22)

Tomas a écrit :
D'autant plus qu'obligation ou non, cela restera une bonne pratique

Sauf que l'attribut alt manquant était signalé par le validateur, maintenant il ne le sera plus.
Donc je crains qu'il ne devienne vite optionnel pour les gens peu scrupuleux de ce genre de choses, et qui s'en souciaient peut être un minimum auparavant pour se targuer d'avoir un site "valide".

QuentinC a écrit :
Ce sont deux choses différentes. <figure> est un élément qui permet de regrouper une image et un texte qui lui est associé et qui complète l'image, alors qu'alt est un texte de remplacement. Le premier sera toujours visible, alors que le second n'est visible que dans certains cas bien particuliers.

Dans un sens si toutes les images d'un sites sont entourées d'un <figure>, l'information reste toujours accessible à moins que le concepteur ne lui colle un display:none, ou j'en passe...
N'est-ce pas finalement un moyen d'inviter à légender une image dans le document pour tout le monde et non plus uniquement dans l'attribut alt uniquement pour ceux qui ne peuvent lire l'information que par ce biais ?
Enfin peut être que je me trompe, mais dans mes lectures diverses sur le net, il me semble bien avoir interprété cela, peut être à tort.

a écrit :
N'est-ce pas finalement un moyen d'inviter à légender une image dans le document pour tout le monde et non plus uniquement dans l'attribut alt uniquement pour ceux qui ne peuvent lire l'information que par ce biais ?

Pas forcément. Les images fonctionnelles, qui servent de bouton par exemple, n'ont pas d'intérêt à avoir un figure associé. Par contre l'alt est de mise.

Mikachu a écrit :
Dans un sens si toutes les images d'un sites sont entourées d'un <figure>, l'information reste toujours accessible à moins que le concepteur ne lui colle un display:none, ou j'en passe...
N'est-ce pas finalement un moyen d'inviter à légender une image dans le document pour tout le monde et non plus uniquement dans l'attribut alt uniquement pour ceux qui ne peuvent lire l'information que par ce biais ?
Enfin peut être que je me trompe, mais dans mes lectures diverses sur le net, il me semble bien avoir interprété cela, peut être à tort.

Disons qu'on réduit déjà la question aux images illustratives et aux images de contenu et qu'on évacue les boutons, icônes, etc. Disons aussi qu'on applique aventureusement les techniques WCAG2.0 prévues pour HTML4.01/XHTML1.0 à HTML5, et qu'on oublie le problème des implémentations.

Le cas-type, c'est wikipédia où depuis longtemps une image de contenu ou illustrative (un thumb dans le jargon) doit être légendée.

Une légende amène à deux cas de figure possibles selon WCAG:
* la légende reproduit l'information véhiculée par l'image: celle-ci doit avoir un attribut ALT qui indique la localisation de la légende. Si, si. L'avantage, c'est que ça s'automatise très facilement.
* la légende ne reproduit pas l'information véhiculée par l'image. celle-ci étant donnée à voir pour elle-même (puisqu'elle est légendée), il lui faut non seulement un ALT synthétique mais aussi une description étendue. or, longdesc est mort en HTML5. Donc on revient à des descriptions étendues immédiatement adjacentes à l'image, c'est à dire au cas de figure précédent. Il faut donc expliquer aux rédacteurs qu'ils doivent non seulement légender leurs images, mais aussi le faire d'une manière qui leur paraîtra effroyablement redondante avec celle-ci, éditorialement idiot et inacceptable (et je ne parle pas seulement des sites collaboratifs web2.0 du type Wikipédia pour ce genre de réaction des rédacteurs)...

Après, si on pousse le vice jusqu'à faire de l'image un lien vers sa version agrandie, comme wikipédia, ça devient plus amusant : l'alternative doit également permettre d'identifier la cible de ce lien. Mais peut-être peut-on faire quelque-chose d'habile avec ARIA.

Comme quoi, ce n'est pas mûr, au moins du côté des méthodes d'application

je ne sais pas pour vous, mais moi, aujourd'hui, je ne sais pas faire du HTML5 accessible (en production).
Modifié par Laurent Denis (10 Mar 2010 - 17:57)

Merci pour ces réponses précises et rapides , ce n'est pas sur mon site que je vais faire de l'accessibilité, mais pour autre chose, je sais que mon portfolio n'est pas accessible

Laurent Denis a écrit :
je ne sais pas pour vous, mais moi, aujourd'hui, je ne sais pas faire du HTML5 accessible (en production)

En prenant un site HTML4 accessible, et en remplaçant juste le doctype? Hop, du HTML5 accessible.
Modifié par Florent V. (10 Mar 2010 - 23:02)

Laurent Denis a écrit :
* la légende reproduit l'information véhiculée par l'image: celle-ci doit avoir un attribut ALT qui indique la localisation de la légende.

Si la légende est juste en-dessous de l'image, c'est pas un peu stupide et redondant de dire que la légende est en-dessous dans le alt ? Dans un tel cas je mettrais un alt vide tout simplement...

Je prends un exemple : si j'ai une image représentant un graphique complexe
alt : <vide>
légende : « évolution des ventes en 2010 » avec un lien « détails » vers le tableau des chiffres si on veut, faisant office de longdesc

Je vois pas où est l'erreur ? Mettre un alt non vide dans un tel cas me paraît inutilement redondant... par contre on en a besoin si on retire la légende.

QuentinC a écrit :
si tu veux parler spécifiquement des innovations apportées par HTML5, comme la structuration qu'il propose (<header> <nav> <footer> etc), la réponse est que pour le moment, 10 mars 2010, cela n'apporte strictement rien par rapport à une page en HTML4 ou XHTML1.0 déjà accessible. En revanche, on peut espérer que d'ici quelques années, quand HTML5 se sera démocratisé, les lecteurs d'écran pourront aussi en profiter.

Hello,

Toutes les lectures que j'ai pu avoir sur le sujet avaient effectivement ce genre de conclusion (et je suis content que tu sois également de cet avis) : en gros, à l'heure actuelle, ça ne change rien. Ce n'est pas mieux, ce n'est pas pire qu'une page HTML4 classique.

Par contre, il semblerait que pour le éléments tels que <h1> <aside>, <footer>, qui sont recommandés un peu partout en HTML5 (dans les sections, voire sous-sections), cela ne facilite pas la tâche des lecteurs d'écran.

Mais en attendant, je suis de l'avis qu'il n'est pas "risqué" de faire du HTML5 en production à partir du moment où :
- on se base sur ce qui est déjà accessible en HTML4,
- on utilise les nouveaux éléments sémantique (header, nav, footer, section,...) sans en abuser
- on ajoute un peu d'ARIA
- et on y colle un tampon-doctype HTML5

Il s'agira d'une sorte de transition qui me semble tout à fait réalisable en production, à moindre frais, et qui facilitera le vrai passage à HTML5.
Modifié par Raphael (06 Apr 2010 - 08:02)

Raphael a écrit :

Par contre, il semblerait que pour le éléments tels que <h1> <aside>, <footer>, qui sont recommandés un peu partout en HTML5 (dans les sections, voire sous-sections), cela ne facilite pas la tâche des lecteurs d'écran.

Tu as des sources ? des articles, des discussions à mettre en lien ?
Je ne vois à priori pas de problème avec aside et footer. Par contre ce qui est un peu plus gênant, c'est que, si j'ai bien compris HTML5, les niveaux de titrages ne sont plus si simples à maîtriser, dans le sens où un H1, un H2 ou un H3 par exemple ne peut être relatif qu'à une section de la page plutôt que systématiquement relatif à la page entière comme c'est le cas en HTML4. De là plusieurs questions : comment gérera-t-on la navigation de titre en titre au clavier ? Y aura-t-il une navigation par section, puis une navigation par titre seulement ensuite ? Vu la complexité de la question et l'importance qu'elle aura (rappelons à toutes fins utiles que la navigation par titres est le moyen de navigation numéro 1 des lecteurs d'écran), mieux vaut en effet ne pas tirer de conclusion et rester simple, si c'était à ça que tu faisais allusion.

Raphaël a écrit :
Mais en attendant, je suis de l'avis qu'il n'est pas "risqué" de faire du HTML5 en production à partir du moment où :
- on se base sur ce qui est déjà accessible en HTML4,
- on utilise les nouveaux éléments sémantique (header, nav, footer, section,...) sans en abuser
- on ajoute un peu d'ARIA
- et on y colle un tampon-doctype HTML5

Il s'agira d'une sorte de transition qui me semble tout à fait réalisable en production, à moindre frais, et qui facilitera le vrai passage à HTML5.

C'est ce que j'ai prévu pour la nouvelle version de mon site perso.... qui sortira dans longtemps quand je serai motivé. Tu mentionnes ARIA, c'est effectivement un des points du web moderne qui fonctionne déjà pas si mal, à condition d'avoir un navigateur et une aide technique à jour. Cela dit, hormis des exemples, en-dehors des landmarks, je n'ai encore pas vu d'application concrète d'ARIA qui fonctionne en production (si tu as des liens à propposer, je suis preneur).
Par contre, j'ai déjà pu m'apercevoir à ce propos que jaws ne respecte pas le standard en ce qui concerne les live region : il relit toute la div à chaque fois...

Bonjour,

"Laurent Denis" a écrit :
Il n'est d'ailleurs pas nécessaire de recourir à HTML5 ou à CSS3 pour casser l'accessibilité minimale d'une page web. cela se fait très bien en XHTML1.0 et CSS2.1, avec par exemple http://www.jcommaret.fr/

(contenus générés CSS, inaccessibilité au clavier, utilisation impropre des niveaux de titrage, etc.)

Je vois pas en quoi il faudrait qu'il soit obligatoirement accessible car il n'y a, dans ce cas, aucun public visé parmi ceux qui sont handicapés.

Aussi, je trouve que tu fais de la mauvaise pub pour ce portfolio.
Modifié par Chok71 (22 Apr 2010 - 14:51)

Un site web (surtout dans ce genre là) c'est fait pour être accessible à tous.

Laurent pointe juste les défauts du site, à l'auteur de corriger.
Modifié par Patidou (22 Apr 2010 - 14:59)

De toute façon, le projet est fini, et ce n'est pas de mon portfolio que je parlait

Ok, désolé...