1091 sujets

Accessibilité du Web

Pages :
Vous me dites si je me trompe, car selon Raphaël je ne comprend pas très bien le principe du W3C ! Je veux vraiment être clair là dessus et pouvoir le mettre en oeuvre le mieux que possible !

Pour moi, W3C est synomyme d'accessibilité, de fluidité et j'ai envie de dire, de compréhension : une page claire, agréable à visiter, accessible pour tous quelque soit le handicap (visuel, de configuration ou moteur) ! Mais après avoir découvert le site http://validator.w3.org/ je me rend compte que tout ceci se trouve également dans la construction et l'enchainement des tags dans le document (x)html ! J'aimerais une définition assez brève car même après avoir lu les conditions du W3C sur le site d'Alsacreations je me rend compte que c'est quand même un peu flou dans ma tête ! Merci d'avance !
Ah oui, là c'est flou...

Le World Wide Web Consortium est un organisme regroupant différentes entreprises et institutions pour définir les standards du Web, dont :
- HTML et XHTML ;
- XML ;
- CSS ;
- DOM.
Ainsi que des normes et recommandations comme les WACG (pour l'accessibilité).

(Il y en a plein d'autres, souvent plus confidentiels ou plus spécialisés, que je ne connais pas ou mal.)

Pour dire les choses clairement : « valide W3C » ne veut absolument rien dire. Aucun site ne peut prétendre « respecter les normes du W3C », si ce n'est par abus de langage. La plupart du temps, un site utilise une partie des technologies créées et/ou normalisées par le W3C, et respecte les normes (ou tente de les respecter).

Pour un site web, on fera souvent référence à :
- La validation HTML ou XHTML : il s'agit de vérifier que la syntaxe (X)HTML d'un document est correcte, c'est à dire que les éléments utilisés sont bien définis comme utilisables pour la version ou « variété » de HTML choisie (Frameset, Transitional, Strict...). L'usage d'un outil de validation (comme celui que tu cites dans ton message) permet de repérer des erreurs de syntaxe, comme par exemple la mauvaise imbrication ou la non fermeture de balises, ou l'utilisation d'éléments dépréciés.
- La validation CSS : même chose, il s'agit de vérifier la syntaxe CSS.

Dans un cas comme dans l'autre, la validation est juste un outil technique, qui ne préjuge en rien de la qualité de la conception. Il y a des codes très mal conçus et parfaitement valides. Par exemple je peux décider de positionner tous les éléments de ma page grâce à la propriété CSS position: absolute;. C'est parfaitement valide (la syntaxe est bonne), mais c'est parfaitement idiot (ça donnera un résultat ingérable).

La validation est donc un outil utile, mais certainement pas une garantie de bonne conception.


Quant à l'accessibilité, c'est encore autre chose. Les WCAG (web content accessibility guidelines) sont publiées par le W3C (et plus précisément par le WAI, la Web Accessibility Initiative, une branche du W3C). Les recommandations qu'elles contiennent sont toutefois plus d'ordre « stratégique » que technique, c'est à dire qu'on ne peut ni les appliquer ni les vérifier par des automatismes. Ça demandera une réflexion et probablement une décision humaine.

Par exemple, une recommandation basique est la WCAG 1.1 : fournir un équivalent textuel à tous les éléments non textuels (par exemple, les images).
Il y a plusieurs moyens de faire ça. Pour améliorer l'accessibilité d'un site, on veillera à fournir des alternatives textuelles pertinentes, par exemple. Et la pertinence, ça ne se décrit pas techniquement et ça ne se vérifie pas automatiquement. Smiley cligne
(Un petit article pratique sur la question des alternatives textuelles, ce qui permettra de se familiariser en douceur avec la nécessité de réflexion derrière toute démarche d'accessibilité : Bien utiliser le texte alternatif.)


Donc :
- « le W3C est synonyme d'accessibilité » : c'est faux, on peut très bien faire un site valide XHTML 1.0 Strict et CSS 2.1, et qui soit peu accessible.
- « synonyme (...) de fluidité » : c'est quoi la fluidité ? Si tu penses à la vitesse de chargement des pages, ça n'est pas directement lié à une quelconque validation, même si un usage réfléchi et efficace de certaines technologies du W3C (dont les feuilles de style CSS) peut y aider. Si tu penses à la lisibilité du code, c'est plus une question de bonne conception ou de bonne pratique que de respect de la syntaxe HTML...
- « accessible pour tous quel que soit le handicap » : on peut faire un site pas valide mais globalement accessible. Bien sûr, travailler à la validité du code HTML et CSS permettra d'éviter quelques erreurs de syntaxe ou l'usage d'éléments propriétaires, et donc d'avoir une plus grande compatibilité avec les navigateurs et autres agents utilisateurs.


Voilà, en espérant que tu y voies un peu plus clair.

Nota : j'ai peut-être écrit quelques bêtises, faut pas hésiter à me corriger, les autres ! Smiley cligne
D'accord, merci !
Donc pour faire très bref (tu me dis si je me trompe) : un site peut très bien respecter les normes W3C (de conception : à savoir si les tags sont bien utilisés, si toute la synthaxe des codes est bonne) et peut être complètement inaccessible (non-universel (ne pas bien fonctionner selon les navigateurs et les différentes résolutions), difficile pour les personnes à handicap (je pense à un menu qui serait mal placé et pourrait poser problème à une personne ayant du mal à bouger sa main), illisible...) ! Et vice versa, un site pour être accessible tout en ne respectant pas les normes W3C ! Donc pour conclure, grosso modo, le World Wide Web Consortium et l'accessibilité d'un site web sont deux choses complètement différentes !!!
Salut,

Un site peut tout à fait être valide pour le validateur du W3C, mais être en revanche totalement inaccessible, si le webmaster n'a fait aucun effort en ce sens.
Ex. Le validateur vérifie bêtement que la balise image soit correctement ouverte et fermée, contienne l'attribut alt. Il n'ira en revanche pas vérifier (et pour cause) qu'aucun contenu textuel ne se trouve dans l'image, et que l'attribut alt ne correspond pas à ce contenu.

Par contre, mais on me reprendra si je me trompe, je pense que faire un site accessible sans passer le validateur risque d'être beaucoup plus improbable, mais il faut bien évidemment savoir quelles sont les erreurs qui empèchent la validation.
S'il s'agit d'un attribut alt inexistant pour une image, il est sur que l'accessibilité sera défaillante.
S'il s'agit d'un caractère non SGML comme un "&" par exemple, je ne pense as que çà puisse remettre en cause l'accessibilité du site si elle est pensée.

Quoi qu'il en soit, je pense que la validation d'un site est une bonne chose pour mettre toutes les chances de son côté pour avancer dans un sens d'accessibilité sur de bonnes bases.
Idem.

D'ailleurs, un des points de contrôle de priorité 2 des WCAG 1.0 est que le document soit valide...

Cela dit, je pense qu'oublier un alt sur un élément de décoration du type pixel.gif ne remet pas dramatiquement en cause, à lui seul, l'accessibilité d'une page... tandis qu'avoir un alt incorrect sur une image avec un contenu informatif est par contre rédhibitoire. Or dans le premier cas, le document ne sera pas valide, alors qu'il le sera dans le second.
mentinet a écrit :
Donc pour faire très bref (tu me dis si je me trompe) : un site peut très bien respecter les normes W3C

Alors je t'arrête tout de suite : « respecter les normes W3C » est une formulation trop large. Et comme je l'ai expliqué plus haut, le W3C édite des normes d'accessibilité, ainsi que quantité de normes techniques pour des choses parfois connues ou parfois complètement obscures, telles que SVG, PNG, SMIL, Xforms, MathML, RDF et OWL (des briques pour le Web sémantique...), etc.

Tu penses sûrement à un site qui respecterait les normes HTML (ou XHTML) et CSS ? Donc à un site qui aurait un code (X)HTML et CSS valide ?

Comme dit plus haut, la validité du code HTML et CSS :
1. est une bonne chose, et une habitude à prendre ;
2. ne suffit pas pour faire un site techniquement bien conçu ;
3. ne suffit pas pour faire un site accessible.

De plus, comme déjà précisé, il est possible d'avoir une page non valide, mais globalement accessible (en particulier si une démarche d'accessibilité bien pensée à été mise en place). Tout dépend du type d'erreur de syntaxe qui sera renvoyé. S'il s'agit de l'oubli systématique des attributs alt sur les éléments non textuels, le site sera très peu accessible. S'il s'agit d'erreurs d'imbrications des balises HTML ou de propriétés CSS erronées, ça aura peut-être un impact mais ça ne me semble pas rédhibitoire pour l'accessibilité.

Pour clarifier les rapports entre validation HTML/CSS (pitié, ne pas parler de « Validation W3C », ça n'a aucun sens... ou alors juste pour vendre le respect des normes W3C à un client potentiel Smiley cligne ), on peut dire ceci :
1. le respect strict et sans faute des syntaxes HTML et CSS n'est pas une condition obligatoire de l'accessibilité ;
2. toutefois, un code HTML valide est une bonne base pour une démarche d'accessibilité, et pour des efforts égaux sur l'accessibilité le site final aura plus de chance d'être accessible si son code HTML est valide que s'il comporte de nombreuses erreurs de syntaxe (note : la validité du code CSS est une bonne chose aussi, mais elle a peut-être moins d'impact sur l'accessibilité) ;
3. cependant, la validité du code HTML/CSS d'un site n'est pas suffisante pour garantir une bonne accessibilité.

Donc, là règle à suivre est la suivante : 1) coder (HTML/CSS) valide, ce qui aura des effets bénéfiques à différents niveaux, pas que pour l'accessibilité et 2) entreprendre également une démarche d'accessibilité.

mentinet a écrit :
Donc pour conclure, grosso modo, le World Wide Web Consortium et l'accessibilité d'un site web sont deux choses complètement différentes !!!

Rapport entre World Wide Web Consortium et Accessibilité : le W3C conseille fortement la mise en oeuvre d'une démarche d'accessibilité, et publie des recommandations à ce sujet au sein du WAI (branche « Accessibilité » du W3C), dont les fameuses WCAG (directives pour l'accessibilité des contenus web). Le rapport entre le W3C et l'accessibilité est donc étroit.

Rapport entre les normes (X)HTML et CSS publiées par le W3C et l'accessibilité : voir ci-dessus.
Florent V. a écrit :

1. le respect strict et sans faute des syntaxes HTML et CSS n'est pas une condition obligatoire de l'accessibilité.


si.

Lire WCAG1.0.
Il me semble que c'est bien ce que je disais, sauf que tu rajoute plein de mots compliqués non ?? Smiley smile
Un site valise (X)HTML/CSS ne signifie pas forcément un site accessible mais c'est entre autre un voie vers cette accessibilité!
Et l'inverse, un site accessible peut très bien ne pas être valise (X)HTML/CSS (comme pour l'attribut alt par exemple, mais dans ce cas là il y quand même un problème mais qui peut ne pas poser de soucis d'accessibilité) ! J'espère avoir compris Smiley sweatdrop
Bonjour,

a écrit :
Un site valise (X)HTML/CSS ne signifie pas forcément un site accessible mais c'est entre autre un voie vers cette accessibilité!


La validite du code est à mettre en perspective avec l'ensemble de la directive 3 de WCAG : Utiliser le balisage et les feuilles de style, et cela de façon appropriée.

L'item 3.2 : "Créer des documents qui sont validés par des grammaires formelles publiées", ne concerne que le code Html, elle implique que le code soit validé pour une DTD valide : Recommended DTDs to use in your Web document. (en).

Les buts recherché par cette validation concerne deux points importants :
- L'absence d'élément dépréciés.
- L'absence de problème et d'identification de la restitution de l'arbre du document (DOM) et des éléments qui le compose.

C'est important en terme d'accessibilité, notamment pour la fermeture des balises et la filiation.

D'autre problèmes peuvent être facilement résolus en validant le code comme l'encodage des caractères.

WCAG 2.0, ne demande plus que le code soit validé mais de s'assurer de la robustesse du code : Guideline 4.1 Support compatibility with current and future user agents (including assistive technologies) Level 1 Success Criteria for Guideline 4.1 (en).

La validite du code n'est, évidemment pas, la garantie qu'un contenu est accessible et il est parfaitement possible d'avoir un site accessible avec du code invalide.

C'est par exemple le cas pour Accessiweb qui ne demande pas la validité du code.

En revanche c'est le moyen le plus intelligent pour s'assurer, à peu de frais, que les items qui réfèrent à la restitution de la structure et à l'utilisation des éléments ne posent pas de problème.

Donc, le seul conseil que l'on peut donner est d'utiliser un DTD valide et de valider le code en relevant es erreurs de structure et d'utilisation des éléments.

Ce faisant on garantira un code robuste ce qui est le but, in fine, de la validité Html.

Jean-Pierre
Modifié par Heyoan (07 Jun 2009 - 02:57)
Bonjour,
interessant... la non fermeture de certaines balises (strong en l'occurence)
peut aussi s'avèrer problématique pour la présentation : effet repercuté
jusqu'à la fin du document.

En therme de validité, on peut se demander en quoi par exemple, cas un
peu particulier, l'oublie d'un élément de type block sous un <form> peut nuir
à l'accessibilité ou à la bonne restitution d'une page. Certe on peut très
bien faire l'économie de ce type de question et se dire c'est comme
ça, pas la peine d'aller chercher plus loin
, mais je suppose que cela n'a
pas été mise en place pour le plaisir.
Et et il me semble qu'arrivé à un certain niveau, il est nécessaire de pouvoir
expliquer le pourquoi des choses et particulièrement dans ce type de cas de figure.
Modifié par Hermann (10 Apr 2007 - 23:01)
Salut,

Hermann a écrit :

En therme de validité, on peut se demander en quoi par exemple, cas un
peu particulier, l'oublie d'un élément de type block sous un <form> peut nuir
à l'accessibilité ou à la bonne restitution d'une page. Certe on peut très
bien faire l'économie de ce type de question et se dire c'est comme
ça, pas la peine d'aller chercher plus loin
, mais je suppose que cela n'a
pas été mise en place pour le plaisir.
Et et il me semble qu'arrivé à un certain niveau, il est nécessaire de pouvoir
expliquer le pourquoi des choses et particulièrement dans ce type de cas de figure.


Ba c'est deux questions très différentes je trouve.

1. D'un coté les procédures efficaces pour avancer en terme de qualité, au premier chef en terme d'accessibilité. Et la validation en fait partie, c'est un outil qui permet un gain de temps énorme, dans ce cadre le mieux est de s'y astreindre sans trop rentrer dans des questions de fond.

2. Par ailleurs il est effectivement légitime de se poser la question du pourquoi de tout ça. Même si dans ce cas il est préférable de bien se boucher les oreilles pour s'éviter la volée de sarcasmes que vaut en général ce genre de réflexion Smiley langue
Christian Le Bouler a écrit :

2. Par ailleurs il est effectivement légitime de se poser la question du pourquoi de tout ça. Même si dans ce cas il est préférable de bien se boucher les oreilles pour s'éviter la volée de sarcasmes que vaut en général ce genre de réflexion Smiley langue

Je vois pas en quoi ce genre d'intérogations peut faire l'objet de propos
sarcastiques...
Hermann a écrit :

Je vois pas en quoi ce genre d'intérogations peut faire l'objet de propos
sarcastiques...


Moi non plus...

C'est juste une allusion à quelques expériences persos... Et pas très bien vécues.
Modifié par Christian Le Bouler (12 Apr 2007 - 10:11)
jpv a écrit :

La validite du code n'est, évidemment pas, la garantie qu'un contenu est accessible et il est parfaitement possible d'avoir un site accessible avec du code invalide.

C'est par exemple le cas pour Accessiweb qui ne demande pas la validité du code.

En revanche c'est le moyen le plus intelligent pour s'assurer, à peu de frais, que les items qui réfèrent à la restitution de la structure et à l'utilisation des éléments ne posent pas de problème.


Cela revient à dire, d'une manière très politiquement correcte (si tu me permets), que l'invalidité est certes le pire des chemins vers l'accessibilité (sauf exceptions), mais que son coût final, par exemple sur le développement de l'accessibilité côté agents utilisateur, pourrait être justifié.

Hum... Le problème est que même la surqualité n'y parvient pas, à cette justification (à l'usage).

J'avoue avoir de plus en plus de mal, bien qu'adorant les distinguos, avec cette démarche : j'aime assez celle consistant à dire plus clairement si vous devez être invalide, vous devrez veiller à votre propre coût à vous assurer que cela n'a aucune conséquences sur l'accessibilité puisque vous vous placez au départ clairement dehors du processus global qui intègre celle-ci.

Question de nuance ? Peut-être bien. J'arrive au final au même conseil que toi, mais avec juste une nuance... disons plus directe ? Smiley cligne
a écrit :
Cela revient à dire, d'une manière très politiquement correcte (si tu me permets), que l'invalidité est certes le pire des chemins vers l'accessibilité (sauf exceptions), mais que son coût final, par exemple sur le développement de l'accessibilité côté agents utilisateur, pourrait être justifié.


Je suis troublé...
Je n'avais pas vu ça sous cet angle là, je m'étais contenté de dérouler l'argumentation du "petit EAE illustré" Smiley lol
Mais oui, évidemment, on pourrait l'interpréter comme ça...

a écrit :
si vous devez être invalide, vous devrez veiller à votre propre coût à vous assurer que cela n'a aucune conséquences sur l'accessibilité puisque vous vous placez au départ clairement dehors du processus global qui intègre celle-ci.


Nous sommes d'accord....

a écrit :
Question de nuance ? Peut-être bien. J'arrive au final au même conseil que toi, mais avec juste une nuance... disons plus directe ? cligne


C'est ce qui fait tout le charme de ton avatar : pomper inlassablement de nouvelles manières de voir... Smiley biggrin

Jean-Pierre
Modérateur
Laurent Denis a écrit :


Cela revient à dire, d'une manière très politiquement correcte (si tu me permets), que l'invalidité est certes le pire des chemins vers l'accessibilité (sauf exceptions), mais que son coût final, par exemple sur le développement de l'accessibilité côté agents utilisateur, pourrait être justifié.

Hum... Le problème est que même la surqualité n'y parvient pas, à cette justification (à l'usage).

J'avoue avoir de plus en plus de mal, bien qu'adorant les distinguos, avec cette démarche : j'aime assez celle consistant à dire plus clairement si vous devez être invalide, vous devrez veiller à votre propre coût à vous assurer que cela n'a aucune conséquences sur l'accessibilité puisque vous vous placez au départ clairement dehors du processus global qui intègre celle-ci.

Question de nuance ? Peut-être bien. J'arrive au final au même conseil que toi, mais avec juste une nuance... disons plus directe ? Smiley cligne
Désolé Laurent, mais ce message est absolument incompréhensible. J'ai souvent remarqué sur ce forum que ça fait bien d'utiliser des termes complexes pour expliquer des choses simples. En général, on fait l'inverse. Smiley smile
a écrit :
J'ai souvent remarqué sur ce forum que ça fait bien d'utiliser des termes complexes pour expliquer des choses simples. En général, on fait l'inverse.


Normalement on vas te répondre que non c'est un faux procès que pour avoir un forum de qualité et parler de certains sujets et patati et patatata comme d'hab quoi.

Moi j'ai fini de me battre pour essayer de leur faire comprendre que tout le monde n'avait pas leur niveau de connaissance de la langue française et de l'anglais vu qu'apperement j'étais le seul à leur faire remarquer.

A quoi bon poser une question quand on est à peu près sur de ne pas comprendre la moitié de la réponse surtout quand ils commencent à parler accessibilité entre-eux.

A quoi bon leur expliquer que cela pourrait faciliter les choses de mettre les liens des traductions en français existantes plutôt que de sauter sur le premier lien anglophone qui leur passent sous la main sans se préoccuper de la personne qui se trouve en face.

Mais ils sont sympas ils te disent gentiement que si tu ne comprends pas les mots qu'ils utilisent et que si tu ne connais pas l'anglais (langue du web) ben voilà quoi et que de toute façon ils continuerons à en parler comme cela qu'ils ne peuvent pas faire autrement c'est le sujet qui veux ça enfin le barratin habituel.

Au début j'y attachais beaucoup d'importance mais maintenant je prends ça à la rigolade.

Si j'ai une question, je la pose et je m'accroche aux branches en attendant les réponses.

Des fois ça le fait des fois ça le fait moins ça dépends.

Pour moi ils ont un petit peu oublié ce pour quoi ils militent "l'accessibilité".
@Knarf Tu es un peu sévère et un peu blasé on dirait.
Rien ne t'oblige à lire ce qui se termine en un dialogue d'experts.
Avoir 2 experts sur ce forum moi je vois ça polutôt comme une chance et puis
leur interventions sont assez rares alors on va pas s'en plaindre...
Avis d'un troisième expert Smiley cligne

Comme beaucoup de métiers, l'accessibilité a son jargon. Plus précisément, le vocabulaire utilisé a sa signification, qui a parfois un sens légèrement différent du sens qu'il a dans le langage courant (voir par exemple les débats sur la notion d'information "équivalente", ou bien les réponses qui ne sont jamais blanches ou noires quand on parle du lien entre accessibilité et respect des standards (X)HTML).

Parfois, quelqu'un arrive avec une question qui lui paraît simple. Mais la réponse, quand on connaît un peu le sujet, est parfois plus complexe qu'il ne s'y attend, et c'est justement pour essayer d'aller jusqu'au fond des choses dans la réponse que les débats semblent se complaire dans des termes abscons.

C'est donc par souci de donner la réponse la plus exacte et la plus précise possible que celle-ci est si élaborée, et déçoit (souvent?) la personne qui posé la question.

En tant que prof, je suis parfois obligé, dans mes cours introductifs ou d'initiation par exemple, de dire des choses qui intérieurement me hérissent, car je dois faire simple pour essayer de faire comprendre la base des choses. Mais j'ai la chance de pouvoir travailler dans la durée, et donc je sais que quelques jours plus tard, quand mes étudiants en auront assez appris, je pourrai préciser ma réponse et la nuancer.

Sur un forum, les choses sont plus compliquées. On ne connaît pas a priori le niveau de compétences de la personne à qui on s'adresse, et qui vient de temps en temps, voire pour la première fois, poser une question. Et comme on ne sait pas si elle va souvent revenir, on est obligé, dans la réponse, de donner immédiatement la réponse la plus complète, même si elle est complexe...
Modifié par Gilles (16 Apr 2007 - 08:02)
Modérateur
Gilles a écrit :
C'est donc par souci de donner la réponse la plus exacte et la plus précise possible que celle-ci est si élaborée, et déçoit (souvent?) la personne qui posé la question.
Tout à fait, mais ici ce n'est pas vraiment ça: on utilise des tournures de phrases incompréhensible et totalement fausses pour donner l'impression d'avoir affaire à de vrais experts traitants de sujets pointilleux et complexes. Je ne remets pas en doute les connaissances des intervenants, mais plutôt la manière dont ils interviennent. Smiley cligne Au hasard, une phrase comme celle-ci ne veut tout bonnement rien dire:
a écrit :
j'aime assez celle consistant à dire plus clairement si vous devez être invalide, vous devrez veiller à votre propre coût à vous assurer que cela n'a aucune conséquences sur l'accessibilité puisque vous vous placez au départ clairement dehors du processus global qui intègre celle-ci.
Pages :