Qualité web : la checklist de référence

(en / fr)
Aller aux filtres

Fitres actuels: 226 bonnes pratiques ou recommandations.

1. Chaque image décorative est dotée d'une alternative textuelle appropriée.

Objectif:

Éviter aux utilisateurs placés dans des contextes où les images ne sont pas perceptibles (navigateur texte, lecteur d’écran, navigateur avec images désactivées) d’être perturbés par des informations sur des images qui leur sont inutiles.

Fournir aux robots d’indexation uniquement des informations pertinentes.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité
  • SEO
  • Label Opquast

2. Chaque image-lien est dotée d'une alternative textuelle appropriée.

Objectif:

Permettre aux utilisateurs placés dans des contextes où les images ne sont pas perceptibles (navigateur texte, lecteur d’écran, navigateur avec images désactivées) de comprendre le sens des liens présents sur des images qu’ils ne peuvent voir.

Permettre aux robots d’exploiter l’information véhiculée par les images-liens (pour le référencement, l’indexation, la traduction automatique des alternatives d’images-texte).

Permettre l’affichage d’un texte pertinent pendant le chargement des images.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité
  • SEO
  • Label Opquast

3. Chaque image porteuse d'information est dotée d'une alternative textuelle appropriée.

Objectif:

Permettre aux utilisateurs placés dans des contextes où les images ne sont pas perceptibles (navigateur texte, lecteur d'écran, navigateur avec images désactivées) de comprendre le sens des images qu'ils ne peuvent voir.

Permettre aux robots d'exploiter l'information véhiculée par les images (référencement, indexation, traduction automatique des alternatives d'images-texte).

Permettre l'affichage d'un texte pendant le chargement des images.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité
  • SEO
  • Label Opquast

4. Les objets inclus sont dotés d'une alternative textuelle appropriée.

Objectif:

Fournir un accès à l'information pour les utilisateurs dont le navigateur ou la plateforme ne supporte pas l'inclusion d'objets ou les technologies utilisées dans les objets inclus.

Faciliter l'exploitation de ces contenus par les robots (référencement en particulier).

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité
  • SEO
  • Label Opquast

5. Les contenus générés via les styles sont dotés d'une alternative appropriée.

Objectif:

Permettre aux utilisateurs placés dans des contextes où les styles ne sont pas restitués (navigateur texte, lecteur d'écran, navigateur avec styles désactivés) d’accéder à l’information présente sous forme de contenus générés en CSS (images d’arrière-plan notamment).

Permettre aux robots d'exploiter l'information véhiculée par les styles CSS (référencement, indexation, traduction automatique des alternatives).

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • SEO
  • Label Opquast

6. Les pictogrammes typographiques sont dotés d'une alternative appropriée.

Objectif:

Permettre aux utilisateurs placés dans des contextes où les polices CSS utilisées pour afficher des pictogrammes ne sont pas restituées (navigateur texte, lecteur d'écran, navigateur avec styles désactivés) de comprendre le sens de ces pictogrammes.

Permettre aux robots d'exploiter l'information véhiculée par ces pictogrammes (référencement, indexation, traduction automatique des alternatives).

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • SEO

7. Chaque contenu audio et vidéo est accompagné de sa transcription textuelle.

Objectif:

Permettre aux utilisateurs qui ne peuvent accéder au son ou à l’image proposés d’accéder à une transcription textuelle servant d’alternative.

Permettre aux utilisateurs qui ne peuvent accéder au son d’accéder à l’information contenue dans la vidéo.

Permettre l’exploitation de l’information par des robots pour améliorer son indexation et son référencement, ou encore pour permettre sa traduction par des outils linguistiques en ligne.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • SEO

8. L'information n'est pas véhiculée uniquement par la couleur.

Objectif:

Permettre l’accès à l’information pour les utilisateurs dont le navigateur, la plate-forme, l’aide technique ou encore le handicap (comme le daltonisme) ne permettent pas de visualiser ou de différencier les couleurs.

Rendre l’information accessible aux robots d’indexation.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Rédaction
Tag
  • Accessibilité
  • Label Opquast

9. Les captchas audio peuvent être réécoutés à volonté.

Objectif:

Faciliter l’accès aux contenus ou services protégés par des captchas pour les utilisateurs ne pouvant exploiter les captchas graphiques.

Faciliter l’utilisation des captchas audio. 

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Développement
Tag
  • Accessibilité

10. Les captchas sont accompagnés d'une solution alternative d'accès.

Objectif:

Permettre aux utilisateurs qui ont des difficultés à passer les tests des captchas, en particulier graphiques, d’accéder par un autre moyen aux contenus ou services protégés.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Développement
Tag
  • Accessibilité
  • Sécurité

11. Le code source de chaque page débute par une déclaration de type de document dont la syntaxe est conforme à celles recommandées par le W3C.

Objectif:

Faciliter la validation du code source.

Favoriser un rendu prévisible quel que soit le navigateur (des versions de navigateurs encore en circulation sont susceptibles de s’appuyer sur la syntaxe précise de la DTD pour adopter un mode de rendu CSS).

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

12. Chaque identifiant HTML n'est utilisé qu'une seule fois par page.

Objectif:

Éviter les erreurs de restitution du contenu ou d’interaction via les scripts.

Limiter les risques d’interprétation hasardeuse du Document Object Model (DOM) par des agents utilisateurs différents.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Robustesse

13. Le contenu de chaque page est organisé selon une structure de titres et sous-titres hiérarchisée.

Objectif:

Permettre aux utilisateurs qui le souhaitent de visualiser la structure du contenu de la page et d’y naviguer.

Permettre aux machines et aux outils d’indexation d’extraire le plan de chaque page.

Améliorer le référencement en facilitant l’interprétation du contenu par les robots d’indexation.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité
  • SEO
  • Label Opquast

14. Le site n'impose pas de redirection ou de rafraîchissement automatique côté client.

Objectif:

Permettre aux utilisateurs de conserver la maîtrise de leur environnement de travail.

Éviter des coupures ou des pertes d’information en cours de lecture, notamment pour les utilisateurs équipés de lecteurs d’écran qu’un rafraîchissement ou une redirection temporisée interromprait lors de la consultation.

Ne pas pénaliser la consultation du contenu en mobilité lorsque la qualité du réseau est variable sur une courte échelle de temps.

Permettre à l’utilisateur d’éviter un surcroît non désiré de coût d’utilisation des données mobiles.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

15. Les dates sont présentées dans des formats explicites.

Objectif:

Éviter aux utilisateurs les risques de méprise sur le sens d’une date.

Faciliter la compréhension et la réutilisation des contenus concernés.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Utilisabilité
  • Internationalisation

16. L'emplacement des blocs de navigation est cohérent dans le code source de toutes les pages.

Objectif:

Faciliter la mémorisation de l’organisation des pages et de la navigation pour les utilisateurs de lecteurs d’écran ou pour ceux qui naviguent au clavier.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité

17. Le codage de caractères utilisé est UTF-8.

Objectif:

Recourir à un jeu de caractères international.

Prévenir les défauts d’affichage.

Faciliter la manipulation des contenus par les utilisateurs et les développeurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Utilisabilité

18. Le code source de chaque page contient une métadonnée qui définit le jeu de caractères.

Objectif:

Permettre un affichage hors ligne correct des pages en indiquant au navigateur quel est le jeu de caractères utilisé.

Prévenir le risque de problèmes d’affichage de caractères lié à un fonctionnement parfois hasardeux des mécanismes de rattrapage des navigateurs quand ils ne disposent pas de l’information nécessaire via l’en-tête HTTP content-type.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • SEO

19. Un contenu qui doit être restitué dans un lecteur d'écran ne lui est pas dissimulé.

Objectif:

Permettre une restitution correcte des contenus masqués qui doivent être lus par les lecteurs d’écran.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

20. Le contenu et le sens de chaque page ne sont pas altérés lorsque les styles sont désactivés.

Objectif:

Permettre la compréhension des contenus par les utilisateurs dont le navigateur n’appliquera pas les feuilles de styles du site ou dont le mode d’accès n’est pas visuel.

Séparer rigoureusement les contenus de la présentation pour favoriser leur interopérabilité.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité

21. Les éléments visuellement présentés sous forme de liste sont balisés de façon appropriée dans le code source.

Objectif:

Permettre l’identification des listes par les navigateurs et les aides techniques et donc leur restitution appropriée afin de faciliter leur compréhension par les utilisateurs.

Améliorer la sémantique du contenu des pages et sa réutilisabilité.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité

22. Les textes pouvant être mis en forme via des styles ne sont pas remplacés par des images.

Objectif:

Faciliter l’adaptation du rendu au media (mobile ou autre) ou aux besoins de l’utilisateur (agrandissement de la taille des caractères, modification des couleurs, de la police, de la graisse, de la justification, etc.).

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité
  • SEO

23. La première occurrence d'une abréviation ou d'un acronyme dans le corps de chaque page donne accès à sa signification.

Objectif:

Permettre à l’utilisateur d’accéder rapidement à la signification d’un sigle.

Permettre l’exploitation du contenu par un robot (pour l’établissement d’un index des sigles).

Favoriser le référencement du contenu.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Intégration
  • Développement
  • Rédaction
Tag
  • Accessibilité
  • Utilisabilité

24. Le code source de chaque page ne contient pas d'éléments détournés à des fins de présentation.

Objectif:

Permettre l’exploitation pertinente du code source par les agents utilisateurs (les navigateurs, les robots d’indexation des moteurs de recherche, les plages brailles, etc.).

Alléger le code source en déportant la mise en forme dans les CSS.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

25. Le code source de chaque page ne contient pas d'éléments ou d'attributs de présentation.

Objectif:

Favoriser l’adaptation de la mise en forme des contenus par les agents utilisateurs, selon les besoins de l’utilisateur.

Réduire le poids du code source des pages, en incitant à mutualiser et à externaliser les informations de mise en forme grâce à CSS.

Faciliter la réutilisation du contenu sans contraintes liées à sa mise en forme initiale.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Écoconception

26. Le site propose au moins un moyen de contact.

Objectif:

Faciliter le retour d’information de la part des utilisateurs.

Favoriser la confiance en garantissant d’entrée de jeu à l’utilisateur la possibilité d’un recours en cas de difficultés.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité
  • E-commerce
  • Confiance

27. Le site propose au moins deux moyens de contact.

Objectif:

Optimiser les possibilités de retour d’information de la part des utilisateurs.

Éviter de mettre l’utilisateur en difficulté en cas d’indisponibilité ou de problèmes d’utilisation de l’un des moyens de contact.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité
  • E-commerce

28. Les coordonnées postales et téléphoniques de la représentation locale ou du siège social des sociétés et organisations sont indiquées.

Objectif:

Favoriser l’identification de l’entité responsable des contenus et des services.

Fournir un moyen de contact alternatif.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • Utilisabilité
  • E-commerce
  • Label Opquast

29. Chaque demande d'information fait l'objet d'un accusé de réception.

Objectif:

Informer les utilisateurs de la prise en compte de leur demande.

Permettre aux utilisateurs d’obtenir une confirmation archivable de la bonne réception de leur demande d’information.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • E-commerce
  • Label Opquast

30. Les délais de réponse aux demandes d'information sont indiqués.

Objectif:

Informer les utilisateurs sur les délais chiffrés de réponse.

Limiter les risques de relance de la part des utilisateurs.

Rassurer sur la capacité à prendre en compte les demandes.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • Utilisabilité

31. Les données contenues dans le Whois du site permettent de le relier directement à son propriétaire.

Objectif:

Faciliter l'identification de l'entité ou de la personne responsable des contenus ou des services.

Permettre à des utilisateurs de s'assurer qu'ils sont bien sur le bon site et non sur un site de phishing, par exemple.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • E-commerce

32. Le titre de chaque page permet d'identifier le site.

Objectif:

Permettre aux utilisateurs d'identifier immédiatement le site dans les onglets, les favoris, dans la fenêtre du navigateur ou encore dans les lecteurs d'écran.

Améliorer le référencement du site et sa présentation dans les moteurs de recherche.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
  • Rédaction
Tag
  • Accessibilité
  • SEO
  • Label Opquast

33. Le titre de chaque page permet d'identifier son contenu.

Objectif:

Permettre aux utilisateurs d'identifier immédiatement la nature des contenus de chaque page dans les onglets, les favoris, dans la fenêtre du navigateur ou encore dans les lecteurs d'écran.

Améliorer le référencement des pages et leur présentation dans les moteurs de recherche.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • SEO
  • Label Opquast

34. Les contenus publicitaires ou sponsorisés sont identifiés comme tels.

Objectif:

Permettre une identification immédiate des contenus publicitaires ou sponsorisés.

Éviter les confusions entre contenus rédactionnels et publicitaires.

Prévenir les risques associés aux conflits d'intérêt.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Rédaction
Tag
  • Utilisabilité

35. Les informations relatives aux droits de copie et de réutilisation sont accessibles depuis toutes les pages.

Objectif:

Informer les utilisateurs sur les conditions sous lesquelles sont publiés les contenus.

Informer les utilisateurs sur les conditions de copie et de réutilisation.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • Utilisabilité

36. Le site fournit aux utilisateurs la possibilité de connaître les nouveaux contenus ou services.

Objectif:

Permettre aux utilisateurs d'identifier immédiatement les nouveaux contenus ou services en ligne.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • SEO

37. Si le site propose un espace personnel ou abonné, il est possible de sauvegarder les contenus personnels dans un format standard.

Objectif:

Permettre l'archivage des contenus créés par l'utilisateur.

Éviter à l'utilisateur d'éventuelles saisies redoublées en cas de réutilisation des contenus.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité
  • E-commerce

38. Un lexique ou un glossaire adapté au public visé explique le vocabulaire sectoriel ou technique.

Objectif:

Permettre aux utilisateurs de comprendre les contenus sectoriels ou à caractère technique.

Faciliter l'utilisation d'un service.

Améliorer le référencement sur des mots-clés ou expressions techniques.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • SEO

39. L'achat d'un produit ou service est possible sans création de compte.

Objectif:

Permettre à l’acheteur de commander immédiatement.

Lever la barrière de la création de compte.

Augmenter le taux de conversion.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • E-commerce

40. Aucun produit ni service annexe n'est ajouté au panier de commande sans que cette action soit déclenchée par l'utilisateur.

Objectif:

Laisser à l'utilisateur le contrôle de sa commande.

Ne pas compromettre la relation de confiance avec l'utilisateur.

Éviter toute forme de vente forcée.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • E-commerce
  • Confiance

41. La disponibilité des produits est indiquée avant la validation définitive de la commande.

Objectif:

Permettre d'anticiper d'éventuelles difficultés et une augmentation du délai de livraison.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

42. Le délai de livraison estimé est indiqué avant la validation définitive de la commande.

Objectif:

Permettre aux utilisateurs d'identifier la date réelle à laquelle le bien commandé sera effectivement en leur possession.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

43. Les modalités de récupération d'un bien dématérialisé sont précisées avant la commande.

Objectif:

Permettre à l’utilisateur d’anticiper les conditions et les moyens d’accès au service ou au bien dématérialisé.

Éviter les déceptions et le traitement de réclamations.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce

44. La modification de la quantité de chaque article, l'ajout et la suppression d'un ou plusieurs articles restent possibles avant la validation définitive de la commande.

Objectif:

Permettre à l'utilisateur de modifier facilement sa commande.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité
  • E-commerce
  • Label Opquast

45. La nature et les caractéristiques quantifiables des produits et services sont indiquées.

Objectif:

Permettre aux utilisateurs d'identifier précisément la nature et les spécifications des produits proposés.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce
  • SEO
  • Label Opquast

46. La période et les conditions de validité des offres spéciales et promotions sont indiquées.

Objectif:

Permettre aux utilisateurs d'identifier la période au cours de laquelle ils peuvent bénéficier des offres proposées.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce

47. Le numéro d'immatriculation délivré aux sociétés ou organisations au terme des procédures légales d'enregistrement en vigueur dans leur pays est indiqué.

Objectif:

Fournir aux utilisateurs une indication vérifiable de l'existence officielle de la structure qui propose les contenus ou le service.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce

48. Le sous-total détaillé est indiqué avant la validation définitive de la commande.

Objectif:

Permettre à l'utilisateur de connaître le détail du montant de sa commande.

Lever un frein à la validation d'une commande.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • E-commerce

49. Les conditions de financement sont indiquées.

Objectif:

Permettre à l'utilisateur d'identifier le montant total qu'il aura à payer et les différentes composantes de ce montant.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce

50. Les conditions de fonctionnement du service après-vente sont indiquées.

Objectif:

Permettre aux utilisateurs de connaître les conditions d'assistance en cas de difficulté.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

51. Les conditions de débit ou d'encaissement sont spécifiées avant la validation définitive de la commande.

Objectif:

Permettre aux utilisateurs d'identifier précisément les conditions de l'encaissement.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce

52. Les conditions de garantie sont indiquées.

Objectif:

Permettre aux utilisateurs d'identifier précisément la nature des services associés et leur coût.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

53. Les conditions de vente ou d'utilisation sont accessibles depuis toutes les pages.

Objectif:

Permettre un accès facile et permanent à toutes les conditions de réalisation du service.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

54. Les informations relatives à la zone de livraison des produits ou de réalisation des services sont indiquées.

Objectif:

Éviter une navigation et des commandes inutiles, voire une perte de temps pour l'utilisateur ainsi que pour la structure qui propose les biens ou les services.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

55. Les moyens de paiement acceptés et les procédures correspondantes sont indiqués.

Objectif:

Permettre aux utilisateurs d'anticiper le mode et les conditions de paiement et de vérifier avant la commande s'ils pourront la mener à son terme.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

56. Les horaires et tarifs de fonctionnement des services mis à la disposition des utilisateurs sont indiqués.

Objectif:

Permettre aux utilisateurs de connaître les services mis à leur disposition et leur fonctionnement.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

57. Les recours en cas de litige sont indiqués dans les conditions générales de vente ou d'utilisation.

Objectif:

Rassurer l'internaute avant l'achat.

Donner à l'acheteur toutes les informations liées à son achat, que celui-ci se passe bien ou non.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce

58. L'adresse et les conditions de retour des produits sont indiquées.

Objectif:

Permettre aux utilisateurs d'anticiper d'éventuelles difficultés d'utilisation et/ou de fonctionnement du bien ou du service proposé.

Réduire le nombre de sollicitations du service client.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

59. Le mode de dépôt et la procédure de traitement des réclamations sont indiqués.

Objectif:

Permettre aux utilisateurs de comprendre ou d'anticiper d'éventuelles difficultés sur le site ou lors de la transaction.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce

60. Les conditions de remboursement sont indiquées.

Objectif:

Permettre aux utilisateurs d'identifier précisément les pièces nécessaires en cas de nécessité de retour du produit.

Anticiper d'éventuels problèmes en cas de demande de remboursement réalisée après le délai légal.

Diminuer le nombre de démarches inutiles et le nombre de demandes au support client.

Augmenter le taux de transformation d'un site e-commerce.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

61. Les matériels et logiciels nécessaires au fonctionnement du service sont indiqués avant la validation de la commande.

Objectif:

Permettre à l’utilisateur d’anticiper les conditions et les moyens d’utilisation du service.

Limiter les réclamations.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce

62. Les prix affichés mentionnent le détail des taxes et suppléments éventuels ainsi que le montant hors taxes.

Objectif:

Permettre aux utilisateurs d'identifier précisément et avant l'achat le montant total qu'ils auront à payer.

Permettre aux utilisateurs d'identifier précisément les montants déductibles et les différentes imputations.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce

63. Une adresse de livraison différente de l'adresse de facturation peut être spécifiée.

Objectif:

Permettre aux utilisateurs de faire livrer un achat sur le lieu de leur choix.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • E-commerce
  • Label Opquast

64. Le site accepte au moins deux moyens de paiement.

Objectif:

Permettre aux utilisateurs de choisir le mode de paiement qui leur convient le mieux dans leur contexte.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • E-commerce
  • Label Opquast

65. La référence de la transaction est affichée au client après la validation de sa commande.

Objectif:

Permettre aux utilisateurs d'afficher et éventuellement d'imprimer une trace de leur commande.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • E-commerce

66. Les mentions d'appartenance à un ordre ou groupe professionnel, d'un label ou d'une récompense sont accompagnées d'un lien vers la source.

Objectif:

Donner un accès immédiat à l'utilisateur pour lui permettre de comprendre de quoi il s'agit.

Permettre à l'utilisateur de vérifier par lui-même l'information.

Accroître le degré de confiance ou de crédibilité.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce
  • Confiance

67. Les produits indisponibles font l'objet d'une différenciation visuelle et textuelle.

Objectif:

Permettre à l'utilisateur d'identifier immédiatement et sans confusion possible les produits indisponibles.

Éviter l'effet de déception si un utilisateur débute une procédure de commande et s'aperçoit tardivement de l'indisponibilité du produit désiré.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Rédaction
Tag
  • E-commerce
  • Label Opquast

68. Un courriel indiquant la référence de la transaction et les données de la commande est envoyé suite à la validation.

Objectif:

Donner à l'utilisateur une confirmation des informations relatives à la commande.

Permettre à l'utilisateur de conserver un historique de la transaction ailleurs que dans le site.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • E-commerce

69. Chaque réclamation fait l'objet d'un accusé de réception.

Objectif:

Permettre à l'utilisateur d'obtenir une confirmation de sa demande en-dehors du contexte de la navigation sur le site.

Éviter au service client de recevoir plusieurs demandes concernant une même réclamation.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • E-commerce

70. Le site propose au moins un moyen de contacter le responsable des réclamations.

Objectif:

Permettre aux utilisateurs de s'adresser ou d'adresser directement leurs réclamations au bon interlocuteur.

Rassurer les internautes sur le fait qu'ils pourront facilement interagir avec le service des réclamations en cas de problème.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce

71. Le site propose au moins un moyen de contacter le modérateur des espaces publics.

Objectif:

Permettre aux utilisateurs de contacter le modérateur pour demander une correction, poser une question ou signaler des abus.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Confiance
  • Espaces publics

72. Les espaces publics proposent au moins un moyen de signaler les abus.

Objectif:

Faciliter le signalement de contenus illégaux ou inappropriés.

Accélérer la détection de ces contenus.

Limiter les risques de consultation de contenus illégaux ou inappropriés.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Confiance
  • Espaces publics

73. Les conditions de modération des espaces publics sont indiquées.

Objectif:

Expliquer aux utilisateurs pour quelles raisons et dans quelle mesure leurs publications peuvent être modérées.

Limiter le nombre de réclamations des utilisateurs ne voyant pas leur publication apparaître.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Confiance
  • Espaces publics

74. Les contenus ou fichiers destinés à des espaces publics peuvent être vérifiés avant leur envoi définitif.

Objectif:

Permettre à l'utilisateur de vérifier sa saisie en contexte et, si nécessaire, de la corriger avant envoi.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Espaces publics

75. Les informations destinées à des espaces publics peuvent être prévisualisées sous la forme où elles seront affichées.

Objectif:

Permettre à l'utilisateur de vérifier et de corriger si nécessaire sa saisie en tenant compte de la présentation finale du contenu concerné.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Espaces publics

76. La durée des contenus vidéo ou audio est indiquée.

Objectif:

Informer l'utilisateur afin qu'il puisse décider en connaissance de cause de consulter ou de télécharger ou non le contenu concerné.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
  • Rédaction
Tag
  • Utilisabilité

77. Le format des fichiers proposés en téléchargement est indiqué.

Objectif:

Permettre aux utilisateurs de savoir en temps utile si leurs outils les autorisent à consulter les fichiers proposés en téléchargement.

Réduire la charge serveur en évitant les téléchargements inutiles.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
  • Rédaction
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

78. La taille des fichiers internes proposés en téléchargement est indiquée.

Objectif:

Informer de façon préventive les utilisateurs sur la quantité de données à télécharger.

Permettre aux utilisateurs de différer le téléchargement en connexion bas débit ou mobile.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
  • Rédaction
Tag
  • Accessibilité
  • Utilisabilité

79. La langue des fichiers en téléchargement est précisée lorsqu'elle diffère de celle de la page d'origine.

Objectif:

Éviter aux utilisateurs des téléchargements inutiles.

Informer les utilisateurs sur les fichiers téléchargés.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • Utilisabilité
  • Internationalisation

80. Les animations, sons et clignotements peuvent être mis en pause.

Objectif:

Laisser à l'utilisateur le contrôle des animations lors de la consultation du contenu.

Ne pas perturber l'attention en imposant des éléments pouvant gêner celle-ci.

Permettre la consultation pas à pas d'animations séquentielles ou de contenus sonores.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

81. Le déroulement des animations ne bloque pas la navigation ou l'accès aux contenus.

Objectif:

Fournir aux utilisateurs un accès direct et immédiat aux contenus, même lorsque l'administrateur du site décide de proposer une animation ou une publicité préalable.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Intégration
Tag
  • Utilisabilité
  • Label Opquast

82. Les sons et vidéos sont déclenchés par l'utilisateur.

Objectif:

Laisser à l'utilisateur le contrôle de l'interface sonore et visuelle lors de la consultation du site.

Ne pas surprendre l'utilisateur par la diffusion inattendue d'un contenu audio.

Ne pas imposer à l'utilisateur le déclenchement d'un contenu animé.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

83. Le texte des documents PDF internes est sélectionnable.

Objectif:

Permettre le référencement des contenus des documents PDF.

Faciliter la manipulation et la réutilisation du contenu des documents PDF.

Garantir la lisibilité des contenus des documents PDF.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • Utilisabilité
  • SEO

84. Les documents PDF internes sont dotés d'une structure de titres.

Objectif:

Permettre aux utilisateurs d’accéder directement à différentes sections d’un document PDF.

Fournir une structure de titres aux utilisateurs qui en ont besoin.

Permettre la consultation d’un PDF via une aide technique.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • Utilisabilité
  • SEO

85. Chaque champ de formulaire est associé dans le code source à une étiquette qui lui est propre.

Objectif:

Faciliter la compréhension des données attendues dans les formulaires.

Permettre aux aides techniques d'accessibilité de restituer les champs de formulaires en les associant systématiquement à une étiquette indiquant leur rôle et la nature de la saisie attendue.

Faciliter la saisie en permettant de sélectionner le champ via un clic sur son étiquette aussi bien que sur le champ lui-même (particulièrement en cas de case à cocher ou de case radio).

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Label Opquast

86. Les informations complétant l'étiquette d'un champ sont associées à celui-ci dans le code-source

Objectif:

Optimiser le rendu dans les lecteurs d’écran en permettant d’expliciter les étiquettes des champs de formulaire.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

87. L'étiquette de chaque champ de formulaire indique si la saisie est obligatoire.

Objectif:

Permettre aux utilisateurs de savoir à l'avance si un champ est obligatoire.

Prévenir les erreurs avant qu'elles ne surviennent.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

88. L'étiquette de chaque champ de formulaire indique, le cas échéant, quel format de saisie doit être respecté.

Objectif:

Limiter le risque d'erreurs de saisie.

Limiter les risques associés à l'envoi de données erronées ou impossibles à exploiter.

Éviter que l'utilisateur ne renonce à poursuivre faute d'information sur la saisie attendue.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Accessibilité
  • Utilisabilité
  • E-commerce
  • Label Opquast

89. L'utilisateur est averti lorsqu'une saisie est sensible à la casse.

Objectif:

Éviter le risque d'erreur et donc éviter à l'utilisateur de devoir remplir plusieurs fois un même champ.

Éviter l'incompréhension de l'utilisateur qui pense avoir rempli correctement le champ et qui le voit signalé en erreur.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité

90. La création d'un mot de passe par l'utilisateur fait l'objet d'un mécanisme de prévention des erreurs de saisie.

Objectif:

Éviter à l'utilisateur de saisir un mot de passe qui ne correspond finalement pas à celui qu'il a souhaité ou mémorisé.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité
  • E-commerce

91. Les caractères saisis dans un champ de mot de passe peuvent être affichés en clair.

Objectif:

Faciliter la saisie des mots de passe, notamment sur les claviers virtuels des terminaux mobiles.

Prévenir les erreurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Intégration
Tag
  • Utilisabilité

92. Chaque étiquette de formulaire est visuellement rattachée au champ qu'elle décrit.

Objectif:

Permettre aux utilisateurs d'identifier sans ambiguïté les champs de formulaire et la nature des informations à saisir.

Prévenir les erreurs de saisie.

Faciliter et accélérer l'usage du formulaire.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Design
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

93. En cas de rejet des données saisies dans un formulaire, les champs contenant les données rejetées sont indiqués à l'utilisateur.

Objectif:

Donner un retour à l'utilisateur sur l'action qu'il vient d'effectuer.

Guider l'utilisateur directement vers les éléments sur lesquels il doit agir.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

94. En cas de rejet des données saisies dans un formulaire, les raisons du rejet sont indiquées à l'utilisateur.

Objectif:

Aider l'internaute à comprendre ce qu'on attend et, ainsi, faciliter le passage à l'étape suivante.

Éviter la frustration de l'utilisateur face à une erreur dont il n'aurait pas la solution immédiate.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

95. En cas de rejet des données saisies dans un formulaire, toutes les données saisies peuvent être modifiées par l'utilisateur.

Objectif:

Laisser la main à l'utilisateur sur la totalité des informations qu'il donne.

Faciliter la correction des erreurs commises par l'utilisateur.

Permettre à l'utilisateur de modifier des informations sur lesquelles il voudrait revenir.

Éviter que l'utilisateur ne quitte le formulaire avant validation définitive.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • E-commerce
  • Label Opquast

96. Lors de la saisie d'un formulaire réparti sur plusieurs pages, un récapitulatif global est affiché avant l'envoi définitif.

Objectif:

Donner à l'utilisateur une vue globale de ce qu'il a saisi dans les pages précédentes.

Permettre à l'utilisateur de vérifier l'ensemble des informations d'une procédure complexe avant la soumission définitive.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité
  • E-commerce
  • Label Opquast

97. La page affichée après l'envoi d'un formulaire permet de reprendre directement la navigation.

Objectif:

Éviter de dérouter l'utilisateur en le menant à une page en impasse, y compris par l'utilisation de la fonction « page précédente » du navigateur.

Limiter le risque de double envoi de formulaire.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité

98. La soumission d'un formulaire est suivie d'un message indiquant la réussite ou non de l'action souhaitée.

Objectif:

Fournir à l'utilisateur un retour immédiat et explicite sur l'action qu'il vient d'effectuer.

Éviter la frustration d'un utilisateur qui pense que le processus s'est déroulé avec succès alors qu'il y a eu un problème.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité
  • E-commerce
  • Label Opquast

99. Les processus complexes sont accompagnés de la liste de leurs étapes.

Objectif:

Donner de la visibilité à l'utilisateur sur les actions qu'il va réaliser (temps, ordre des étapes, informations nécessaires pour les accomplir, etc.).

Éviter que l'utilisateur ne se sente piégé dans un processus dont il n'avait pas prévu la durée.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité
  • Label Opquast

100. L'étape en cours d'un processus complexe est indiquée.

Objectif:

Permettre à l'utilisateur d'identifier le degré d'avancement dans un processus.

Rassurer l'utilisateur lors de la réalisation d'un processus complexe.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Design
Tag
  • Utilisabilité
  • Label Opquast

101. Chaque étape d'un processus complexe permet de revenir à l'étape précédente.

Objectif:

Faciliter l’utilisation des formulaires répartis sur plusieurs pages successives.

Réduire les risques d’erreurs de saisie.

Limiter les risques d’abandon en cours de processus.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité

102. L'utilisateur est averti de la perte d'information en cas d'utilisation de l'historique de son navigateur dans un processus complexe.

Objectif:

Faciliter l’utilisation des formulaires répartis sur plusieurs pages successives.

Limiter les risques d’abandon en cours de processus.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité

103. La navigation dans un processus complexe ne provoque pas la perte des données précédemment soumises.

Objectif:

Faciliter la saisie et sa correction dans les formulaires répartis par étapes.

Limiter les risques d’abandon en cours de procédure.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité

104. Le copier coller est possible dans les champs de formulaire.

Objectif:

Faciliter la saisie dans les formulaires.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Utilisabilité
  • Label Opquast

105. Les éléments d'une liste déroulante qui peuvent être regroupés le sont de manière appropriée.

Objectif:

Permettre aux aides techniques de restituer à l'utilisateur une liste dont l'organisation est clairement perceptible et qui facilite le passage d'un élément du contenu à l'autre.

Favoriser un rendu approprié des listes déroulantes complexes dans tous les navigateurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité

106. Les listes d'options de formulaires sont présentées dans un ordre identifiable.

Objectif:

Permettre aux utilisateurs d'accéder rapidement à l'item de liste recherché.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité

107. Chaque lien est doté d'un intitulé dans le code source.

Objectif:

Éviter aux utilisateurs d'avoir uniquement une URL peu compréhensible en guise de libellé.

Éviter les liens qui deviennent invisibles lorsque les styles CSS ou les images d'arrière-plan ne sont pas pris en compte.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

108. Le soulignement est réservé aux hyperliens.

Objectif:

Éviter les clics inutiles sur des contenus soulignés perçus comme des hyperliens.

Faciliter l'identification des liens.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Rédaction
Tag
  • Utilisabilité
  • Label Opquast

109. Les hyperliens sont visuellement différenciés du reste du contenu.

Objectif:

Permettre aux utilisateurs d'identifier facilement les liens au fil du texte ainsi que les blocs de navigation.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

110. Le site n'applique pas le même style aux liens visités et non visités.

Objectif:

Faciliter l'identification des contenus déjà visités.

Faciliter l'identification des contenus restant à découvrir.

Inciter à la navigation sur de nouvelles pages.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Intégration
Tag
  • Utilisabilité

111. Le site n'impose pas d'interdiction ou de restriction à la mise en place des liens entrants.

Objectif:

Faciliter le référencement à travers l'obtention de backlinks.

Augmenter la visibilité du site pour les utilisateurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • SEO
  • Label Opquast

112. Le survol ou l'activation des hyperliens ne modifie pas la mise en page.

Objectif:

Limiter les difficultés à cliquer sur un lien lorsque celui-ci occupe plus d'espace en mode survolé ou activé.

Limiter les effets de clignotement ou de déplacement de contenus lors du survol d'un lien ou de sa prise de focus clavier.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Utilisabilité

113. Les hyperliens de même nature ont des couleurs, des formes et des comportements identiques sur toutes les pages.

Objectif:

Accélérer l'apprentissage du fonctionnement de l'interface.

Améliorer l'identification des liens et de leurs fonctions respectives.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Design
Tag
  • Utilisabilité

114. Tous les hyperliens internes du site sont valides.

Objectif:

Éviter les erreurs 404 en cours de navigation.

Faciliter un accès rapide à tous les contenus.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • SEO

115. Le libellé de chaque hyperlien décrit sa fonction ou la nature du contenu vers lequel il pointe.

Objectif:

Permettre aux utilisateurs d'identifier précisément la nature du lien et d'éviter des actions erronées.

Permettre aux outils d'indexation d'associer un libellé à une ressource.

Permettre aux lecteurs d'écran d'en indiquer la cible de façon explicite et d'éviter de désorienter les utilisateurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • SEO
  • Label Opquast

116. Les hyperliens consécutifs sont séparés visuellement.

Objectif:

Éviter les confusions entre deux liens consécutifs.

Améliorer la lisibilité des liens et des contenus.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Rédaction
Tag
  • Utilisabilité

117. Les hyperliens internes et externes sont différenciés.

Objectif:

Avertir clairement l'internaute du fait qu'il va quitter le service en ligne qu'il est en train de visiter.

Faciliter le repérage des liens externes

Checklist
  • Bonnes pratiques
Phase projet
  • Design
Tag
  • Utilisabilité
  • Internationalisation

118. L'identité de l'auteur, de la société ou de l'organisation est indiquée.

Objectif:

Rassurer l'utilisateur en lui permettant d'identifier directement l'auteur (au sens large).

Limiter les risques de défiance.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • SEO

119. L'identité de la personne ou du service responsable des contenus est indiquée.

Objectif:

Permettre aux utilisateurs d'identifier sans ambiguïté un interlocuteur physique capable de répondre aux questions éventuelles sur les contenus proposés, ou d'assumer les responsabilités liées à ces contenus.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Utilisabilité

120. La page d'accueil expose la nature des contenus et services proposés.

Objectif:

Donner aux utilisateurs une vision immédiate de la nature du site et des contenus proposés.

Éviter les recherches inutiles.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • SEO

121. Le nom du site et/ou le nom de l'auteur sont indiqués sur chaque page.

Objectif:

Permettre à l'utilisateur d'identifier immédiatement et en permanence l'auteur, l'entité qui administre le site ou le site lui-même le cas échéant.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • SEO

122. Si le site est réservé ou destiné à un public spécifique, ce public est mentionné au moins sur la page d'accueil.

Objectif:

Éviter des consultations inutiles.

Délivrer un avertissement aux utilisateurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • Utilisabilité

123. L'adresse complète et le numéro de téléphone des sociétés et organisations sont accessibles depuis toutes les pages du site.

Objectif:

Donner aux utilisateurs qui le souhaitent la possibilité d'accéder sans difficulté aux moyens de contact téléphoniques et postaux.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • E-commerce
  • SEO

124. La racine du site contient des instructions pour les robots d'indexation.

Objectif:

Permettre un référencement ciblé.

Améliorer le guidage des outils de recherche.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • SEO
  • Écoconception
  • Label Opquast

125. Le code source de chaque page contient une métadonnée qui en décrit le contenu.

Objectif:

Permettre aux outils de recherche et d'indexation d'extraire des informations à propos du contenu des pages et ainsi d'améliorer la restitution aux utilisateurs des résultats de recherche.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • SEO
  • Label Opquast

126. Le code source des pages contient un appel valide à un icône de favori.

Objectif:

Améliorer l'identification visuelle du site et de ses pages.

Faciliter l'identification dans le navigateur et dans les favoris ou signets.

Permettre l'affichage, l'appel, et la mémorisation éventuelle de l'icône de favori par tous les navigateurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Utilisabilité
  • Label Opquast

127. L'extension utilisée est cohérente avec l'identité, l'activité, la zone géographique couverte ou avec le nom de domaine.

Objectif:

Contribuer à la compréhension immédiate de l'identité, de l'activité ou de la zone géographique du site.

Améliorer la capacité des utilisateurs à mémoriser l'adresse du site et à la retrouver en cas d'oubli.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • SEO

128. Le site propose un fichier sitemap indiquant les contenus à explorer.

Objectif:

Mettre à disposition des informations synthétiques et lisibles par les machines sur l'ensemble des contenus proposés.

Le fichier sitemap permet d'indiquer aux moteurs majeurs l'intégralité des contenus à indexer. L'intérêt premier est pour les sites très profonds comme les catalogues en ligne avec plusieurs milliers de produits ou encore des sites dont le contenu est difficilement accessible linéairement comme des encyclopédies.

L'intérêt pour un site de quelques pages est faible voire inexistant, mais la présence du fichier ne sera pas pénalisante.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • SEO
  • Écoconception
  • Label Opquast

129. Si le site déclare respecter un ou plusieurs standards ou référentiels, un lien est proposé vers chacun d'entre eux.

Objectif:

Faciliter la compréhension par l'utilisateur des règles de qualité, d'accessibilité ou autres appliquées sur le site.

Accroître la confiance dans les informations délivrées sur le site.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce
  • Confiance

130. L'indicatif international est disponible pour tous les numéros de téléphone.

Objectif:

Permettre l'utilisation immédiate du contact téléphonique quel que soit le contexte utilisateur.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Internationalisation

131. Le pays est précisé pour toutes les adresses postales.

Objectif:

Permettre aux utilisateurs d'identifier immédiatement le pays associé à l'adresse postale, sans ambiguïté et sans avoir recours à d'autres éléments (ville, région, code postal, numéro de téléphone).

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Internationalisation

132. Le code source de chaque page indique la langue principale du contenu.

Objectif:

Favoriser l'indexation des contenus selon leur langue.

Faciliter la traduction automatique.

Permettre une lecture correcte du contenu par un outil de synthèse vocale.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Internationalisation
  • SEO
  • Label Opquast

133. La langue principale de la page cible d'un hyperlien est identifiable lorsqu'elle diffère de celle de la page d'origine.

Objectif:

Permettre aux utilisateurs et outils de navigation d'anticiper le changement de langue en cours de navigation.

Éviter aux utilisateurs de se rendre sur une page dont ils ne comprennent pas la langue.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Utilisabilité
  • Internationalisation

134. Chaque changement de langue est signalé.

Objectif:

Permettre aux aides techniques d'interpréter correctement les contenus exprimés dans une autre langue.

Faciliter le travail des outils de traduction automatiques.

Permettre aux outils d'indexation d'extraire des chaînes dans une langue donnée.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • Internationalisation

135. Les liens d'accès aux versions traduites pointent directement vers la traduction de la page courante.

Objectif:

Donner un accès direct et immédiat aux traductions de la page courante.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Utilisabilité
  • Internationalisation

136. Les liens vers les versions équivalentes de la page ou du site sont rédigés dans leur langue cible.

Objectif:

Permettre l'identification immédiate du lien pertinent par l'utilisateur.

Rendre compréhensible des liens spécialement créés pour un public spécifique.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Utilisabilité
  • Internationalisation

137. Le serveur ne force pas la redirection de la version desktop vers la version mobile.

Objectif:

Laisser le choix à l’utilisateur de la version ayant ses préférences.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Mobile

138. Il est possible de basculer depuis chaque page entre les versions mobile et desktop du site.

Objectif:

Permettre à l’utilisateur de choisir le mode de rendu le plus adapté à ses préférences et à son contexte.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité
  • Mobile

139. Le site ne bloque pas les fonctionnalités de zoom du navigateur.

Objectif:

Permettre aux utilisateurs d’adapter le rendu à leurs besoins ou à leurs préférences en recourant au zoom graphique.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Mobile
  • Label Opquast

140. Les alertes javascript et fenêtres modales invitant à l'installation d'une application mobile ne se produisent qu'une seule fois par session.

Objectif:

Éviter les sollicitations imposées et répétitives.

Faciliter la navigation dans le site.

Prévenir d’éventuelles pénalités de la part des moteurs de recherche.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Développement
Tag
  • Utilisabilité
  • Mobile

141. La promotion de l'application mobile ne recourt ni aux alertes javascript ni aux fenêtres modales.

Objectif:

Éviter les sollicitations imposées et répétitives.

Faciliter la navigation dans le site.

Prévenir d’éventuelles pénalités de la part des moteurs de recherche.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité
  • Label Opquast

142. Le site propose un ou plusieurs mécanismes dédiés à l'adaptation aux terminaux mobiles.

Objectif:

Faciliter la consultation sur les terminaux mobiles.

Améliorer le positionnement dans les outils d’indexation qui prennent ce critère en compte.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Intégration
Tag
  • Utilisabilité
  • Mobile
  • Label Opquast

143. Les champs de saisie de type mail, URL, téléphone, nombre, recherche, mots de passe, heure et date sont dotés du type approprié.

Objectif:

Permettre l’utilisation des claviers virtuels adaptés aux différents types de saisie sur les terminaux mobiles.

Faciliter la validation de la saisie. 

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Développement
Tag
  • Utilisabilité
  • Mobile
  • Label Opquast

144. Les numéros de téléphone sont activables via le protocole approprié.

Objectif:

Permettre l’utilisation des claviers virtuels adaptés aux différents types de saisie sur les terminaux mobiles.

Faciliter la validation de la saisie.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Développement
Tag
  • Utilisabilité
  • Mobile

145. Chaque iframe est doté d'une description.

Objectif:

Permettre une restitution alternative d'un iframe sous la forme d'un lien correctement libellé vers le contenu inclus.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

146. Le site n'emploie pas la technique des jeux de cadres.

Objectif:

Améliorer la consultation et la navigation pour les personnes handicapées.

Éviter les problèmes d'impression ou de mise en favoris.

Améliorer le référencement en évitant l'indexation de pages orphelines.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Utilisabilité

147. Il est possible de revenir à la page d'accueil depuis toutes les pages.

Objectif:

Permettre aux utilisateurs de revenir en page d'accueil en cas de désorientation.

Identifier le lien principal permettant d'accéder au site.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité

148. L'utilisateur est averti des ouvertures de nouvelles fenêtres.

Objectif:

Permettre à l'utilisateur d'anticiper le résultat de l'activation d'un lien.

Éviter aux utilisateurs d'aides techniques d'être désorientés par l'ouverture d'une nouvelle fenêtre qui n'est pas toujours perceptible et perturbe notamment l'utilisation de l'historique de navigation.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

149. La navigation sur le site ne provoque pas l'ouverture de fenêtres surgissantes (popups).

Objectif:

Permettre à l'utilisateur de naviguer sur le site sans avoir d'opération spécifique à effectuer pendant la navigation.

Éviter à des utilisateurs d'aides techniques d'être désorientés par l'ouverture d'une nouvelle fenêtre qui ne sera pas toujours aisément perceptible et qui perturbe notamment l'utilisation de l'historique de navigation ou qui masquera dans un lecteur d'écran la fenêtre principale.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Accessibilité
  • Utilisabilité
  • Label Opquast

150. Les mécanismes de fermeture de fenêtres sont visuellement rattachées à leur contenu.

Objectif:

Faciliter la navigation.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
Tag
  • Utilisabilité

151. Les mécanismes de fermetures de fenêtres sont immédiatement disponibles.

Objectif:

Limiter le temps d’apprentissage de l’interface.

Accélérer l’accès aux contenus.

Réduire le taux de rebond.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité

152. Les nouvelles fenêtres dimensionnées et les fenêtres modales sont dotées d'un bouton de fermeture explicite.

Objectif:

Donner aux utilisateurs des indications explicites pour fermer une fenêtre ou une boîte modale.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Intégration
Tag
  • Utilisabilité

153. Les mécanismes de fermetures de fenêtres sont affichés aux mêmes emplacements sur toutes les pages.

Objectif:

Limiter le temps d’apprentissage de l’interface.

Accélérer l’accès aux contenus.

Faciliter la navigation.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité

154. La consultation du site ne redimensionne pas la fenêtre du navigateur.

Objectif:

Laisser à l'utilisateur le contrôle de son navigateur et de son interface de consultation

Ne pas le désorienter ou le surprendre par un changement non anticipé de ceux-ci.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité

155. Le focus clavier n'est ni supprimé ni masqué.

Objectif:

Permettre la navigation au clavier ou via des périphériques d'entrées ou des dispositifs qui ne reposent pas sur la souris.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

156. Le site est intégralement utilisable au clavier.

Objectif:

Permettre la navigation au clavier pour les utilisateurs ayant une préférence pour cette pratique.

Permettre la consultation des contenus et l'utilisation des services indépendamment du périphérique d'entrée, afin de les rendre accessibles aux utilisateurs d'aides techniques (lecteurs d'écran par exemple) qui n'utilisent que le clavier ou un périphérique plus spécifique reposant sur les mêmes mécanismes que le clavier (bouton poussoir par exemple).

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Label Opquast

157. La navigation au clavier s'effectue dans un ordre prévisible.

Objectif:

De nombreux utilisateurs naviguent sans souris, avec les touches de leur clavier : facilitez-leur la vie.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

158. Le site ne comporte pas de liens internes vers des pages en construction.

Objectif:

Éviter des clics inutiles aux utilisateurs.

Limiter la consommation inutile de bande passante.

Proposer du contenu à valeur ajoutée.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Utilisabilité
  • SEO

159. Chaque page affiche une information permettant de connaître son emplacement dans l'arborescence du site.

Objectif:

Permettre à l'utilisateur de déterminer son emplacement dans le site.

Simplifier le passage des moteurs de recherche.

Faciliter la navigation dans l'arborescence des contenus.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité
  • Label Opquast

160. Le site propose un moteur de recherche interne.

Objectif:

Fournir aux utilisateurs une solution de navigation alternative et d'accès rapide aux contenus liés à des mots-clés retenus par ceux-ci.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Accessibilité
  • Écoconception
  • Label Opquast

161. La page des résultats de recherche indique le nombre de résultats, le nombre de pages de résultats, et le nombre de résultats par page.

Objectif:

Permettre aux utilisateurs d'avoir l'ensemble des informations essentielles relatives à la recherche qu'ils ont effectuée.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité

162. Chaque page de résultats de recherche peut être atteint via une adresse Web.

Objectif:

Permettre à l’utilisateur de partager ou de conserver dans ses signets un résultat de recherche.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Écoconception

163. Un plan du site est accessible depuis chaque page.

Objectif:

Fournir aux utilisateurs une solution en cas de désorientation, pour naviguer et se repérer dans le site, pour visualiser l'ensemble des contenus et la taille du site.

Inciter les responsables du contenu à représenter graphiquement et à rationaliser leur contenu.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Accessibilité
  • SEO
  • Label Opquast

164. Les blocs de navigation de même nature sont affichés aux mêmes emplacements sur toutes les pages.

Objectif:

Faciliter l'apprentissage de la navigation sur l'interface.

Faciliter le repérage de l'information.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Design
Tag
  • Accessibilité
  • Utilisabilité

165. Les icônes de navigation sont accompagnées d'une légende explicite.

Objectif:

Limiter le temps d'apprentissage de l'interface.

Faciliter la compréhension des icônes.

Limiter le risque d'erreurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Intégration
Tag
  • Utilisabilité

166. Les liens provoquant l'ouverture d'un logiciel externe ont un libellé explicite.

Objectif:

Éviter sur le poste client l'ouverture inopinée d'un autre logiciel que le navigateur Web.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité
  • Utilisabilité

167. Si le site n'est pas réservé à un public spécifique, l'accès aux contenus est immédiat.

Objectif:

Permettre aux utilisateurs de commencer immédiatement leur navigation sur la ressource qu'ils ont demandée.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité
  • SEO

168. Chaque page contient des liens d'accès rapide placés au début du code source.

Objectif:

Permettre aux utilisateurs qui consultent les pages de manière linéaire (mode vocal) ou semi-linéaire (écran de faible largeur) de ne pas avoir à défiler l'ensemble des éléments sur chaque page pour accéder aux contenus.

Fournir des raccourcis accélérant la navigation au clavier et évitant des actions au clavier répétées pour parcourir la page et atteindre la zone souhaitée.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Intégration
Tag
  • Accessibilité

169. Un lien de désinscription est présent dans chaque newsletter.

Objectif:

Permettre aux abonnés de ne plus recevoir une newsletter.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité
  • Newsletter

170. La désinscription depuis une newsletter ne demande pas de confirmation par courriel.

Objectif:

Ne pas imposer à l’utilisateur une étape qui n’est pas nécessaire dans ce contexte.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Écoconception
  • Newsletter

171. L'inscription aux newsletters est soumise à un processus de confirmation.

Objectif:

Éviter l'inscription à une newsletter par un tiers usurpant une identité.

Vérifier que l'adresse e-mail a été saisie sans erreur.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Newsletter

172. La désinscription aux newsletters est possible depuis le site.

Objectif:

Permettre à l'utilisateur de se désinscrire sans nécessairement passer par un mail.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Newsletter

173. La dernière newsletter envoyée est disponible en ligne.

Objectif:

Permettre aux utilisateurs de se faire une idée de la newsletter envoyée aux abonnés.

Permettre aux utilisateurs de consulter la newsletter en dehors des contraintes de l'email.

Accroître le référencement de vos contenus.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • Utilisabilité
  • Newsletter

174. Les archives de newsletters sont disponibles en ligne.

Objectif:

Faciliter la consultation des archives des newsletters.

Permettre aux utilisateurs de se faire une idée de la newsletter envoyée aux abonnés.

Favoriser le référencement de vos contenus.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
Tag
  • SEO
  • Newsletter

175. La fréquence d'envoi des newsletters est consultable avant l'abonnement.

Objectif:

Permettre aux utilisateurs de connaître avant leur inscription la fréquence à laquelle ils recevront la newsletter.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Rédaction
Tag
  • Utilisabilité
  • Newsletter

176. La charte graphique est cohérente sur l'ensemble du site.

Objectif:

Permettre une homogénéité et une continuité dans la visite et la navigation.

Permettre une identification permanente du service en ligne visité.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
Tag
  • Utilisabilité

177. La taille des polices destinées à l'affichage écran est exprimée en taille variable et non en taille fixe.

Objectif:

Permettre aux utilisateurs équipés de navigateurs qui ne gèrent pas l’agrandissement des polices en taille fixe d’agrandir les polices sans difficulté.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

178. Le site propose des styles dédiés à l'impression.

Objectif:

Permettre l'impression des contenus sous une forme appropriée au support.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Utilisabilité

179. Le contenu de chaque page est disponible à l'impression sans blocs de navigation.

Objectif:

Améliorer la lisibilité et la pertinence des contenus imprimés.

Rationnaliser l'espace utilisé par les contenus imprimés pour économiser du papier.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Utilisabilité
  • Écoconception

180. Une famille générique de police est indiquée comme dernier élément de substitution.

Objectif:

Permettre aux contenus de s'afficher correctement, même lorsque les polices prévues ne sont pas présentes sur le système de l'utilisateur.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Robustesse

181. Les contenus sont présentés avec un contraste suffisant par rapport à leur arrière-plan.

Objectif:

Permettre une bonne lisibilité des contenus.

Limiter la charge mentale lors de la consultation.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
Tag
  • Accessibilité
  • Label Opquast

182. Les mises en majuscules à des fins décoratives sont effectuées à l'aide des styles

Objectif:

Permettre un copier-coller des contenus indépendamment de la mise en forme entièrement en majuscules.

Faciliter l'adaptation de la mise en forme pour les utilisateurs ayant des difficultés de lecture des textes entièrement en majuscules.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Utilisabilité

183. Les styles ne justifient pas le texte.

Objectif:

Faciliter la lecture à l’écran, notamment pour les personnes dyslexiques.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
Tag
  • Accessibilité

184. Un contenu n'est pas désigné uniquement par sa forme ou par sa position à l'écran.

Objectif:

Permettre la compréhension de l'information sans l'accès au support visuel ou lorsque le rendu de celui-ci est altéré.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Accessibilité

185. L'identité des prestataires impliqués dans les transactions est précisée.

Objectif:

Fournir aux utilisateurs des informations sur les partenaires tiers impliqués dans la transaction.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Sécurité
  • E-commerce

186. La politique de confidentialité et de respect de la vie privée est accessible depuis toutes les pages.

Objectif:

Permettre aux utilisateurs de connaître les conditions de conservation de leurs données personnelles.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Sécurité

187. Le site propose une procédure de réinitialisation du mot de passe.

Objectif:

Permette à l'utilisateur d'accéder à son compte en cas de perte du mot de passe.

Simplifier la gestion des comptes utilisateurs.

Renforcer la sécurité en évitant le stockage de mots de passe non cryptés afin de pouvoir les communiquer de nouveau à l'utilisateur.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité
  • E-commerce
  • Label Opquast

188. Les mots de passe peuvent être choisis ou changés par l'utilisateur.

Objectif:

Permettre aux utilisateurs de choisir un mot de passe personnalisé.

Éviter aux utilisateurs de rechercher leur mot de passe à chaque connexion.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Sécurité
  • Label Opquast

189. Les mots de passe choisis par l'utilisateur admettent les caractères imprimables de la table ASCII.

Objectif:

Favoriser un niveau élevé de sécurité des mots de passe.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

190. Un dispositif sensibilise l'utilisateur sur le degré de sécurisation du mot de passe qu'il choisit

Objectif:

Informer les utilisateurs sur le niveau de sécurité du mot de passe choisi et donc sur les risques de détournement.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

191. Les certificats de sécurité sont signés et en cours de validité.

Objectif:

Permettre aux utilisateurs de connaître la validité du certificat et contribuer à la sécurisation de la transaction.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité
  • Label Opquast

192. Les données sensibles ne sont pas transmises en clair dans les url.

Objectif:

Éviter que des données sensibles ne soient publiques et stockées en clair aux différentes étapes de l'accès à la page (FAI, proxy, serveur Web, historique du navigateur, services tiers…).

Permettre à l'utilisateur de saisir des données sensibles en sachant qu'elles seront protégées et confidentielles.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

193. Les échanges de données sensibles sont sécurisés et signalés comme tels.

Objectif:

Conforter la confiance de l'utilisateur.

Permettre à l'utilisateur de saisir des données sensibles en sachant qu'elles seront protégées.

Minimiser les risques d'utilisation frauduleuse des données des utilisateurs.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité
  • Confiance
  • Label Opquast

194. Les en-têtes envoyés par le serveur désactivent la détection automatique du type MIME de chaque ressource.

Objectif:

Réduire les risques de téléchargement d’un contenu dangereux dissimulé.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

195. Le serveur indique le type MIME de chaque ressource.

Objectif:

Réduire les risques de téléchargement d’un contenu dangereux dissimulé.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

196. Les informations sur la sécurité des transactions sont indiquées.

Objectif:

Contribuer à l'information des utilisateurs sur la sécurisation des échanges de données sensibles.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Sécurité
  • E-commerce
  • Label Opquast

197. L'objectif des cookies et les limitations inhérentes à leur refus sont expliqués.

Objectif:

Informer l'utilisateur sur les cookies.

Expliquer leur rôle et leur utilité.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • Sécurité
  • E-commerce
  • Label Opquast

198. La procédure d'accès et de rectification des données personnelles est décrite.

Objectif:

Informer l'utilisateur sur l'utilisation de ses données personnelles.

Conforter la confiance dans le site ou le service.

Faciliter la gestion des demandes liées aux données personnelles.

Checklist
  • Bonnes pratiques
Phase projet
  • Rédaction
Tag
  • E-commerce
  • Confiance

199. La création d'un compte est soumise à un processus de confirmation.

Objectif:

Réduire les risques d’inscription de l’utilisateur à son insu.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

200. La création de compte est possible sans recours à un système d'identification tiers.

Objectif:

Laisser l’utilisateur libre de son choix d’utiliser ou non un service tiers.

Fournir un moyen alternatif d’accès au service.

Fournir un moyen d’accès maîtrisé par les administrateurs du service.

Limiter la dépendance à un acteur tiers dont la politique et la stratégie commerciale ou technique ne manquera pas d’évoluer dans le temps.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Sécurité

201. Les comptes ou abonnements ouverts en ligne peuvent être fermés par le même moyen.

Objectif:

Faciliter la gestion des comptes utilisateurs.

Éviter à l'utilisateur une recherche de contact.

Conforter la confiance dans le site ou le service.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • E-commerce
  • Confiance

202. Le serveur n'envoie pas la liste des fichiers des répertoires n'ayant pas de page d'index.

Objectif:

Éviter l'affichage de listes de fichiers contenus dans un répertoire.

Améliorer la sécurité du serveur.

Limiter les risques d'intrusion.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

203. Le serveur envoie les informations d'activation de protection cross site scripting.

Objectif:

Réduire les risques de téléchargement d’un contenu dangereux dissimulé.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

204. Le serveur envoie les informations indiquant les domaines autorisés à intégrer ses pages dans des cadres.

Objectif:

Réduire les risques d’utilisation trompeuse du contenu.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Sécurité

205. Le site propose un mécanisme de sécurité permettant de restreindre l'origine des contenus.

Objectif:

Réduire les risques d’exécution ou d’affichage d’un contenu non désirable ou d’une source non autorisée.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Développement
Tag
  • Sécurité

206. Le serveur envoie les informations permettant la mise en cache des contenus.

Objectif:

Accélérer l'affichage des contenus et permettre une navigation plus fluide.

Réduire les coûts de bande passante.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Performance
  • Label Opquast

207. Le serveur envoie un code http 404 pour les ressources non trouvées.

Objectif:

Permettre la détection automatisée des URL erronées.

Transmettre au navigateur une information sûre.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • SEO
  • Écoconception

208. Le serveur envoie une page d'erreur 404 personnalisée.

Objectif:

Informer l'utilisateur sur l'erreur rencontrée, sur la continuité de fonctionnement du serveur et lever le doute sur un éventuel problème lié à sa connexion.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Développement
Tag
  • Utilisabilité
  • Label Opquast

209. Le serveur envoie une page d'interdiction 403 personnalisée.

Objectif:

Rassurer l'internaute sur le fait qu'il est toujours dans le même site.

Permettre à l'administrateur du site de mettre des éléments de guidage pour l'utilisateur.

Informer l'utilisateur sur l'erreur rencontrée, sur la continuité de fonctionnement du serveur et mettre hors de cause sa connexion.

Checklist
  • Bonnes pratiques
Phase projet
  • Design
  • Développement
Tag
  • Utilisabilité

210. Le menu principal de navigation figure sur les pages d'erreur personnalisées.

Objectif:

Éviter aux utilisateurs les ruptures de navigation, l'arrivée sur des pages cul-de-sac ou l'obligation d'utiliser le bouton Précédent du navigateur.

Checklist
  • Bonnes pratiques
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité
  • Label Opquast

211. Le serveur transmet des contenus compressés aux clients qui les acceptent.

Objectif:

Améliorer la vitesse de rendu de la page.

Diminuer les coûts de bande passante.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Performance
  • Écoconception
  • Label Opquast

212. Les en-têtes envoyés par le serveur contiennent les informations relatives au jeu de caractères employé.

Objectif:

Permettre au navigateur de choisir le bon encodage des caractères pour afficher la page.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Développement
Tag
  • SEO

213. Le serveur respecte l'ordre préférentiel de langues des outils de consultation.

Objectif:

Servir les pages dans la langue souhaitée.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Internationalisation

214. Les feuilles de style du site sont minifiées.

Objectif:

Minimiser la quantité de données à télécharger par l'utilisateur.

Améliorer les performances.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Performance
  • Écoconception

215. Les scripts du site sont minifiés.

Objectif:

Accélérer la vitesse d'affichage des pages.

Améliorer les performances.

Diminuer la quantité de données à télécharger.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Performance
  • Écoconception

216. Les fonctions de scripts internes au site sont placées dans des fichiers externes.

Objectif:

Minimiser la quantité de données à télécharger par l'utilisateur.

Améliorer les performances.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Performance
  • Écoconception
  • Label Opquast

217. L'adresse du site et de ses sous-domaines fonctionnent avec ou sans préfixe www.

Objectif:

Permettre aux utilisateurs de rejoindre la page d'accueil du site même lorsqu'ils oublient de taper le préfixe www.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • Écoconception

218. Le code source des fils de syndication indique leur fréquence de mise à jour.

Objectif:

Permettre aux utilisateurs de configurer la fréquence à laquelle leurs outils consultent le fil de syndication.

Réduire la charge du serveur.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Performance
  • SEO
  • Écoconception
  • Syndication

219. Les fils de syndication sont détectables par les agents utilisateurs.

Objectif:

Permettre au navigateur d'indiquer dans son interface la présence d'un fil de syndication associé à la page en cours de consultation.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Utilisabilité
  • Syndication

220. Les hyperliens contenus dans les fils de syndication sont absolus.

Objectif:

Assurer la fiabilité des liens lorsque le contenu est réutilisé.

Checklist
  • Bonnes pratiques
Phase projet
  • Développement
Tag
  • Utilisabilité
  • SEO
  • Syndication

221. Le site propose au moins un lien vers chaque fil de syndication.

Objectif:

Permettre aux utilisateurs de s'abonner facilement aux fils de syndication.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Syndication
Tag
  • Utilisabilité
  • Syndication

222. Les cellules des tableaux de données sont reliées à leurs en-têtes.

Objectif:

Permettre aux aides techniques de restituer l'information contenue dans les tableaux de données de manière compréhensible, en indiquant à l'utilisateur les relations logiques entre contenu et en-têtes du tableau.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité
  • Label Opquast

223. Les titres des tableaux de données sont renseignés.

Objectif:

Permettre aux utilisateurs d'aides techniques (lecteurs d'écran) d'identifier aisément la nature des informations fournies par un tableau.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité

224. La linéarisation des tableaux utilisés pour la mise en page ne nuit pas à la compréhension des contenus.

Objectif:

Fournir un contenu compréhensible aux utilisateurs dont l'agent utilisateur ou l'aide technique (lecteur d'écran) ne permet pas de restituer la mise en forme initialement prévue à l'aide d'un tableau.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
Tag
  • Accessibilité

225. Les tableaux de données ne sont pas remplacés par des images.

Objectif:

Permettre aux utilisateurs d’accéder à des tableaux exploitables par leur agent utilisateur et restitués de manière compréhensible dans tous les cas.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité
  • Utilisabilité
  • SEO

226. Les tableaux de données ne sont pas simulés à l'aide de texte mis en forme.

Objectif:

Permettre aux utilisateurs d'accéder à des tableaux exploitables par leur agent utilisateur et restitués de manière compréhensible dans tous les cas.

Checklist
  • Bonnes pratiques
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité
  • SEO

R1 . Si un contenu est proposé sous une forme inaccessible, une version alternative accessible est mise à disposition.

Objectif:

Il arrive qu’il soit impossible de rendre accessible un contenu. Si vous en avez la possibilité, proposez une version alternative. Attention, ne proposez pas une version spécifique accessible de votre site, faites plutôt en sorte de rendre la version principale accessible.

Checklist
  • Recommandations
Phase projet
  • Prototype
  • Intégration
  • Développement
  • Rédaction
Tag
  • Accessibilité

R2 . Une description étendue correctement associée complète l’alternative textuelle des images complexes.

Objectif:

La description étendue donne l’intégralité de l’information et complète l’alternative textuelle plus synthétique. Pour un graphique, par exemple (courbe, diagramme, etc.), elle donnera l’ensemble des données, généralement sous forme d’un tableau. Elle profitera ainsi à l’accessibilité, au référencement et plus largement à l’accès aisé au détail de l’information.

Checklist
  • Recommandations
Phase projet
  • Prototype
  • Rédaction
  • Intégration
Tag
  • Accessibilité

R3 . Les captchas audio peuvent être mis en pause.

Objectif:

Pouvoir réécouter un captcha audio est déjà une aide appréciable lorsqu’il s’avère difficile à déchiffrer. Pouvoir l’écouter pas à pas, grâce à un bouton play/pause, sera encore plus appréciable.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Utilisabilité

R4 . Le code source de chaque page ne comporte pas d’erreur portant sur l’arbre du document ou la syntaxe des balises et attributs.

Objectif:

Les erreurs de validité HTML sont parfois difficilement évitables, dans la pratique. Mais toutes n’ont pas le même impact et n’exposent pas aux mêmes risques, en particulier en matière d’accessibilité de la page. Les erreurs visées ici sont celles jugées dangereuses pour l’accessibilité.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Accessibilité
  • Robustesse

R5 . Le code source des pages est valide au regard de la grammaire choisie.

Objectif:

La validité complète du code HTML est évidemment, quand elle est possible, la solution radicale face aux risques de rendus ou de comportements imprévus.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Robustesse

R6 . Les éléments avec une sémantique native sont préférés.

Objectif:

Il est certes possible de reconstruire des éléments sémantiques (liens, boutons, titres de section, etc.) à partir d’éléments génériques (div, span), notamment via ARIA. Mais mieux vaut privilégier autant que possible les éléments sémantiques natifs, dont le support est bien plus assuré.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Robustesse

R7 . Les zones principales de la page sont identifiées dans le code source.

Objectif:

Les « landmarks » HTML5 et les rôles ARIA équivalents peuvent être d’une aide considérable pour l’accessibilité. N’hésitez pas à baliser explicitement au moins votre header, vos menus, votre footer, votre contenu principal et votre formulaire de recherche.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Accessibilité

R8 . Les citations sont balisées de façon appropriée.

Objectif:

Le balisage des citations avec les éléments HTML appropriés (q, blockquote) améliore leur accessibilité en permettant aux aides techniques de les distinguer à coup sûr du reste du contenu. C’est également un atout pour le référencement.

Checklist
  • Recommandations
Phase projet
  • Intégration
Tag
  • Accessibilité

R9 . Les dimensions réelles des images sont indiquées dans le code source.

Objectif:

Indiquer les dimensions réelles des images dans le code source accélère le rendu. En cas de nécessité, ces informations peuvent être surchargées par les styles.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Performance

R10 . L’accès aux contenus et services est possible sans le support des scripts.

Objectif:

Même si la présence d’une alternative à JavaScript n’est plus aujourd’hui une exigence d’accessibilité (dans la mesure où il s’agit de scripts en eux-mêmes conformes aux recommandations d’accessibilité), il peut rester prudent de permettre un accès aussi complet que possible aux contenus indépendamment du support, de l’activation ou du bon déroulement des scripts. Ne serait-ce, par exemple, qu’en cas de dysfonctionnement.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Robustesse

R11 . Le site n’emploie aucune technique destinée à bloquer ou gêner l’affichage et/ou la lecture du code source.

Objectif:

Le Web a été pensé de façon à ce que chacun puisse publier librement et se servir des contenus publiés et pour que les techniques utilisées par les autres puissent être partagées. Certains sites tentent d’empêcher d’accéder à leur code source, c’est très facilement contournable et absolument pas dans l’esprit.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Confiance

R12 . Le site n’emploie aucune technique destinée à empêcher l’utilisation de fonctions natives des agents utilisateurs (clic droit, sélection de texte, impression…).

Objectif:

Bloquer certaines fonctionnalités ou possibilités des navigateurs ou équipements des utilisateurs est une très mauvaise idée. C’est non seulement gênant mais également assez facilement contournable. Inutile et contre

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Utilisabilité

R13 . L’auteur de chaque article est identifiable.

Objectif:

La présence de l’identité de l’auteur sur un article est de nature à renforcer la confiance que l’on peut porter à son contenu. Par rebond, cela facilite la réutilisation, et cela incite au partage de l’article.

Checklist
  • Recommandations
Phase projet
  • Prototype
  • Intégration
Tag
  • Confiance

R14 . Des sources (citations, lien vers une référence, etc.) légitiment les informations présentées et/ou leurs auteurs.

Objectif:

Comme le disait Victor Hugo, il est difficile d’établir la véracité et la solidité d’une information sur Internet. La présence des sources est de nature à renforcer la confiance des lecteurs.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Confiance

R15 . L’identité du ou des traducteurs est indiquée.

Objectif:

Les traducteurs ont un rôle important dans la qualité finale des contenus. La mention de leur identité les crédite, permet de les identifier en cas de question sur une traduction et renforce la confiance que l’utilisateur peut accorder à l’information.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Internationalisation

R16 . Les contenus éditoriaux qui le nécessitent sont associés à une date ou une période de publication.

Objectif:

Certains contenus sont de nature à périmer rapidement, certains nécessitent également d’être datés pour être compris dans leur contexte et réutilisables. La mention des dates aide à la compréhension et à la réutilisabilité.

Checklist
  • Recommandations
Phase projet
  • Prototype
  • Intégration
Tag
  • Utilisabilité
  • Confiance

R17 . La date de mise à jour des contenus contractuels est indiquée.

Objectif:

Les contenus contractuels sont opposables à des entités judiciaires ou administratives. Il est donc fortement recommandé de les versionner et d’afficher les numéros de version

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Confiance

R18 . Les systèmes de votes, notes et sondages précisent le nombre de votants, la période et le mode de mesure.

Objectif:

En l’absence du nombre de votants, de la période et du mode de mesure, les votes, notes et sondages sont sujets à caution.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Confiance

R19 . Le site respecte les règles ortho-typographiques de la langue du texte.

Objectif:

La présence de fautes d’orthographe est l’un des éléments qui entâchent fortement la perception de la qualité d’un site. Pour les utilisateurs, cela donne une mauvaise image, et certaines études montrent que la présence de fautes d’orthographe a des effets négatifs sur les taux de conversion.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Confiance

R20 . Le contenu des pages ne contient pas de mots-clés dissimulés.

Objectif:

Pour améliorer le référencement de termes ou d’expressions, certains sites ont introduit des contenus dans les pages, et étant donnée leur faible utilité pour les usagers, ils prenaient soin de les afficher de la même couleur que le fond. Cette pratique a été sanctionnée par Google et a heureusement pratiquement disparu.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • SEO

R21 . L’affichage de contenus publicitaires ou sponsorisés ne vient pas automatiquement modifier la mise en page.

Objectif:

Différentes techniques d’insertion de contenus publicitaires peuvent faire apparaître ceux-ci au cours de la consultation de la page, par exemple en les intercalant entre deux blocs de contenu rendus visibles par le scroll. Il est alors extrêment désagréable de voir le texte qu’on est en train de lire se déplacer inopinément.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Utilisabilité

R22 . Une métadonnée indique l’URL de référence des contenus proposés sous plusieurs formes.

Objectif:

L’indication d’une URL canonique (rel canonical) vous bénéficiera en cas de contenus dupliqués.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • SEO

R23 . Les tableaux de données des documents PDF internes sont structurés.

Objectif:

Comme les pages HTML, les PDF peuvent être vocalisés, les tableaux de données sont très fréquents dans ce type de documents et le fait de les baliser correctement peut rendre ces contenus plus accessibles.

Checklist
  • Recommandations
Phase projet
  • Rédaction
  • Développement
Tag
  • Accessibilité

R24 . Les listes ordonnées et non ordonnées des documents PDF internes sont structurées.

Objectif:

Le balisage des listes ordonnées et non ordonnées facilite la vocalisation de leur contenu.

Checklist
  • Recommandations
Phase projet
  • Rédaction
  • Développement
Tag
  • Accessibilité

R25 . Les images des documents PDF internes sont dotées d’alternatives textuelles.

Objectif:

Tout comme une image incluse dans une page HTML, une image porteuse d’information ou une image-lien dans un document PDF ont besoin d’une alternative, pour leur accessibilité et pour le référencement.

Checklist
  • Recommandations
Phase projet
  • Rédaction
  • Développement
Tag
  • Accessibilité

R26 . Les documents PDF sont linéarisables.

Objectif:

S’assurer que le contenu d’un PDF est linéarisable permet à un lecteur d’écran de le restituer dans un ordre cohérent et compréhensible. Ceci est particulièrement important dans le cas de mises en page complexes.

Checklist
  • Recommandations
Phase projet
  • Rédaction
  • Développement
Tag
  • Accessibilité

R27 . Les pages proposent un accès à une information synthétique pour les contenus sonores, visuels, animés et médias synchronisés.

Objectif:

Que vous puissiez ou non satisfaire à la bonne pratique qui vous invite à fournir une transcription textuelle de ces contenus, il est toujours bénéfique de donner par ailleurs une indication concise résumant l’essentiel de l’information : cela sera utile en termes d’accessibilité autant que de référencement.

Checklist
  • Recommandations
Phase projet
  • Rédaction
  • Intégration
Tag
  • Accessibilité

R28 . Les contenus multimédias sont sous-titrés.

Objectif:

Les sous-titres sont utiles pour les sourds et malentendants, mais pas seulement, puisqu’en l’absence de transcription, ils peuvent aussi devenir le seul moyen d’accès aux éléments textuels d’un contenu multimédia. Ils peuvent apporter une valeur ajoutée importante pour de nombreux utilisateurs (apprentissage des langues, consultation des contenus sans son, facilitation de la compréhension).

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Accessibilité

R29 . Chaque contenu vidéo est doté d’une audio-description.

Objectif:

L’audio-description bénéficie à un public non-voyant ou malvoyant, pour qui elle va donner accès, dans les blancs de la piste sonore par défaut, à l’information visuelle contenue dans la vidéo.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Accessibilité

R30 . L’utilisateur est averti du verrouillage majuscule de son clavier lors de la saisie d’un champ sensible à la casse.

Objectif:

L’activation du verrouillage majuscule est une raison fréquente d’échec lors de la saisie d’un mot de passe. Il peut être intéressant d’avertir l’utilisateur lorsqu’il est activé.

Checklist
  • Recommandations
Phase projet
  • Prototype
  • Intégration
Tag
  • Utilisabilité

R31 . La position des libellés et des champs est uniforme dans chaque formulaire.

Objectif:

La saisie d’un formulaire est une opération essentielle sur le Web, et il est très important de diminuer au maximum la charge mentale imposée aux usagers. Pour ceci, les champs et étiquettes doivent être alignés. L’alignement à droite des étiquettes et à gauche des champs est une solution souvent efficace.

Checklist
  • Recommandations
Phase projet
  • Design
Tag
  • Accessibilité

R32 . Les validations de formulaires côté client ont une alternative côté serveur.

Objectif:

Lorsque des contenus sont présentés sous forme de multiples blocs successifs à « ouvrir », cela facilite certes la vue d’ensemble sur ceux-ci. Mais la recherche d’une information spécifique à travers ces blocs peut aussi s’avérer fastidieuse s’il faut les ouvrir un à un

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Robustesse

R33 . La possibilité d’envoyer un formulaire à l’aide de la touche Entrée du clavier n’est pas altérée.

Objectif:

Naviguer au clavier, c’est aussi très souvent se servir de la touche Entrée pour valider l’envoi d’un formulaire.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Accessibilité

R34 . Le lien d’activation de l’aide contextuelle à un champ de formulaire est visuellement rattaché à l’étiquette de ce champ.

Objectif:

Cette recommandation étend la bonne pratique invitant à afficher un champ et son étiquette de manière à ce que leur association soit immédiatement visible. Ici, on rapprochera par exemple l’icône donnant accès à une aide à la saisie du champ, selon le même principe de proximité visuelle immédiate.

Checklist
  • Recommandations
Phase projet
  • Design
Tag
  • Utilisabilité

R35 . Les informations relatives à l’audience et à la fréquentation du site sont accompagnées de la période couverte et du mode de mesure.

Objectif:

Une donnée statistique ne peut être utilisable ou compréhensible qu’en présence des conditions dans lesquelles elle a été obtenue. En l’absence de ces conditions, les chiffres sont sujets à caution.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Confiance

R36 . La syntaxe des URL est homogène sur l’ensemble du site.

Objectif:

Les URL ne sont certes pas obligatoirement faites pour être mémorisées par les utilisateurs. Mais une syntaxe d’URL cohérente à travers tout le site facilitera souvent les choses.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Utilisabilité

R37 . Un seul jeu d’identifiants est nécessaire pour accéder à l’ensemble des services proposés.

Objectif:

Certains sites ou groupes de sites (comme Opquast, par exemple) proposent plusieurs services qui nécessitent de s’identifier.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Utilisabilité

R38 . Les titres, libellés et contenus alternatifs sont traduits dans la langue de la page.

Objectif:

Une page doit si possible être intégralement traduite, y compris les meta données et les contenus alternatifs, éléments qui ne font pas directement partie des contenus traduits.

Checklist
  • Recommandations
Phase projet
  • Rédaction
  • Développement
Tag
  • Internationalisation

R39 . Les formulaires et les messages associés sont rédigés dans une langue unique.

Objectif:

Cette recommandation vise notamment les messages d’erreurs, qui sont souvent oubliés lors des phases de traduction. Lors de l’internationalisation d’un formulaire, il faut penser à tout.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Internationalisation

R40 . La version originale des contenus traduits est indiquée.

Objectif:

Les versions originales non traduites d’un contenu peuvent servir de référence pour les utilisateurs, notamment parce que des erreurs d’interprétation ou de traduction sont toujours possibles.

Checklist
  • Recommandations
Phase projet
  • Rédaction
  • Développement
Tag
  • Internationalisation

R41 . Les pages dont le contenu est issu d’une traduction automatique sont signalées comme telles.

Objectif:

Faire traduire ses pages par un outil automatique n’est pas idéal, mais dans certains cas, c’est mieux que rien. Dans ce cas, il faut simplement le préciser.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Internationalisation

R42 . Le sens de lecture du contenu est indiqué lorsqu’il diffère de celui par défaut.

Objectif:

Les navigateurs savent exploiter un mécanisme permettant de déterminer le sens de l’écriture à partir de son contenu (algorithme bidirectionnel). Mais ce mécanisme a quelques limites susceptibles de provoquer des rendus indésirables, notamment quand interviennent des signes dont la direction est neutre (chiffres, ponctuations).

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Rédaction
Tag
  • Accessibilité

R43 . Les pages contiennent des liens transversaux (alternatives à la navigation par les menus).

Objectif:

La navigation peut être accélérée grâce à des liens qui permettent de circuler entre les pages sans avoir à passer par l’accueil ou par les menus.

Checklist
  • Recommandations
Phase projet
  • Prototype
Tag
  • Utilisabilité

R44 . Le code source des pages contient des liens relatifs vers l’auteur, les droits de reproduction, l’accueil et le plan du site.

Objectif:

Le HTML permet de fournir des données directement dans le code source, ce qui rend ces informations utilisables par les machines.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • SEO

R45 . Les blocs de contenu affichés individuellement à la demande de l’utilisateur peuvent être ouverts en une seule fois.

Objectif:

Lorsque des contenus sont présentés sous forme de multiples blocs successifs à « ouvrir », cela facilite certes la vue d’ensemble sur ceux-ci. Mais la recherche d’une information spécifique à travers ces blocs peut aussi s’avérer fastidieuse s’il faut les ouvrir un à un

Checklist
  • Recommandations
Phase projet
  • Intégration
Tag
  • Utilisabilité

R46 . Le défilement du contenu ne provoque pas l’affichage automatique de contenu interstitiel.

Objectif:

La navigation sur un site déclenche de plus en plus fréquemment l’ouverture automatique de contenus. Cette mauvaise pratique provoque des déplacements de contenus et gêne considérablement les utilisateurs.

Checklist
  • Recommandations
Phase projet
  • Prototype
Tag
  • Utilisabilité

R47 . Chaque résultat de recherche est accompagné d’un extrait du contenu.

Objectif:

À l’instar des grands moteurs de recherche, les extraits de contenus ont une valeur ajoutée importante pour les utilisateurs. Le titre n’est pas toujours suffisant pour se faire une idée du contenu des résultats. L’extrait de contenu peut servir à supprimer des ambiguïtés.

Checklist
  • Recommandations
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité

R48 . L’utilisateur peut choisir le nombre de résultats de recherche affichés par page.

Objectif:

Afficher des résultats de recherche par tranche de 20, par exemple, peut sembler approprié pour tous les contextes utilisateurs : ni trop à la fois, ni trop peu. Mais pourquoi ne pas éviter de gêner des utilisateurs ayant par exemple besoin de parcourir plus rapidement un grand nombre de résultats ? Permettez-leur d’afficher, au choix, par exemple 20, 50 ou 100 résultats par page.

Checklist
  • Recommandations
Phase projet
  • Prototype
  • Développement
Tag
  • Utilisabilité

R49 . Les alternatives textuelles, étiquettes et libellés de liens ayant des fonctions identiques sont cohérentes à travers le site.

Objectif:

Il est essentiel pour l’expérience utilisateur que l’interface soit aussi prévisible que possible, lorsque c’est pertinent. Il s’agit ici simplement de donner un même libellé aux liens, boutons et champs de formulaire ayant le même rôle ou la même cible à travers différentes pages du site.

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Accessibilité

R50 . L’accès à chaque contenu temporisé peut être mis en pause ou prolongé.

Objectif:

Chaque limite de temps imposée à l’utilisateur lors de l’accès au contenu peut être extrêmement pénalisante pour des personnes ayant, pour une raison technique ou liée à un handicap, besoin de plus de temps que vous ne l’aviez prévu. Il est donc important, lorsque c’est possible, de permettre à l’utilisateur de prolonger le temps qui lui a été imparti.

Checklist
  • Recommandations
Phase projet
  • Intégration
Tag
  • Accessibilité

R51 . Le champ destinataire de la newsletter ne comprend que l’e-mail du destinataire (ou à défaut un e-mail générique créé par l’expéditeur).

Objectif:

L’inscription aux newsletters doit généralement – et c’est ce que demandent de nombreuses législations – faire l’objet d’un opt-in (l’utilisateur manifeste sa volonté d’être abonné en cochant une case) plutôt que d’un opt-out (décochage d’une case pour manifester la volonté de ne pas être abonné). Certains sites ne s’embarrassent même pas de la présence d’une case à cocher et abonnent directement les utilisateurs lors d’une création de compte ou d’une commande en ligne. C’est évidemment à évite

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Newsletter

R52 . L’interlettrage n’est réalisé que dans les styles CSS.

Objectif:

Pour obtenir un effet de mise en forme, on peut écrire par exemple « H E L L O ». Ce texte sera interprété par des aides techniques ou par des robots d’indexation ou de traduction comme une suite de lettres sans signification. Mieux vaut, donc, écrire « HELLO » et recourir à la propriété CSS letter

Checklist
  • Recommandations
Phase projet
  • Intégration
Tag
  • Utilisabilité

R53 . Les dispositifs de changement de taille de caractères proposés par le site agissent sur la totalité de la page.

Objectif:

Offrir un mécanisme d’agrandissement des caractères inclus dans la page (les classiques icônes A+) peut être ergonomiquement appréciable. Il ne faut cependant pas croire que seul le contenu principal de la page suffit à être visé : l’utilisateur peut tout aussi bien avoir besoin d’agrandir les menus ou les contenus annexes.

Checklist
  • Recommandations
Phase projet
  • Intégration
Tag
  • Utilisabilité

R54 . Les styles en ligne ne sont utilisés que s’ils ne peuvent pas être externalisés.

Objectif:

Pourquoi surcharger le code HTML d’attributs de styles répétés lorsqu’il s’agit de mises en forme qui pourraient être gérées plus économiquement dans une feuille de styles, à l’aide de classes et d’identifiants ? Allégez vote code autant que possible !

Checklist
  • Recommandations
Phase projet
  • Intégration
  • Développement
Tag
  • Performance

R55 . Le contenu textuel reste lisible avec une taille de caractères augmentée d’un facteur deux dans le navigateur.

Objectif:

Même si l’usage du zoom graphique s’est largement répandu aujourd’hui, il reste important, pour l’accessibilité notamment, de permettre à l’utilisateur d’agrandir uniquement la taille du texte et non les éléments graphiques, par le paramétrage de son navigateur ou le racourci clavier Ctrl++.

Checklist
  • Recommandations
Phase projet
  • Intégration
Tag
  • Accessibilité

R56 . Les vignettes ne sont pas des images de taille supérieure redimensionnées côté client.

Objectif:

Pour afficher une vignette de petite taille, il suffit de prendre une image de grande taille et de lui donner une petite taille en HTML. Dans ce cas, l’image s’affiche en petit mais c’est bien la grande image qui est téléchargée. Cela ralentit le temps d’affichage et augmente la quantité de données à télécharger.

Checklist
  • Recommandations
Phase projet
  • Intégration
Tag
  • Performance

R57 . Le site n’impose pas d’effets de flash.

Objectif:

Même si ce type de contenu est extrêmement rare, il est préférable d’éviter systématiquement les effets de flash, c’est à dire les clignotements à plus de 3 flashs par seconde, susceptibles de provoquer au minimum une gêne considérable à l’utilisateur.

Checklist
  • Recommandations
Phase projet
  • Design
Tag
  • Accessibilité

R58 . La commande ou la création de compte ne provoque pas d’inscription automatique à une newsletter.

Objectif:

L’inscription aux newsletters doit généralement – et c’est ce que demandent de nombreuses législations – faire l’objet d’un opt-in (l’utilisateur manifeste sa volonté d’être abonné en cochant une case) plutôt que d’un opt-out (décochage d’une case pour manifester la volonté de ne pas être abonné). Certains sites ne s’embarassent même pas de la présence d’une case à cocher et abonnent directement les utilisateurs lors d’une création de compte ou d’une commande en ligne. C’est évidemment à éviter.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Confiance
  • E-Commerce
  • Newsletter

R59 . Les contenus postés dans des formulaires sont filtrés pour éviter les injections.

Objectif:

En injectant certaines commandes de bases de données dans de simples formulaires, certains utilisateurs arrivent à prendre la main sur le serveur. Il est donc intéressant de vérifier que cette injection est impossible.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Sécurité

R60 . L’utilisateur peut modifier à tout moment ses choix en matière de cookies.

Objectif:

Malgré l’acceptation quasi systématique par les utilisateurs européens de l’activation de cookies, chaque utilisateur doit pouvoir conserver le choix de refuser ceux de certains sites. Pour cela, les administrateurs de sites peuvent proposer aux utilisateurs de refuser les cookies.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Confiance

R61 . Toute collecte d’information personnelle fait l’objet d’une explication ou d’une justification.

Objectif:

Chaque demande d’information personnelle d’un utilisateur doit pouvoir se justifier. En l’absence d’explication ou de justification, l’utilisateur peut imaginer toutes sortes d’utilisations pas forcément utiles de ses données.

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Confiance

R62 . Le serveur est configuré pour ne pas renvoyer d’informations sur les versions des logiciels et langages utilisés.

Objectif:

Il est inutile d’exposer publiquement des détails, même apparemment inoffensifs, à propos de votre serveur et de sa configuration : c’est toujours un risque côté sécurité, aussi minime soit-il.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Sécurité

R63 . Le serveur envoie un code 301 pour le contenu ayant changé d’adresse de façon permanente.

Objectif:

Améliorez votre référencement et allégez votre charge serveur : ne déménagez pas sans signaler explicitement votre changement d’adresse.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • SEO

R64 . Le site ne pratique pas de détection du user-agent.

Objectif:

Différentes techniques d’insertion de contenus publicitaires peuvent faire apparaître ceux-ci au cours de la consultation de la page, par exemple en les intercalant entre deux blocs de contenu rendus visibles par le scroll. Il est alors extrêment désagréable de voir le texte qu’on est en train de lire se déplacer inopinément.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Robustesse

R65 . Les appels de scripts ne sont pas dupliqués.

Objectif:

L’affichage d’une page web peut déclencher des appels multiples au même script. L’effet peut être au mieux une perte de performance, au pire une perte de fonctionnalité.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Performance

R66 . La date et l’heure du serveur sont correctes.

Objectif:

La date et l’heure du serveur ne sont pas toujours des données essentielles pour les humains, mais elles sont au minimum essentielles pour les machines et logiciels qui accédent aux contenus. Les conséquences d’un mauvais réglage ou d’un oubli de passage à l’heure d’été ou d’hiver peuvent être imprévisibles.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Robustesse

R67 . Les appels aux scripts sont placés après le contenu.

Objectif:

Cette règle consistant à charger prioritairement permet souvent, mais pas toujours, d’afficher les contenus plus rapidement, et de donner l’impression d’un chargement plus rapide de la page.

Checklist
  • Recommandations
Phase projet
  • Intégration
Tag
  • Performance

R68 . Le serveur envoie des pages d’erreurs personnalisées.

Objectif:

Un serveur renvoie des codes d’erreurs qui dépendent de la requête. Le plus fréquent est 200, qui dit que la ressources existe, mais il existe aussi les codes d’erreurs 404, 403 et 500. Dans tous les cas, ces erreurs gagnent à être aux couleurs du site.

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Utilisabilité

R69 . Le nombre de requêtes http est optimisé.

Objectif:

Cette recommandation est de nature à augmenter les performances et la vitesse d’affichage de vos pages. Les valeurs optimales sont complexes à trouver et dépendent beaucoup des contenus, mais une phase d’optimisation de ce paramètre peut jouer un rôle favora

Checklist
  • Recommandations
Phase projet
  • Développement
Tag
  • Performance

R70 . Le site ne comporte pas de tableaux de données complexes.

Objectif:

Il est possible de baliser de manière accessible un tableau de données comportant de multiples en-têtes, des lignes d’en-têtes intermédiaires et des sections complexes. Certes, mais plutôt qu’un tableau théoriquement accessible mais compliqué pour tous, ne vaut-il pas mieux, autant que possible, scinder tout cela par exemple en plusieurs tableaux plus simples ?

Checklist
  • Recommandations
Phase projet
  • Rédaction
Tag
  • Accessibilité