Accessibilité : définition

Bonjour à tous

Mon topic va un peu changer de d'habitude car je ne poste pas pour vous poser des questions sur les standards mais pour avoir votre avis sur un article de ma conception (ça fait bien cette formule ! )

J'ai rédigé un article sur la définition de l'accessibilité qui est trop souvent assimilé aux handicaps. Comme c'est le premier article que je rédige sur mon site, en dehors des divers forums où je vaque habituellement, je voulais avoir des avis de personnes expérimentées ou non sur le contenu mais aussi le style, le ton employé et la forme.

Ca se passe donc par ici : Accessibilité : définition d'une valeur oubliée...

N'ayez pas peur de me faire part de toutes vos remarques : toute critique est bonne à prendre.

Merci d'avance

PS: je ne savais trop où poster ce topic. Ce n'est en aucun cas de la publicité mais je comprendrendrais, si vous le considériez comme tel que vous le fermiez.

Bonjour,

aucune contre-indication à poster ici
1ère remarque sans rapport avec l'article: le bouton pour l'aperçu d'un éventuel commentaire est libellé "Aperçu" (A majuscule avec tilde et paragraphe) et si j'appuie dessus par inadvertance, les messages d'erreur sont in english:

a écrit :
* You need to provide your name.
* You need to provide a valid email address.
* Empty comments are not comments.

2ème remarque: typos Dernière DerRière / une des valeurS les plus négligées par le webmaster débutant, mais pronéE / unE certaine / Bien[ ]sûr / des E et des S en trop/qui manquent, un pti coup d'aspell ou d'OOo serait le bienvenu / obsOlète / répAndu / sortE considéréE

Sur le fond, tu décris bien certains aspects du problème mais après l'intro il faut attendre le 3ème § pour le vif du sujet, stun peu long dans les phrases . Une définition sur accesskeys et alt seraient enfin pas superflues je pense, comme il y en a déjà sur CSS2.

Felipe

Merci bien pour cette critique.

En ce qui concerne l'encodage et les messages d'erreurs, je vais tâcher de voir à celà. Tout marche pourtant bien en local mais peut être est-ce dû à problème de configuration ou de templates.

En effet, j'ai fait pas mal de fautes d'inatention ou de frappe que je me suis empressé de corriger. La prochaine fois je ferais une vérification sur OOo avant de publier l'article.

Après, il me semble que les paragraphes précédent le troisième sont necessaires pour replacer le lecteur dans des situations diversifiées ayant chacune une problématique commune : l'accès aux informations.
Mais j'essayerais de raccourcir peut-être un peu ce prologue.

je suis un peu précipité mais je prends en compte tous les aspect de ta remarque et encore merci.

Rien de spécial à signaler hormis l'orthographe, je trouve que c'est bien expliqué.

Bonjour,

Quelques remarques en vrac :

a écrit :
Accessibilité : définition d'une valeur oubliée...

Oubliée pourquoi ? on n'en à jamais autant parlé...

a écrit :
la raison suffisante à la mise en place d'accesskeys (raccourcis clavier facilitant la navigation)
...
la mise en place de dispositifs facilitant la navigation au clavier comme les liens d'évitement ou les accesskeys

Les raccourcis clavier et les liens d'évitement n'ont aucun rapport, de près ou de loin, avec l'interopérabilité qui est un concept purement technique.
C'est de la qualité, de l'accessibilité, du confort, de l'ergonomie mais pas du tout de l'interopérabilité.

a écrit :
L'accessibilité sur le web peut être en quelque sorte considérée comme l'homonyme de l'interopérabilité, c'est à dire le fait qu'un site soit accessible sur le plus grand nombre de plateformes, navigateurs et dispositifs possibles.

Non, c'est une erreur de dire ça, l'interopérabilité et l'accessibilité ne sont pas homonymes. Ce peut-être complémentaire, interdépendant, indissociable au choix mais surtout pas homonyme.
Il est parfaitement possible de faire des sites très soignés en terme d'interopérabilité et parfaitement innaccessibles, notamment au sens de l'utilisabilité et inversement.

