Bases d’un thème optimisé

Le thème d’un site constitue la partie visuelle de celui ci mais pas uniquement ! Outre son design, le thème c’est une structure html qui doit être solide, accessible, avec une sémantique correctement définie, du css facile à maintenir, optimisé pour le chargement, des scripts qui ne bloquent pas l’affichage du site, et comme nous sommes sous un CMS, les fonctions php spécifiques de WordPress utilisées doivent être à jour etc …

En travaillant à la création de thèmes personnalisés, j’ai constaté qu’il y avait divers points auxquels il fallait faire attention dans un thème pour qu’il soit un minimum optimisé. Se constituer une check list d’éléments que l’on considère importants peut être d’une aide précieuse. Cela permet de créer ses propres thèmes en ayant une ligne directrice. Et si on en achète un sur des plateformes dédiées, de l’analyser pour vérifier ses manques.

Voici ma checklist pour le moment, elle sera réactualisée régulièrement.

Un thème devrait pouvoir être changé facilement

Un thème ne devrait pas enfermer dans son utilisation. Cela implique :

  • qu’il ne devrait pas intégrer la création de Custom Post Type : les contenus spécifiques devraient être générés via des plugins, sans quoi changer de thème ferait perdre l’affichage de pans entiers de contenus au site.
  • pour les shortcodes, même chose que pour les CPT, il est préférable qu’ils soient placés dans un plugin et pas dans le thème lui même. En cas de changement de thème ils ne pourront plus être interprétés et seront rendus tels quels avec leurs crochets [monshortcode] dans le texte.

Maintenant, le bémol : Dès lors que l’on crée un thème entièrement personnalisé, éventuellement en prenant les services d’une intégrateur/développeur WordPress, il y a peu de chances qu’on en change comme de chemise ! Donc ce qui est dit plus haut est à mon sens surtout valable quand on cherche à utiliser des thèmes prêts à l’emploi qu’on peut acheter sur des plateformes comme Themeforest, Elegant thèmes, Woothèmes etc …

Respecter les standards de wp

Les fonctions présentes dans un thème doivent être à jour. Pour le vérifier :

  • activer le debug à true dans le fichier wp-config.php : define('WP_DEBUG', true);  vous serez averti si des fonctions sont devenues obsolètes etc …
  • pour avoir des infos plus complètes utiliser le plugin Log Deprecated Notices,
  • des plugins utiles aussi pour tester un thème : Theme Check, Theme Sniffer
  • Installer PHP Code Sniffer sur son éditeur de texte en lui passant les Coding Standard PHP de WP

Vérifier l’architecture html

  • Un attribut lang est il bien présent sur le site au niveau de la balise html ? Cela permet  de rendre possible les traductions et aux lecteurs d’écran de prononcer correctement le contenu du site.
  • Les balises titres sont elles correctement hiérachisées, les sauts de niveaux sont à proscrire. Pour le vérifier on peut le faire dans le code source mais il existe d’autres moyens plus efficaces. (Article en préparation !)
  • Les balises sémantiques HTML5 comme articles ou section ou aside sont elles utilisées à bon escient ? La sémantique est elle valide ?
  • La sémantique a t’elle été renforcée par des microdatas, du balisage aria, microformat hatom, des données structurées ? C’est une bonne chose de le faire. (Article en préparation : « Renforcer la sémantique de sa structure html »)
  • Tracker les identifiants dupliqués. Un identifiant c’est unique !
  • Utiliser un outil comme HTML Code Sniffer pour faire une bonne partie des tests facilement

Vérifier le css

  • Si vous voyez des  !important à tout va dans les feuilles de style, c’est un problème ! Cela vous indique que votre css sera bien difficile à maintenir sur la durée quand il va s’enrichir …
  • la palette des couleurs peut être variée mais doit être efficace, si vous constatez un nombre de variantes infinies, ça aura besoin d’être nettoyé (utiliser sass permet de prendre garde à cet aspect)
  • Du font-size trop modifié selon le type de page etc … il vaut mieux le fixer assez tôt dans une feuille de style et ne faire des modifications que si c’est vraiment nécessaire.

Vérifier l’impact du javascript

Le JS, peut se mêler de générer de l’affichage, il faut faire attention qu’il ne fasse pas perdre l’accès à du contenu important s’il est désactivé sur le navigateur du visiteur. Bien sûr de plus en plus de sites maintenant utilise le js pour générer complètement leur contenu, mais là on est sous WordPress, donc en PHP alors on peut faire un effort.

Si vous utilisez Ajax pour afficher du contenu, alors prévoir ce qu’il faut pour que ce ne soit pas invalidant pour la visite du site sans JS.

Le JS peut aussi être utilisé pour améliorer l’accessibilité, avec l’ajout de classes comme aria-expanded false ou true … ou is-active etc … là on ne peut pas y faire grand chose. Prévenir le visiteur que le Javascript est nécessaire à une bonne navigation sur le site.

Au niveau UX

  • Eviter la duplication de contenu provenant de liens générés inutilement :
    • comme des liens vers des archives de dates, d’auteur alors qu’on peut être le seul auteur du site …
    • ou des liens d’archives par date, perso je ne vois pas leur utilité
  • Faire en sorte de ne pas avoir de lien qui pointent vers la page courante
    • comme le lien vers la catégorie alors qu’on est déjà dans la dite catégorie
    • comme le lien du menu qui reste cliquable alors qu’on est déjà dans la page de destination du dit lien
  • S’il n’y en a pas, ajouter un fil d’ariane c’est extrêmement pratique pour le visiteur, cela fait d’ailleurs parti des recommandations du WCAG.
  • Vous pouvez aussi ajouter un sitemap html (le sitemap xml servant lui aux robots d’indexation), mais bon, si le menu de navigation est bien construit c’est juste un plus.
  • Vérifier que les chaines getText sont bien traduites, sur un site en français, voir un Readmore c’est pas terrible. Utiliser PoEdit.

Au niveau accessibilité

  • dans le css : pas de outline à none, sinon la navigation au clavier ne rendra aucun visuel pour s’y retrouver ! ou alors prévoir une alternative.
  • pas de maximum-scale=1.0 : cet attribut empêche de zoomer le site sur mobile.
  • Tester le site en zoomant à 200% pour s’assurer que tous les contenus restent visibles et lisibles.
  • Existe t’il des liens d’évitement (ou liens d’accès rapides) pour la navigation au clavier ?
  • analyser le ratio des contrastes avec Colour Contrast Analyser par exemple, disponible pour Windows et Mac : https://developer.paciellogroup.com/resources/contrastanalyser/
  • vérifier que la navigation au clavier est correctement mise en place.
  • Mettez en place un lecteur d’écran comme NVDA pour Windows, (VoiceOver est déjà présent sur Mac) cela permet de se rendre compte de la navigabilité dans le site pour une personne malvoyante ou aveugle.
  • Les menus déroulants ne doivent pas être trop complexes, 2 niveaux de profondeur devraient être suffisant.
  • Penser à ajouter en JS des classes lors d’évènements  comme :focus :active et des attributs comme aria-expanded= »true » ou « false »
  • Vérifier de façon générale la navigation à la tabulation : Elle doit se faire dans le « bon ordre », on doit pouvoir accéder à tous les éléments interactifs.
  • sur son navigateur, installer aXe , a11y.css, tota11y, permettent de faire des tests d’accessibilité facilement.