C'est que l'on peut constater plusieurs jolies erreurs :
http://validator.w3.org/check?uri=http%3A%2F%2Futilisateu...
Je pense que Feedback gagnerais beaucoup à respecter les recommandations du W3C (http://www.w3.org), et ce sur toute ses pages.
Je ne parle pas seulement de faire un site valide (X)HTML et CSS, je parle aussi de respecter les recommandations de la "Web Accessibility Initiative" (http://www.w3.org/WAI).
Cela permettrais de garantir Feedback ne soit pas accessible qu'à madame et monsieur tout le monde, mais aussi au personnes souffrants handicapes divers.
Après tout, le principe de Feedback n'est-il pas que tout le monde, sans exception, ai son mot à dire ?
Cette suggestion est archivée, les contributions sont neutralisées.
Envoyer cette suggestion à un ami
Si vous désirez partager et faire connaître cette suggestion à vos amis par courrier électronique, merci d'indiquer leurs adresses email, en les séparant par des virgules.
En cliquant sur OK, un message leur sera envoyé.
C'est que l'on peut constater plusieurs jolies erreurs :
http://validator.w3.org/check?uri=http%3A%2F%2Futilisateu...
Bigou > Plus qu'une déclaration de principe général il serait plus intéressant de savoir quelle partie du site souffre de gros problème d'accessibilité, et pour quel type d'usage, non?.
Les problèmes d'accessibilité au contraire de ceux de sémantiques ont une part non négligeable d'interprétation et de relativisme (ce qui est accessible pour l'un ne l'est pas forcement pour l'autre). Preuve en est l'hétérogénéïté des normes ne serait-ce qu'à l'échelle européenne. A priori je dirais que pour un site web2.0 avec autant de javascript, ajax et compagnie nous nous plaçons plutôt dans la catégorie des gens respectueux sans pour autant mériter la médaille d'or, mais si tu compares avec des produits comme gmail, on fonctionne correctement sans javascript par exemple.
Ivan > Il ne faut pas confondre accessibilité WAI et validatité XHTML. L'un et autre sont des problématiques très différentes. Mais effectivement il y a des petites erreurs dans la sémantique, rien de grave si on regarde en détail c'est facilement corrigeable.
Oui je connaîs la différence entre le WAI et la validité, je voulais juste souligner le fait, qu'en plus de faire ce que propose Bigou, vous pourriez corriger les quelques erreurs XHTML du site. Ce n'est pas bien grave, car une page web peut s'afficher correctement même si son code est horriblement mal foutu, mais c'est juste une question "d'éthique" de mon point de vue.
D'un niveau peu subjective, je reprocherais la non utilisation de la propriété "acceskey". Juste les AccesKeys principale, avec AccesKey 0 pour la page qui indique quels AccesKeys sont utilisé et à quoi ils correspondent, AccesKey 1 pour retourner à l'accueil et quelques autres AccesKeys pour accéder rapidement à la suggestion elle même, au menu (celui du haut) et un dernier pour les "raccourcis" (le grand menu de droite).
Après il et vrai que votre site n'est pas des moins accessibles : ordre de défilement des liens plutôt naturel (donc pas besoin d'utiliser l'attribut "tabindex"), menu de droite situé au dessus des suggestions si la gestion des CSS est déactivé, site utilisable sans JavaScript, ...
On peut encore reprocher l'absence de système permettant "d'expliciter" un acronyme (balise <acronym=""></acronym>), mais je doute que madame Michou soit capable de s'en servir.
100% d'accord pour les accesskeys ca aurait dû être fait.
Pour les accronymes tu veux dire permettre aux utilisateurs d'avoir un moyen d'en mettre dans le corps des commentaires/sugg ?
edit: correction du labsus entre accronyme et accesskey dans la première phrase
Oui, c'est à ça que je pensais, et c'est pour ça que je disais "je doute que madame Michou soit capable de s'en servir."
Par contre, qu'en est il des acceskeys ? Pour rappelle j'en propose un pour la liste des acceskeys (par convention on n'y atribue presque toujours l'acceskey 0), un pour retourner à l'accueil de ce feedback (par convention on n'y atribue presque toujours l'acceskey 1), un pour accéder directement au teste de la suggestion, un pour retourner au menu principal (tout en haut) et un dernier pour accéder au menu de droite. (Le dernier n'est pas utile au personne valide, certe, mais ça peut être utile à d'autres.)
Pour rappelle, on met toujours les acceskeys à des liens. Pour cela on ajoute acceskey="" à la balise <a href="">, ce qui donne <a href="" acceskey="">. (par exemple <a href="index.php" acceskey="1">)
J'ai fait un labsus dans le précédant commentaire entre accesskey et accronyme, j'ai corrigé le commentaire. Tu as parfaitement raison à ce propos.
En ce qui concerne la possibilité de faire des accronymes dans les entrées utilisateurs je doute qu'on mette ca en place c'est vraiment réservé power user et c'est vrai pour plein de chose (quote, liste...). Le but c'est vraiment une application grand public donc tous les machins genre bbcode et autres joyeusetés ne sont pas planifiés. On réflechit à un support des images cependant.
J'en ai d'ailleurs moi même fait la remarque : "je doute que madame Michou soit capable de s'en servir."
Et puis il n'est pas si dur de mettre la signification d'un acronyme à la suite et entre parentèse (Exemple : JID (Identifiant Jabber)), ce qui permet de rétablire les définitions sans être un "power user".
Nous sommes sensibles aux aspects accessibilité évoqués ici, peut-être plus que d'autres.
Nous avons rencontré deux personnes non-voyantes qui ont testé Feedback2.0, nous avons également participé au séminaire Accessiweb cf http://www.accessiweb.org/fr/groupe_travail_accessibilite...
Nous ferons donc attention à maintenir un niveau d'accessibilité élévé, pour autant que ce soit techniquement (vis à vis du spam notamment) et financièrement raisonnable.
Je comprend bien les soucis que cela fait rencontrer, et l'on ne peut que vous féliciter de votre niveau d'accessibilité déjà élevé. Je voulais juste signaler quelques points (un seul en fait) qui me semblaient essentiels et qui ne demandent pas de moyens conséquents.
Je vous encourage à rester dans la voie de la simplicité et de l'accessibilité.
Pouvons-nous savoir quels ont été les commentaires des personnes non-voyantes qui ont testé Feedback ? Ca m'intéresse beaucoup cette partie de l'accessibilité.
Majoritairement une semantique plutôt moyenne du XHTML, notamment en ce qui concerne le score/popularité des suggs ce n'est pas évident à comprendre quand on a que le xhtml. Les étoiles utilisateurs ne sont également pas du tout accessibles.
Bizarrement en revanche les experts en accessibilité eux ce sont arrêtés au fait que plutôt que de procurer exactement les mêmes fonctionnalités avec ou sans javascript qu'on ait préféré les cacher. Notamment le tri des blocs. Sur une application censée être scalable à l'infini ca n'a pas de sens de délivrer un html spécifique à chacun mais c'est une autre histoire. Pas mal ont également trouvé superflu quelques effets ajax du genre le tri qui engendre un mauvais support de la fonction back du navigateur.
En revanche ils ont très justement remarqué que la navigation au clavier est plutôt mal supportée.
Globalement le niveau d'accessibilité est satisfaisant bien que perfectible. Le futur layout très micro-format devrait améliorer les petits problèmes de sémantique de l'actuel.
Globalement le niveau d'accessibilité est satisfaisant bien que perfectible. Le futur layout très micro-format devrait améliorer les petits problèmes de sémantique de l'actuel.

Un autre site qui aide bien pour l'accessibilité d'un site, c'est Opquast (http://fr.opquast.com).
On peut aussi ajouter accessibilite.info (http://www.accessibilite.info), Acces-Pour-Tous (http://www.acces-pour-tous.net), Ocawa (http://www.ocawa.com) et le validateur d'accessibilité de l'APNIC (http://validateur-accessibilite.apinc.org).
Il y a d'ailleurs sûrement plein d'autres site à ajouter à la liste, mais je suis loin de tous les connaitres.
Bigou