a écrit :
Elle n'est possible qu'en respectant différentes notions basiques à savoir la sémantique (respect de l'utilisation des balises pour leur usage propre),...

Je pinaille certainement mais la sémantique du balisage n'est pas l'exemple à mettre en exergue pour l'interopérabilité.
Tu gagnerais à dire les choses : l'interopérabilité repose sur la standardisation des langages, dont la sémantique du balisage n'est qu'un aspect particulier.
D'autant plus que tu fais référence à la validation juste après, notion qui va être difficile à comprendre sans la référence à ladite standardisation des langages.

Sur l'article en général :

Je pense que tu ne choisis pas le bon angle, ce dont tu veux parler c'est de l'interopérabilité et comment certaines dispositions liées à l'accessibilité peut la favoriser.

Pourquoi ne pas le faire sous cet angle ?

En réduisant l'accessibilité des contenus aux seules dispositions favorisant l'interopérabilité (pour en parler donc) tu fais passer cette idée qu'il s'agit de la même chose ou que l'un est suffisant à l'autre: c'est partiellement faux et de mon point de vue tu prends le risque de rajouter de la confusion à un domaine déjà sensible.

Jean-pierre
Modifié par jpv (20 Feb 2006 - 14:34)

Arf, désolé de ne pas avoir répondu à ce message avant : la maladie à eu raison de moi durant quelques jours et je n'ai que peu fréquenté mon PC pendant cette période.

Quand je parle de valeur oubliée, c'est plus pour refléter le sentiment que j'ai en surfant sous les traits de l'internaute X et à voir des sites à la mode Frontpage ou tout simplement développés mais pas avec les bonnes bases. Elle n'est pas vraiment oubliée, c'est vrai mais elle est tout au moins trop peu présente ou mal interprétée.

a écrit :
Les raccourcis clavier et les liens d'évitement n'ont aucun rapport, de près ou de loin, avec l'interopérabilité qui est un concept purement technique.
C'est de la qualité, de l'accessibilité, du confort, de l'ergonomie mais pas du tout de l'interopérabilité.

Je parles bien là d'accessibilité et non d'interopérabilité, sur ce point, nous sommes d'accord que ça n'intervient pas dans un concept technique d'interopérabilité.

a écrit :
Non, c'est une erreur de dire ça, l'interopérabilité et l'accessibilité ne sont pas homonymes. Ce peut-être complémentaire, interdépendant, indissociable au choix mais surtout pas homonyme.
Il est parfaitement possible de faire des sites très soignés en terme d'interopérabilité et parfaitement innaccessibles, notamment au sens de l'utilisabilité et inversement.

Effectivement, après réflexion ces propos sont déplacés et incohérents. Je vais essayer de modifier celà ou de tourner ça différemment

a écrit :
Je pinaille certainement mais la sémantique du balisage n'est pas l'exemple à mettre en exergue pour l'interopérabilité.
Tu gagnerais à dire les choses : l'interopérabilité repose sur la standardisation des langages, dont la sémantique du balisage n'est qu'un aspect particulier.
D'autant plus que tu fais référence à la validation juste après, notion qui va être difficile à comprendre sans la référence à ladite standardisation des langages.

Je parle encore une fois de l'accessibilité. L'interropérabilité faisant partie intégrante de celle ci mais ne représentant qu'une infime partie de ce concept.

a écrit :
Je pense que tu ne choisis pas le bon angle, ce dont tu veux parler c'est de l'interopérabilité et comment certaines dispositions liées à l'accessibilité peut la favoriser.

Non, au contraire ! Et j'en suis désolé si on le comprend dans ce sens. Je ne veux pas me cloisonner à l'interropérabilité mais définir l'utilité de l'accessibilité en survolant par la même occasion quelques solutions techniques permettant son instauration comme la sémantique, l'interopérabilité ou les accesskeys. Je ne souhaite pas rentrer dans les détails de ceux ci qui seront peut-être plus amplement définis dans des articles futurs.

Il faut donc que je modifie l'article en conséquence pour que l'on comprenne mieux mes intensions à travers ces quelques paragraphes.

Merci pour cette analyse qui va me permettre de faire évoluer mon texte. J'essayerais en même temps de prendre en compte toutes les autres remarques qui m'ont été faites ici et ailleurs.

Salut à tous,

Je dis à tous car tous vous devez utiliser FF comme navigateur.
Perso, j'utilise IE et je ne vois pas la page. Je n'en voie que :

Ce qui vous en conviendrez est assez peu pour porter un jugement.
Je précise que j'ai aussi FF et la page s'affiche.

<troll>C'est de la discrimination négative </troll>

Arf, il s'agissait d'un bug qui m'avait échapé sur le dimentionnement des textarea situés en fin des articles et qui les faisait s'afficher les articles sous le menu. La chose est maintenant réglée.

Encore une victoire de canard

Bonjour

Je viens de lire un peu tardivement le billet de Deeder qui m'inspire quelques réflexions un peu théoriques, mais bon, après tout la théorie ça sert à déboucher sur des pratiques... Désolé d'être un peu long mais je ne peux pas faire plus court.
Il me semble qu'à travers les diverses interventions sur le forum se dessinent deux tendances développant chacune une approche différente de ce qu'est (ou devrait être) le web accessible, et que les échanges ressemblent parfois à des échanges de sourds puisque les uns et les autres n'appréhendent pas l'objet de la même façon. La première catégorie est celle de ceux qui considèrent qu'un site est un outil de communication parmi d'autres, avec sa logique et ses spécificités, dont l'une est de pouvoir être plus accessible que d'autres médias. Pour cette tendance, un site est d'abord un résultat visible, c'est-à-dire quelque chose dont la finalité est d'apparaître sous une certaine forme. L'autre catégorie considère que le web est essentiellement un contenu structuré, et que sa restitution sur un écran n'est qu'une des possibilités de traitement que ce contenu peut subir.

La différence entre les deux approches est méthodologiquement importante puisque d'un côté, en gros on construit un site pour sa visualisation, insistant sur son aspect (voir toutes les questions du genre mon div déborde dans IE...) et l'on tente ensuite, par un genre de "patching", de le rendre plus accessible, considérant sa restitution comme une dégradation inévitable, parfois insupportable, mais toujours déontologiquement obligatoire. De l'autre, toujours en gros, on structure d'abord un contenu qu'ensuite par un jeu de feuilles de style on va présenter de telle ou telle façon, que ce soit sur un écran d'ordi, de PDA, une page d'imprimante, un lecteur vocal, etc.

Ce qui différencie ces deux approches c'est finalement le statut de l'utilisateur, toujours présent mais rarement éclairé.
D'un côté il est par nature un individu "normal", c'est-à-dire doté de caractéristiques "moyennes" (de vision, d'audition, de capacités motrices, etc.), exactement tel que l'est un utilisateur de tout autre média : journaux, radios, télévisions, etc. A cet utilisateur "normal" s'ajoutent diverses catégories d'utilisateurs particuliers pour lesquels on va "patcher" notre travail. On pourrait appeler cette tendance celle des "metteurs-en-forme".
La deuxième approche considère qu'il n'y a aucun utilisateur définissable par défaut et que sa définition même est inutile, puisque le contenu étant distribué de façon linéaire, cohérente et sémantiquement construite, c'est l'utilisateur (quel que soit son outil) qui lui donnera la forme rendant le contenu plus facilement compréhensible. Cette tendance pourrait s'appeler celle des "metteurs-en-sens". En poussant la démonstration un peu loin on pourrait dire qu'être "doté de capacités moyennes" est un handicap comme un autre, à la différence près que cette catégorie est plutôt favorisée par les éditeurs de logiciels de restitution.

En terme d'accessibilité la différence n'est pas mince. Du côté des premiers la démarche consiste à "anticiper des dégradations", de l'autre à "prévoir des restitutions multiples". Cette différence rejaillit en pratique par exemple dans les questions concernant la validation : un site validé W3C signifie pour les premiers qu'il est corrrectement écrit, et donc logiquement et en toute bonne foi que sa "dégradation" par les outils de restitution alternatifs est acceptable et satisfaisante. Pour les seconds elle signifie seulement que le support distribuant le contenu est jugé apte à le faire dans les meilleures conditions. Ça n'est pas du tout la même chose. Finalité pour les uns, condition a minima pour les autres.

L'article de Deeder tend à présenter l'accessibilité comme une logique de "patch" (les handicapés ont droit... etc.) On peut aussi se dire qu'il n'y a pas a priori de profil utilisateur type, et qu'à partir du moment où un contenu est structuré et mis en forme, peu importe qui le restitue et comment il le fait.
Naturellement le monde n'est pas noir et blanc et ces tendances cohabitent à divers degré en chacun... La question est : laquelle doit prendre le dessus ?

Bonsoir,

Excellente et percutante analyse !

En effet, belle analyse du "problème" si l'on peut dire...

Objectivement, je ne saurais me classer dans l'une ou l'autre catégorie. Je fais donc confiance à ton intérprétation qui me qualifie de "patcheur". J'ai surtout utilisé des clichés plus visuels pour que le lecteur puisse apréhender la chose d'une manière moins abstraite que par l'universalité du partage de l'information quel que soit le profil de l'utilisateur. La mise en place de cas particuliers et leur description permet au lecteur, à mon humble avis, de se placer dans des situations concrètes, des situation d'analyse plus logiques que des remarques généralistes qui peuvent rester floues.
Devant le fait accompli, devant des preuves irréfutables de l'utilité de l'accessibilité, le visiteur ne peut que se forger un avis sur le sujet. Les données théoriques auront plus tendance à placer le lecteur dans une vérité à la fois générale mais indéfinie, dans laquelle il pourra alors se sentir abandonné, ce que je souhaite pas.

A mon avis, les deux "états" que tu as cités sont complémentaires. Certes, comme tu l'as précisé, en différentes mesures, mais elles n'en restent pas moins indissociables. Le rendu importe autant que la manière utilisée pour l'obtenir. Si l'on adapte pas à des outils courants qui interprètent mal la mise en forme donnée, on risque de perdre une part de tranfert de l'information non négligeable. Ensuite, l'utilisation d'un panache de feuilles de styles dépend aussi du public visé et interressé ainsi que d'autres paramètres.

Les deux cas ne font à mon avis qu'un seul suivant les situations...

Deeder a écrit :

Objectivement, je ne saurais me classer dans l'une ou l'autre catégorie. Je fais donc confiance à ton intérprétation qui me qualifie de "patcheur".

Rassure-toi nous le sommes tous Le but de mon billet n'était pas de te dézinguer, au contraire, mais d'essayer de comprendre d'un point de vue plus théorique comment les approches des uns et des autres s'articulent, quels soubassements les fondent, etc. J'ai d'ailleurs terminé en disant que nous étions tous un peu des deux, et je n'ai pas parlé de "catégories" mais plutôt de "tendances".
Il est évident qu'aujourd'hui le rendu visuel prime sur l'organisation du contenu en sens, comme tu l'expliques. Là où je suis moins d'accord avec toi, c'est que les deux tendances ne sont ni complémentaires ni indissociables. Qu'elles le soient pour le moment ne signifie pas qu'elles le resteront. Il me semble au contraire qu'on se dirige vers une séparation de plus en plus nette, rendue obligatoire par l'émergence de nouveaux besoins et de nouveaux outils pour y répondre. On peut imaginer à terme que le même contenu devra également pouvoir être restitué à la radio par exemple, on sera bien alors obligés de penser sa structuration autrement... Le jour où <h1> signifiera autant "titre en Arial 2em #123" que "Voix légèrement plus forte suivie d'un jingle" les patcheurs que nous sommes vivront leurs dernières heures +
a+

Ne t'inquiète pas, je ne l'ai pas mal pris du tout...

Je suis principalement d'accord avec toi mais je pense que l'omniprésence du XML qui est de plus en plus importante peut permettre justement de classer des informations et de les mettre en ordre indépendamment du media. Ainsi, on peut très bien penser que le xhtml 2 ne se concentrerait plus seulement au media web mais qu'il pourrait être adapté àd'autres supports comme une radio, pour reprendre ton idée. Je ne pense pas que la séparation soit de plus en plus prononcée, loin sans faux. A l'heure ou l'on se permet d'ordonner les données afin de les universaliser, je pense que tout reste encore possible.