Opquast V2 : point à date
Par Élie Sloïm le jeudi 3 décembre 2009, 09:25 - Qualité Web - Lien permanent
Voici quelques informations sur le travail en cours sur la deuxième version des bonnes pratiques Opquast. Le travail sur les bonnes pratiques a commencé il y a un mois. 36 contributeurs ont laissé plus de 2500 commentaires.
Les bonnes pratiques sont maintenant ventilées sur quatre sections :
- Candidates : ce sont les bonnes pratiques qui ont le plus de chances de faire partie du corpus principal. Nous avons 234 bonnes pratiques candidates;
- Propositions : ce sont les bonnes pratiques que le contributeurs ajoutent au jour le jour ;
- Recommandations : ce sont les bonnes pratiques intéressantes, mais non vérifiables par un utilisateur extérieur, ou à valeur ajoutée insuffisante. Elles seront données à titre indicatif, à moins que les contributeurs n'aient des propositions de reformulation valables ;
- Refusées : ce sont les bonnes pratiques qui ne sont valables que dans certains cas très précis, ou même très fortement sujettes à discussion.
Normalement, nous avions prévu de lancer l'appel à commentaires public au 30 novembre, mais entre les missions en cours et la production de la nouvelle version du service en ligne mon-opquast, nous sommes sous l'eau et n'avons pas encore le temps de nous occuper de la plate-forme d'appel à commentaires. Voilà, il faudra attendre un petit peu.
Pour vous faire patienter, voici un petit échantillon de ving-cinq nouveautés, choisies parmi les bonnes pratiques candidates, et présentées dans le désordre. Comme d'habitude, chaque mot a été soigneusement choisi et pesé :
- Le code source de chaque page contient une metadonnée qui en décrit le contenu ;
- Le site propose un fichier sitemap indiquant les contenus à explorer ;
- Les captchas sont dotés d'une solution d'accès alternative ;
- Les contenus publicitaires ou sponsorisés sont identifiés comme tels ;
- En l'absence de fil de syndication, le site fournit aux utilisateurs la possibilité de connaître les nouveaux contenus ou services ;
- L'interlettrage n'est réalisé que via les styles CSS ;
- Le texte des documents PDF internes est sélectionnable ;
- Les animations éventuelles en page d'accueil peuvent être contournées, arrêtées ou fermées ;
- Les processus complexes sont accompagnés de la liste de leurs étapes ;
- L'étape en cours d'une succession d'étapes est indiquée ;
- La page affichée après l'envoi d'un formulaire permet de reprendre directement la navigation ;
- Le focus clavier n'est ni supprimé ni masqué ;
- La navigation sur le site ne provoque pas l'ouverture de fenêtres surgissantes ("popups")
- Les liens provoquant l'ouverture d'un logiciel externe ont un libellé explicite.
- Les mots de passe peuvent être choisis ou changés par l'utilisateur
- Un dispositif sensibilise l'utilisateur sur le degré de sécurisation du mot de passe qu'il choisit
- Le site propose une procédure de réinitialisation du mot de passe en cas de perte ou d'oubli ;
- Le serveur transmet uniquement des contenus compressés aux clients qui les acceptent ;
- Les produits indisponibles font l'objet d'une différenciation visuelle et textuelle ;
- Les éléments audio et/ou vidéo sont déclenchés par l'utilisateur ;
- La consultation du site ne redimensionne pas la fenêtre du navigateur ;
- Les comptes ou abonnements ouverts en ligne peuvent être fermés par le même moyen ;
- Les phrases ou ensemble de mots mis en images ne sont pas morcellés en plusieurs images ;
- La durée des contenus vidéo ou audio est indiquée ;
- Les styles ne sont pas utilisés pour générer du contenu.
Si vous faites partie des inscrits à l'atelier W3 café que nous animons ce soir avec Fabrice Bonny à Paris, nous vous donnons rendez-vous pour une bonne séance de présentation et de travail sur les bonnes pratiques. Si vous n'êtes pas encore inscrit, pas la peine d'essayer, l'atelier est complet depuis un bon moment.
Commentaires
Vivement ce soir, parce qu'il y a quelques items dans la liste qui me font bondir !
@Benoit : indique déjà ici-même celles qui te font bondir, parce que ce soir, on ne va pas faire de débat ouvert sur les BP, sinon, l'atelier pourrait être flingué rien que sur une bonne pratique. Aux arguments, citoyen ;-)
@Elie
OK
En fait, c'est plutôt l'aspect "universel" de ces bonnes pratiques qui me fait bondir, il y en a plusieurs (cf détail ci-dessous) qui ne s'appliquent pas dans certain contexte (entreprise ou autre).
1. Le code source de chaque page contient une metadonnée qui en décrit le contenu
De quoi parle-t-on quand on parle de page : de la réponse à une URI donnée ? La plupart des "pages" actuelles sont fabriquées dynamiquement, les sites statiques que l'on dépose à l'un d'un client ftp ne doivent plus courir les rues.
Partant de là, qu'est ce qui fait qu'on devrait avoir une description différente ? L'URI, mais dans ce cas, ajouter des paramètres non traités côté serveur à une URI donnée modifie l'URI, mais ne va pas modifier le rendu, donc on aura pas de distinction de la description.
2. Le texte des documents PDF internes est sélectionnable ;
Même dans le cas des PDF, pour lequel on a justement utilisé le format PDF pour protéger la propriété du texte (exemple, livres, études de marchés, ...) ?
3. La navigation sur le site ne provoque pas l'ouverture de fenêtres surgissantes ("popups")
Tout à fait d'accord sur le fond de cette remarque, pas sur la formulation, je dirait plutôt : "Ne pas déclencher l'ouverture de fenêtre surgissantes ('popups') ne correspondant pas à une action effective de l'utilisateur. De plus, il doit avoir été signalé clairement (par un texte ou par l'affordance du bouton) à l'utilisateur qu'une fenêtre allait s'ouvrir consécutivement à son action.".
4. Les mots de passe peuvent être choisis ou changés par l'utilisateur
Non applicable dans un contexte d'entreprise par exemple.
5. Le serveur transmet uniquement des contenus compressés aux clients qui les acceptent ;
Cela fait parti intégrante de la norme HTTP. Ou alors je n'ai pas compris le fond de cette remarque.
@benoit : ouf, tu m'as fait peur, j'ai cru qu'on racontait des bêtises ;-)
Bon à savoir : nous allons rédiger des solutions techniques et préciser des exceptions pertinentes.
En revanche, dans tes remarques, je n'ai pas de blocage. Prenons un exemple, en imaginant dans un contexte d'entreprise : "Les postes ne sont pas équipés avec IE6 (imaginaire)". Certaines entreprises vont te répondre : je ne peux pas, pour telle ou telle raison. Cela ne veut pas dire qu'il n'auraient pas intérêt à rendre cette pratique conforme. En l'occurrence, ces entreprises seront non conformes pour cette pratique. C'est un choix non discutable (ou pas ;-).
Dans le cas d'un PDF avec texte non sélectionable, celui-ci sera sans doute totalement innacessible et non référençable. Soit, c'est un choix. La bonne pratique est non conforme, mais elle n'en est pas moins pertinente.
Autre exemple : "je ne peux pas choisir mon mot de passe" (Sous entendu : parce que mon outil ne me le permet pas en entreprise). L'outil est non conforme à cette bonne pratique, et on ne peut rien dire de plus. En revanche, celle-ci vaudrait le coup qu'on s'y penche, parce que tu n'as pas tort, elle est fortement discutable.
Pour celle sur le code source et la meta description : je sais que si tu me propose une page ne respectant pas cette règle, moi, ou les outils d'indexation ne pourront pas extraire une info synthétique. Tu peux ne pas le faire, mais il me semble que c'est une mauvaise pratique.
Voilà, je ne sais pas si je suis très clair, mais je tente, c'est déjà ça ;-)
@Elie
L'exemple que tu donnes avec IE6 est excellent. Cependant en ce qui concerne les PDF ou le choix du mot de passe, ce n'est pas du même ordre. En effet, le contexte (droit d'auteur ou politique de gestion des identités d'entreprise) fait que la bonne pratique est l'inverse de la bonne pratique telle qu'exprimée.
En ce qui concerne la bonne pratique 1 (avec mes numéros), ma remarque porte plutôt sur le fait qu'elle manque de précision. Je ne remet pas en cause le fond de la bonne pratique.
Autre sujet. Lors de la présentation de MonOpquast v1 et de la première liste de bonne pratique, à Paris Web 2008, une auditrice avait fait une remarque que je trouvais pertinente. Il était dommage de ne pouvoir, pour chaque bonne pratique, accéder au thread des experts ayant contribué à établir la pertinence de cette bonne pratique, afin de pouvoir vérifier si cette pertinence est toujours valable dans une circonstance particulière.
Cela a-t-il été pris en compte pour la nouvelle version des bonnes pratiques ?
@Benoit : le fait de mettre un PDF avec texte non sélectionnable sur le Web en espérant que cela protégera du non respect du droit d'auteur n'a pas de sens. Un OCR te permet de récupérer la donnée, et finalement, tu compliques la vie à certains utilisateurs pour une protection réelle quasi nulle. C'est une mauvaise pratique, selon moi (et d'autres j'espère). Dans une entreprise, c'est une pratique, pas une bonne pratique ;-)
Oui, nous allons donner accès aux threads, en vérifiant que cela ne pose pas de problème aux experts, dans le cas contraire, nous devrons anonymer les interventions. Mais la réponse est oui.