Aide à la création de contenu

La sainte trinité du contenu web : quand le balisage sémantique rencontre l'accessibilité… et la SEO

La sainte trinité du contenu web : quand le balisage sémantique rencontre l'accessibilité… et la SEO

Le jour où le chef de projet a compris le balisage sémantique (enfin presque)

« Mais pourquoi on met un <h1> ici, et un <p> là ? Ça rend pareil à l’écran ! » Cette question, je l’ai entendue des dizaines de fois. Et à chaque fois, je prends une grande inspiration, et je repars à l’attaque de mon combat éternel : expliquer l’importance du balisage sémantique. On parle souvent de performance, d'outils frontend de la mort qui tue, de frameworks à la mode... Mais on oublie trop souvent la base, le squelette même de nos créations : le HTML. Et pas n’importe quel HTML, le HTML qui a du sens, celui qui parle.

J'ai un jour eu un chef de projet, un bon gars au demeurant, mais qui voyait le HTML comme une série de boîtes à assembler pour que le visuel corresponde à la maquette. Point. Pas de fioritures. Il était persuadé que tant que le CSS faisait le boulot, le HTML n’était qu’un détail. Imaginez ma frustration. J'ai passé des heures à lui montrer des outils de lecture d'écran, à lui faire simuler une navigation au clavier, à lui expliquer comment Google (oui, même Google !) analyse la structure d'une page. Il a commencé à piger le truc quand je lui ai dit : « Imagine que tu lises un livre sans chapitres, sans titres, juste un pavé de texte. C’est ce que tu proposes à une partie de tes utilisateurs. » Bingo. Il a eu un déclic. Pas une révélation divine, mais un bon début.

Plus qu'une question de "beau", une question de "compréhensible"

On développe pour des humains, pas pour des navigateurs aveugles. Et pourtant, on a souvent cette tendance à tout mettre dans des <div> génériques en se disant que le CSS fera le reste. Grave erreur ! Le balisage sémantique, ce n'est pas juste pour les puristes qui veulent un code propre. C'est la fondation de l'accessibilité et un pilier essentiel pour le référencement naturel.

Si tu construis une maison sans fondations solides, elle finira par s'écrouler, peu importe la beauté de la peinture.

Pensez-y : un <header>, un <nav>, un <main>, un <article>, un <section>, un <aside>, un <footer>... Ce ne sont pas de simples balises. Ce sont des panneaux de signalisation pour le navigateur, pour les moteurs de recherche, et surtout, pour les technologies d'assistance. Elles donnent du sens, une structure logique à votre contenu. Comment un lecteur d'écran saurait qu'une partie de votre page est la navigation principale si vous l'avez encapsulée dans un simple <div> sans attribut role="navigation" ou, mieux encore, sans la balise <nav> ? Il ne le saura pas. Et votre utilisateur se retrouvera à errer dans un labyrinthe de texte. Et ça, c'est inacceptable.

L'accessibilité, ce n'est pas une option, c'est une obligation morale (et légale)

Combien de fois ai-je vu des interfaces flambant neuves, super design, avec des animations à tomber par terre, mais totalement inutilisables pour une personne handicapée ? C'est un crève-cœur. Et c'est souvent dû à un manque de considération dès le début du projet pour le balisage sémantique. Un bouton doit être un <button>, pas un <div> avec un onclick. Un lien doit être un <a>, pas un <span> stylisé. C'est la base. Et pourtant, on se prend encore les pieds dans le tapis sur ces fondamentaux. J'ai eu un projet où, pour des raisons de "facilité" (comprenez : "flemme"), l'intégrateur avait mis des <div> partout. Le résultat ? Une catastrophe pour l'accessibilité. On a dû reprendre une bonne partie du code. Coût supplémentaire, temps perdu, stress… tout ça pour avoir voulu gagner quelques minutes au début. Le calcul est vite fait.

Et au-delà de la morale, il y a la loi. De plus en plus de pays imposent des normes d'accessibilité strictes pour les sites web. Ne pas s'y conformer, c'est s'exposer à des amendes et à une mauvaise image. Mais surtout, c'est se priver d'une partie non négligeable de l'audience. Est-ce vraiment ce que l'on veut en 2024 ?

Le SEO : quand Google lit entre les balises (littéralement)

Ah, le SEO ! Le Graal des marketeurs et le cauchemar des développeurs qui doivent parfois jongler avec des requêtes farfelues. Mais le balisage sémantique, c'est votre meilleur ami dans cette quête. Google n'est pas un humain qui voit les couleurs et les polices. Google est un robot qui lit votre code. Et plus votre code est structuré, plus il a de sens, plus Google comprendra de quoi parle votre page. Un <h1> bien placé avec le titre principal de votre article ? Bingo, Google sait que c'est important. Des <h2> pour vos sous-titres ? Encore mieux, il comprend la hiérarchie de votre contenu. Des <article> pour vos articles de blog ? Il identifie clairement le contenu principal.

J'ai vu des sites avec un contenu de qualité exceptionnelle peiner à se positionner sur Google, simplement parce que leur HTML était un plat de spaghettis sans aucune structure logique. À l'inverse, des sites avec un contenu correct, mais un balisage sémantique impeccable, grimper dans les résultats. Ce n'est pas magique, c'est juste de la logique. Google récompense les sites bien faits, et un site bien fait, c'est d'abord un site bien structuré.

Mon plaidoyer pour un HTML qui a du sens (et qui nous facilite la vie)

Alors oui, je suis un fervent défenseur du balisage sémantique. Non pas par purisme, mais par pragmatisme. C'est un investissement minime au début d'un projet qui rapporte gros sur le long terme : en accessibilité, en SEO, et même en maintenabilité de votre code. Un code sémantique est plus facile à lire, à comprendre et à modifier pour n'importe quel développeur qui reprendra le projet après vous (ou vous-même dans six mois, quand vous aurez oublié pourquoi vous avez fait ce truc bizarre).

La prochaine fois que vous hésitez entre un <div> générique et une balise sémantique plus appropriée, prenez un instant. Pensez à l'utilisateur aveugle qui naviguera avec un lecteur d'écran. Pensez au robot de Google qui tentera de comprendre votre contenu. Pensez à votre futur vous qui devra débugger ce code. Et choisissez la sémantique. Votre conscience, vos utilisateurs, et votre référencement vous remercieront. Et peut-être même que votre chef de projet finira par comprendre, qui sait ?

Partager LinkedIn X Facebook

Commentaires

Connectez-vous pour laisser un commentaire.

Aucun commentaire pour le moment. Soyez le premier !