Lorsque vous utilisez Opquast, que ce soit via Reporting ou via Desktop, vous avez la possibilité de nous faire des retours sur tel ou tel test si vous n’êtes pas d’accord. Je tiens personnellement à vous remercier car bien souvent vous avez fait progresser les tests en trouvant des cas limites, voire des erreurs grossières. Cependant, il reste 2 retours types que nous recevons régulièrement et qu’il faut une fois pour toutes expliquer ici.
Le W3C, il a dit que c’était valide
Ah, ma préférée… Vous tapez votre URL dans le validateur du W3C et vous obtenez un beau laissez-passer pour votre page. Oui, mais voilà, y’a juste un petit hic, un couac dans la logique. Le navigateur de vos visiteurs, il y a très peu de chance qu’il voit la même chose que le validateur du W3C. Le validateur analyse le code HTML tel qu’il est à la sortie du serveur. Le navigateur va ajouter les librairies ou frameworks Javascript, les widgets Twitter, Facebook, Google+ et les jolis plugins jQuery développés par des punks que vous avez glanés sur la toile. Alors, oui, il y a déjà nettement plus de chances que votre code source ressemble au champ du père Martin après une rave.
La force d’Opquast, c’est de valider le code source tel qu’il est perçu par un navigateur et non pas tel qu’il envoyé par le serveur. Ceci signifie que vous devez récupérer le HTML via Firebug, par exemple, et le copier/coller dans le validateur du W3C pour avoir une idée des dégâts. Se contenter de taper l’URL n’est valable que si aucune librairie, aucun widget, aucune transformation côté client n’est mise en œuvre sur votre page. Typiquement, un diaporama jQuery où les images n’ont pas d’attributs alt ne sera pas vu par le validateur HTML du W3C.
Je fais du HTML 6 et des CSS 4
Certains se plaignent que les tests ne prennent pas en compte des technologies qui ne sont même pas terminées. Si, si. Certains tests supportent une partie de HTML5 ou de CSS3 mais les technologies d’assistance sont légitimement alignées sur des versions stables de HTML et CSS, et pas forcément les plus récentes. Et même lorsque les outils existeront, s’imaginer que la première préoccupation d’une personne en situation de handicap sera de renouveler son matériel relève du fantasme. Même sans déficience particulière, certains d’entre nous ne changent pas de mobile tous les 2 ans (le mien en a 4). Alors oui, ton site en responsive design HTML5 / CSS3 est au top de la geekitude mais ces technos ne sont pas encore stables et posent de vrais problèmes d’accessibilité, de support, etc.
Conclusion
Je trouve assez paradoxal que les 2 soucis majeurs d’incompréhension d’Opquast viennent à la fois d’une perception obsolète (ma page est un code HTML statique sans transformation côté client) et futuriste (j’utilise des technos à l’état de brouillon) du web. J’aime à penser que c’est parce qu’Opquast réussit le pont entre le développeur amateur qui analyse son site personnel et le geek furieux dont la connexion avec la réalité n’est pas toujours 4G ready.
6 commentaires sur “Puisqu’on te dit que c’est pas bon !”
Les commentaires sont clos..
« … les jolis plugins jQuery développés par des punks … »
=> C’est quoi ce racisme anti-punk ? :-p
« j’utilise des technos à l’état de brouillon »
=> Je ne peux m’empêcher de réagir sur ce point. Si on parle de technologies expérimentales, je suis d’accord. Si on parle de technologies dont la spécification W3C est un « working draft » alors je suis méchamment en désaccord.
Notamment pour toutes les APIs JS, les workings draft (notamment DOM et DOM Events) reflètent souvent bien mieux la réalité des implémentations que les « Recommandation » qui sont obsolètes dès qu’elles ont atteint le statut.
« Et même lorsque les outils existeront, s’imaginer que la première préoccupation d’une personne en situation de handicap sera de renouveler son matériel relève du fantasme. »
=> La vraie question que ce point soulève est le support de telle ou telle techno dans les différents matériels/logiciels liés à l’accessibilité. La seule manière de résoudre ces questions, c’est de maintenir des tables de compatibilité et de suivre l’évolution des « parts de marché ».
Est-ce que vous avez des infos là-dessus ?
Concernant les tables de compatibilité, je sais que MDN serait friand de ce genre d’info. Je peux faire une mise en contact et aider à mettre ça en place.
Justement, que les tests soient effectués sur le code généré permet de voir l’étendue des dégâts occasionnés par des scripts jQuery à la noix ou d’autres scripts tiers pourris, je trouve que c’est une vraie force de pouvoir mieux s’en rendre compte ! 🙂
Sur les préoccupations futuristes, c’est surtout une question de référentiel : typiquement, les media-queries n’étaient pas utilisées lors de la création du référentiel Opquast. Du coup, je comprends dans certains cas (raisonnables s’entend) que par exemple l’utilisateur soit surpris d’entendre qu’il n’a pas de version pour petit écran.
@Nico : la bonne pratique actuelle sur le media handheld est un cas historique. Ce dispositif a en effet perdu à peu près tout intérêt depuis la publication de la dernière version des BP Opquast…
Opquast (Le Livre, plus actuel) dit à présent : « Notons qu’une meilleure réponse que les fichiers CSS handheld a été trouvé avec l’apparition des media queries qui permettent non seulement l’adaptation des contenus au type de périphérique mais également aux caractéristiques des appareils. » 😉
@David Bruant, à propos du « support de telle ou telle techno dans les différents matériels/logiciels liés à l’accessibilité » :
Il y a un besoin criant de données de références centralisées, mais je crois savoir qu’un organisme bien connu dans le paysage français de l’accessibilité y travaille, justement 😉
Cela dit, ce n’est qu’une partie de la réponse (une petite même). Ce à quoi renvoyait Fabrice ci-dessus est une situation délicate :
* Les versions d’aides techniques se succèdent aujourd’hui à un rythme de plus en plus rapide, s’agissant des lecteurs d’écran, premiers concernés par HTML5/ARIA en particulier (ils suivent de près les développements récents) ;
* Mais changer de version de Jaws (ou aussi bien de NVDA) n’a rien de trivial, en raison du coût et de la difficulté d’apprentissage (les lecteurs d’écran sont bien plus que des navigateurs et nécessitent un apprentissage, dont trop peu d’utilisateurs bénéficient aujourd’hui). Une nouvelle version, c’est parfois coûteux et souvent très compliqué.
* Ces nouvelles versions peuvent exiger la mise à jour du navigateur ; c’est à dire dans certains cas de l’OS. Complexité, coût et difficulté démultipliés…
En bref : mettre à jour son aide technique est le plus souvent difficile, voire dissuasif. C’est pourquoi le parc logiciel des aides techniques telles que les lecteurs d’écran n’évolue pas aussi vite que celui des navigateurs des autres utilisateurs. C’est un contexte utilisateur qui mérite qu’on y prête une attention particulière : la question est complexe, mais les raisons d’entretenir une compatibilité soutenue avec des versions parfois anciennes ne manquent pas.
David :
> les workings draft […] reflètent souvent bien mieux la réalité des implémentations
La réalité des derniers navigateurs et des geeks, pas celle de la majorité internautes.
Nico :
Typiquement, sur un téléphone, on ne peut pas toujours mettre à jour le navigateur et beaucoup ne supportent pas les media queries. Donc, ça passe par un achat de matériel. Et souvent un téléphone récent rend mieux un site sans media queries qu’un vieux téléphone ne rend un site sans handheld.
@Laurent @Fabrice : certes, les media-queries ont bien remplacé le media handheld (moi le premier, j’ai laissé tomber le media handheld), toutefois attention à ne pas totalement l’enterrer, de mémoire, j’ai vu une chouette présentation (j’en ai discuté avec Élie) à Sud Web où on a pu constater qu’il était encore bien utilisé dans certains cas. L’exemple des « vieux téléphones » est juste aussi.
Je pense qu’un simple assouplissement des critères de cette BP serait suffisant, non ?