[Résolu] Pages accessibles : une seule ou plusieurs spécialisations ?

Bonjour,

Les handicaps étant de natures diverses, ne serait-il pas judicieux de prévoir, non pas un, mais plusieurs modes d'accessibilités pour un même site ?

En d'autres termes, pour être plus concret, les impératifs n'étant pas les mêmes pour un déficient visuel et pour quelqu'un souffrant de difficultés d'ordre moteur, est-il pertinent de proposer d'intervenir sur le contraste, ou sur la taille des affichages dans le même temps que l'on offre des facilités de navigation à l'aide du clavier ?

Ne faudrait-il pas orienter les visiteurs vers une page spécifiquement adaptée à leur handicap ?
Ne faudrait-il pas, en plus de la page 'standard', destinée aux valides, faire exister non pas une mais plusieurs pages spécifiquement adaptées ?


La lecture de mon profil vous aura renseigné quant à ma compétence faible dans le domaine abordé ici, ne m'en veuillez pas si ma remarque parait hors sujet ou de faible intérêt ; mon propos n'est pas de 'donner des leçons', mais bien d'en solliciter. J'ai en projet la réalisation d'une plate-forme d'apprentissage dont je tiens à ce qu'elle offre un niveau d'accessibilité optimal, et j'ai du mal à collecter informations et préconisations.
Modifié par sergeAles (18 Jan 2010 - 10:21)

Salut,

