a écrit :
on se dit que certaine personne devrait se plonger dans les études avant de proposer quoique ce soit.
D'autant qu'une optimisation de l'accessibilité fondé sur WCAG, si elle s'accompagne d'une réflexion de fond sur l'ergonomie, l'utilisabilité et la gestion du flux suffit, en rêgle générale, à offrir un matériel adéquat aux utilisateurs et aux aides techniques.
En revanche, rien n'interdis de "penser" des adaptations particulières destinés à des situations de handicaps particuliers, je penses notamment aux handicaps moteurs lourds comme la tétraplégie, pour qui la gestion de la navigation clavier est un vrai défi et qui sont les grands oubliés de l'accessibilité du web. (cf la faillite et le désastre de l'implémentation des accesskey).
Mais il est très important de ne pas oublier, que les aides techniques, par exemple les lecteurs d'écrans possèdent leur propres mécanismes avec lesquelles il ne faut pas interférer.
Ainsi il existe des fonctionnalités de navigation sémantique (de liens en liens, de titre en titre) qui sont très intéréssantes, si elle sont connues et maitrisé par l'utilisateur.
Il faut, quand on procède à ce genre d'adaptation, ne jamais perdre à l'esprit que l'on peut crééer des conflits entre l'adaptation réalisé et l'aide technique équivalente.
Le drame d'handilog par exemple, c'est qu'ils ont cherché à "reproduire" certaines de ces fonctionnalités, comme la lecture séquencée d'une liste de liens et que, ce faisant, ils détruisent le rôle de l'aide technique fournie par le périphérique adaptée au profit d'un système inutilisable.
La diversité des publics concernés par le handicap et la grande variabilité des aides techniques imposent d'offrir à l'utilisateur la plus grande souplesse possible, tant au niveau de son habitude d'utilisation que de sa maitrise de l'aide technique utilisé.
Le WCAG et la normalisation du code sont une base idéale, généralement suffisante et surtout offrent aux aides techniques et à l'utilisateur une base commune sur laquelle ils peuvent s'appuyer.
Toute adaptation suplémentaire doit être très réfléchie, sous peine de créér encore plus de problèmes qu'on en résoud.
Dans cet esprit des initiatives comme celles d'handilog ou labelvue, même si on peut (c'est par pure politesse ) supposée qu'elles aient été "de bonne foi" sont désastreuses, parce qu'en créant des "méthodes particulières" elles ne font que compliquer l'utilisation des sites par les publics concernés.
C'est très exactement comme si vous deviez utiliser des méthodes différentes, propre à chaque site, pour cliquer sur un lien : un coup c'est avec le bouton gauche, un coup avec le bouton droit, un coup avec la touche F1, et qu'en plus ces méthodes viennent parasiter la procédure par défaut propre au périphérique que vous utilisez ou vos propres habitudes.
La situation des publics handicapés est déjà très compliqué, du fait qu'il s'agit plus d'une collection de cas particuliers que de "profil standard", surtout quand plusieurs handicaps se cumulent.
La complexité de paramétrage et d'utilisation des aides techniques est également un frein supplémentaire, chaque périphérique adaptés ayant ses propres mécanismes.
En la matière, ce qui doit vous guidez c'est la simplicité, le maximum de souplesse, une analyse attentive du flux et le respect absolu des directives du WCAG, si rien ne sera véritablement "parfait" vous vous assurerez au moins que dans l'immense majorité des cas les utilisateurs handicapés et leurs aides techniques disposeront d'un matériel "suffisant".
JP
Ps: pour compléter la réponse à Bene, il existe à ma connaissance trois tentatives de ce genre : handilog,
labelvue,
confort de lecture sont du même acabit.
En revanche une société suédoise édite un service de vocalisation de contenu web
read speaker, qui peut présenter de l'intérêt, pas pour les non-voyants qui utiliseront leur propre périphérique, mais pour les mal-voyant ou des handicapés moteurs qui peuvent "entendre" au lieu de "lire" tout ou partie d'un site web.
Malheureusement, dans la version "complète" (lecture totale d'un site web) la structure proposé est encore fondé sur une structure de frameset.
Néanmoins il existe la possibilité de vocaliser des documents sans quitter la structure originale du site et c'est assez intéréssant.
En revanche, ce doit être assez couteux, et cela perdra beaucoup d'intérêt quand les navigateurs, (comme opéra le fait) se décideront à implémenter la lecture vocale en standard.
Modifié par jpv (08 Jun 2005 - 01:14)
.... En tout cas, moi je suis pas pilot donc je peux pas y aller 
)