(Merci d'avoir ouvert ton propre sujet pour poser la question )

L'intérêt des standards est avant tout de n'avoir plus qu'un seul et même site à produire pour diminuer la durée et les couts de sa production, ainsi que la durée et les couts de sa maintenance. Produire différentes pages spécifiquement pour chaque différents handicaps reviendrait à ce qui se faisait il y a quelques années en arrière où c'était fait pour chaque différent navigateur.

L'objectif des standards, est de proposer une information qui sépare le fond et la forme, en ayant la base à savoir l'information dans un seul et même fichier, qui peut être accessible quel qu'en soit le moyen utilisé pour cela. La forme peut ensuite être enrichie par le biais d'autres technologies telles que CSS, javascript, etc.

Pour chaque handicap, il existe une solution technique du côté de l'utilisateur, qui lui permet d'accéder à l'information d'un site si celui ci est fait pour. D'où l'intérêt de se baser sur un code propre et valide, respectant au mieux les recommandations du WCAG.

Donc pour répondre à ta question, non cela ne serait pas justifié, car les solutions techniques du côté de l'utilisateur nécessiteux sont bien plus élaborées que celles qu'il est possibles de faire avec les outils actuels, donc l'intérêt de substituer (ou ajouter) du "bien" à un "mieux" n'est que très faible.

Pour approfondir cela, il est possible de mettre des outils en plus dans un site, concernant tel ou tel handicap, tels que les liens d'évitements ou les accesskeys, car même s'ils ne sont pas utilisés par tout le monde, ils peuvent être pratiques pour les uns et les autres sans pour autant les gêner.
Modifié par Mikachu (12 Jan 2010 - 16:11)

Je vais répondre assez rapidement (par manque de temps)

sergeAles a écrit :
En d'autres termes, pour être plus concret, les impératifs n'étant pas les mêmes pour un déficient visuel et pour quelqu'un souffrant de difficultés d'ordre moteur, est-il pertinent de proposer d'intervenir sur le contraste, ou sur la taille des affichages dans le même temps que l'on offre des facilités de navigation à l'aide du clavier ?

À partir du moment où les mécanismes d'accessibilité (si on peut les appeller comme ça) ne rentrent pas en conflit, il n'y a pas de raison de ne pas tous les proposer à la fois. Il ne faut pas oublier que tous les handicaps sont uniques et qu'une personne souffrant de la même "maladie" (par example) n'aura pas forcément le même comportement qu'une autre sur Internet.

sergeAles a écrit :
Ne faudrait-il pas orienter les visiteurs vers une page spécifiquement adaptée à leur handicap ?

La multiplications de pages "conçue spécialiement pour" est généralement mauvaise. 1. c'est difficile à maintenir pour le développeur ; 2. cela créé une ségrégation entre les visiteurs qui peut être mal perçue par certains.

sergeAles a écrit :
Ne faudrait-il pas, en plus de la page 'standard', destinée aux valides, faire exister non pas une mais plusieurs pages spécifiquement adaptées ?

Comme dit plus haut, il ne devrait y avoir qu'une seule version de page.

@Laurie : Mouahahahaha, d'une seconde là !

Bonjour,

La démarche d'accessibilité selon les standards WCAG du W3C repose au contraire sur la stratégie inverse :
* ne pas tenter de traiter spécifiquement chaque contexte de handicap, ce qui serait peu efficace en raison de la variété des situations et des besoins. Ou encore : ne pas tenter d'anticiper ce qui conviendra très précisément à chaque utilisateur, ce qui est impossible.
* mais fournir à tous les utilisateurs et surtout à toutes les aides techniques utilisées (navigateurs, lecteurs d'écran, loupes, périphériques de navigation, etc.) des pages génériquement accessibles, c'est à dire exploitables par l'aide technique selon les besoin de l'utilisateur.

Une très grande partie de l'accessibilité WCAG ne se préoccupe pas en fait des utilisateurs, mais bien davantage de leurs outils. C'est à dire de machines auxquelles on peut adresser un traitement générique. Ce qui rend la démarche réaliste et économiquement viable.

Dans cette démarche, disons que :
* le site fait une très grande partie du chemin,
* mais l'utilisateur fait lui aussi sa part du chemin : c'est à lui de tirer parti des contenus "accessibles", grâce à l'usage avisé d'une aide technique appropriée.

La démarche d'accessibilité se place donc volontairement à un certain niveau d'abstraction vis-à-vis des utilisateurs concernés et de leurs handicaps propres. Mais dans une certaine mesure seulement :
* il reste dans les exigences de la norme WCAG des critères visant certains contextes de handicap bien précis, ou visant l'utilisateur et non ses outils.
* toute situation de handicap ne peut pas être traitée de cette manière abstraite. En particulier quand il ne s'agit plus seulement de coder d'une certaine manière les contenus, mais qu'il s'agirait de produire des contenus spécifiques en réponse à des handicaps spécifiques (notamment cognitifs, mais aussi sensoriels : cas de la surdité). On touche là aux limites de la démarche...

Je vous remercie l'un et l'autre de vos réponses pertinentes et précieuses.

J'ai bien entendu ce que vous m'avez dit pour ce qui est des conséquences négatives de 'la multiplication des petites pages' concernant la maintenance et les évolutions du site.

La séparation du contenu et de la mise en forme par le biais de feuilles CSS est qque chose de nouveau pour moi, mais justement, il me semblait qu'en les utilisant de façon pertinente, on se préoccupait de cet aspect une bonne fois pour toute. Il me semblait, qu'ayant créé l'organisation des blocs, qu'ayant fixé les styles, on n'avait ensuite plus qu'à se préoccuper d'un seul contenu.

Si je ne viens pas d'énoncer une énorme bêtise, alors ce supplément de travail me paraît justifié, puisqu'il n'est à produire qu'une fois.

Je suis comme vous, totalement opposé à multiplier le nombre de fichiers .html ou .php. Mais je ne suis pas opposé à l'idée d'avoir 3 .css (un standard, un spécial vision, un spécial moteur), voire quatre, si l'on rajoute une mise en forme se préoccupant de l'ouïe, mais je ne sais pas aujourd'hui si cela se justifie


Je m'abreuve depuis quelques temps déjà de vos posts (et vous êtes, l'un et l'autre diablement productifs !), donc ne prenez pas mal ma contradiction : contrairement à toi, Laurie-Anne, j'ai l'impression que certaines adaptations sont conflictuelles : en effet, lorsque l'on 'grossit' des affichages, cela se paie par 'moins d'info au cm²', et donc, oblige à scroller plus fréquement. Ce faisant, je pense qu'on ennuie quelqu'un qui a du mal à le faire, tout en ayant une excellente vue.

Qu'en pensez-vous ? Qu'en pensent les autres lecteurs ?

@Laurent :
Désolé, je rédigeais ma réponse quand la tienne est arrivée.

Donc, si je comprends bien, Vous me dites
- (Laurie-Anne et Mikachu) : tu vas t'inventer du boulot inutile
- (Laurent) tu risques de commettre du boulot nuisible.

Désillusions cruelles....

Merci, j'en tiendrai évidemment compte, mais ça va être douloureux

Pour la satisfaction intellectuelle d'être allé au bout du débat, quid de ma question de 16:23 (cm² et scrolls) ?
Modifié par sergeAles (12 Jan 2010 - 16:45)

sergeAles a écrit :

Pour la satisfaction intellectuelle d'être allé au bout du débat, quid de ma question de 16:23 (cm² et scrolls) ?

Il y a une distinction importante à faire entre :
* l'accès au contenu : un texte trop petit pour moi n'est pas perceptible du tout.
* le confort d'accès au contenu : consulter un texte agrandi contraint à scroller plus fréquemment.

Disons que, dans cet exemple, un contenu "confortable" mais non perceptible n'aurait guère de sens, n'est-ce pas ?

Je suis d'accord avec toi sur la nécessité de la distinction, mais un grand mal-voyant et placera-t-il le seuil d' inconfort au même niveau que toi ?
Désolé de paraître ergoter
Modifié par sergeAles (12 Jan 2010 - 16:55)

L'intérêt des outils actuels des navigateurs classiques, c'est qu'il est possible de zoomer au choix soit seulement sur le texte, soit sur tout le site (avec plus de niveaux que le zoom texte). Le seuil sera donc différent mais l'utilisateur pourra donc trouver son équilibre entre confort et nécessité, selon son propre besoin.
Sans compter que les écrans se font de plus en plus grands, et permettent d'afficher de plus en plus de contenu simultanément.

Même si tu prévois une feuille de style spécifique en grande taille, le problème sera de toute manière le même, à savoir que l'utilisateur verra toujours un contenu plus réduit que si le texte est plus petit, c'est mathématique. Sans compter que tu ne tomberas pas pour autant à la taille qu'il désire, car il doit y avoir autant de préférences différentes que d'individus.
Il vaut mieux faire une seule et unique feuille de style (à part pour IE mais ça c'est un autre débat), et faire en sorte qu'elle puisse contenter le maximum d'utilisateurs. Donc arriver à définir une mise en forme médiane qui conviendra à la majorité, et qui laisse la possibilité du zoom autant en réduction qu'en agrandissement.

Ok,

donc

- j'abandonne mes velléités, je lâche prise et ne décide pas à la place de l'utilisateur (citation, mais de qui ?).
- je joue sur les contrastes, les liens d'évitement, la navigation au clavier, etc et je laisse l'utilisateur gérer le zoom.

Je remercie chacun de vous.

Mikachu a écrit :
Il vaut mieux faire une seule et unique feuille de style (à part pour IE mais ça c'est un autre débat), et faire en sorte qu'elle puisse contenter le maximum d'utilisateurs.

Je préciserai que s'il faut ajouter d'autres feuilles de style, ce sera pour ajuster les styles pour l'impression, d'une part, et pour les supports mobiles (les iPhone, les Blackberry, les autres smartphones et les PDA, par exemple), d'autre part, sachant que la feuille de style dont parle Mikachu doit servir pour tous types de support.

Bien noté.

Merci

Pour en remettre une couche (probablement inutile, au vu des derniers messages ), une des raisons pour lesquelles il n'est pas judicieux de proposer des versions adaptées à chaque handicap (hors cas particulier de certains handicaps cognitifs), et que l'on n'a pas encore évoquée, est que cela met ipso facto de côté, ou bien au minimum complique la vie, de ceux qui ont un handicap multiple.

Si j'ai un handicap moteur qui nécessite l'utilisation d'un dispositif de pointage spécifique, et suis mal-voyant avec une mauvaise perception des couleurs,quelle version dois-je choisir ? Celle qui présente des contrastes renforcés, celle qui agrandit le texte, celle qui élargit les zones de clic avec des liens plus gros (jamais vu, mais on peut l'imaginer)?

Fournir une version unique, mais pour laquelle le recours à des techniques référencées permet d'assurer la personnalisation au gré des besoins de chaque utilisateur, permet de surcroît à l'utilisateur de ne pas se sentir mis à l'écart quand il n'entre pas "dans les cases": on le reconnaît en tant que citoyen et utilisateur à part entière, et non comme faisant partie d'une catégorie de personnes mise à l'écart, ne serait-ce que virtuellement.

@Gilles :

Certes, tu en rajoutes une couche ; elle techniquement pertinente, argumentée, donc constructive et humainement riche, ce qui n'est pas le moindre de ses mérites.
Merci donc pour cette couche...

Dans le domaine de l'accessibilité, il y a deux responsables : le webmaster, et le navigateur (complété ou non par un ou plusieurs logiciels d'aide technique appropriés). Le premier ne devrait idéalement pas perdre son temps à ajouter des fonctionnalités pour palier celles absentes du second. Ce qu'on fait parfois en connaissance de cause ou non, moi le premier bien entendu.

Les fameux boutons augmenter la taille du texte en javascript, pour citer un exemple qui revient régulièrement, sont donc une bêtise. Les navigateurs proposent par défaut un zoom basique, et un malvoyant possède un logiciel qui lui permettra d'agrandir les textes de façon beaucoup plus efficace et adaptée. De mêm qu'un non-voyant n'accédera pas plus facilement à l'information sur une page en texte brut, ou pire, dans des fichiers audio générés d'avance spécialement prévue pour lui, quand une page présentant du texte correctement sémantisé existe. A vouloir trop bien faire, finalement on y perd. Je dis ça mais en même temps, je suis le premier à vouloir trop en faire pour faire bien.

Par contre, pour que ça puisse marcher, pour que les navigateurs et les aides techniques puissent véhiculer l'information selon les volontés de l'utilisateur, il faut donner le moyen aux machines de comprendre cette information. Aucun ordinateur ne sera jamais capable de deviner la structure d'un document ou le texte alternatif d'une image s'il n'y a pas un humain pour les lui indiquer à un moment donné, pas plus que le sens d'un texte, d'une musique ou une vidéo. L'éditeur du contenu a donc également sa part de travail à faire, et pour qu'il sache quoi faire, on a écrit les WCAG et tous les référenciels et documentations qui en sont issus. WCAG qui devraient, à mon avis, ne pas se limiter au web mais également à tous les formats bureautiques et, plus largement encore, à toutes les interfaces utilisateur.

En conclusion, je dirais que l'accessibilité, c'est aussi savoir rester simple : respecte les standards, les WCAG et ARIA, mais ne fais rien de plus et ne te complique pas la vie inutilement. Et ton site sera accessible au plus grand nombre dans des conditions qui seront en moyenne globalement acceptables pour la majorité des utilisateurs.
Modifié par QuentinC (14 Jan 2010 - 09:21)

@QuentinC

Merci de ta réponse, (sollicitée, qui plus est).
Tu enfonces le clou, et ton avis me tenait particulièrement à coeur...

@ tous

Je remercie tous ceux qui m'ont évité de me fourvoyer.
Je propose, sauf avis contraire de fermer ce billet, dans un jour ou deux.

Hello,

sergeAles a écrit :
Je propose, sauf avis contraire de fermer ce billet, dans un jour ou deux.

Je suppose que tu parles de le passer en [résolu] puisqu'on ne ferme que très rarement un sujet.

Du coup c'est à chaque auteur (et donc à toi) d'en décider.

Oui, l'inculte-du-web que je suis s'est mélangé les pinceaux.
Modifié par sergeAles (14 Jan 2010 - 09:54)

QuentinC a écrit :
WCAG qui devraient, à mon avis, ne pas se limiter au web mais également à tous les formats bureautiques et, plus largement encore, à toutes les interfaces utilisateur.

Le W de WCAG est mis pour Web. Pour les interfaces utilisateur, il y a les ATAG (Authoring Tool Accessibility Guidelines) qui peuvent servir et sur lesquelles est basé le référentiel Accessiweb CMS.

Quant aux formats bureautiques, étant donné qu'il n'y en a aucun qui est maintenu par le W3C, ce dernier a peu de chances de pondre une spécification à ce sujet. Mais, d'autres organismes s'en chargent : Braillenet fournit des documents indiquant comment améliorer l'accessibilité d'un document Word ou PDF et le projet AcceDE se penche sur l'accessibilité des documents PDF.