RM Partie 8 : Bonnes pratiques et outils
Partie 8 — Bonnes pratiques et outils
1) Objectifs pédagogiques
- valider ton code HTML/CSS avec les bons outils (ex. W3C Validator)
- appliquer les règles d’accessibilité de base
(
alt,label,aria-*) - distinguer bonnes pratiques et mauvaises pratiques dans la rédaction de ton code
- utiliser les outils développeur des navigateurs (inspecteur, console, network, etc.)
- identifier les sources fiables de documentation (MDN, WHATWG, W3C).
2) Validation du code
2.1 Pourquoi valider ?
- Détecter des erreurs de syntaxe (balises mal fermées, attributs incorrects).
- Améliorer la compatibilité entre navigateurs.
- Assurer une meilleure accessibilité et un meilleur référencement.
2.2 Outils principaux
W3C Validator : https://validator.w3.org/
- Vérifie la conformité d’un document HTML/CSS.
- Trois méthodes : URL, upload de fichier, copier-coller du code.
Nu Html Checker (validator.w3.org/nu/) : version moderne du validateur HTML5.
CSS Validator : https://jigsaw.w3.org/css-validator/
2.3 Exemple d’erreurs détectables
- Attribut obsolète :
<font color="red"> - Oubli de fermeture de balise :
<p>Texte - Mauvais encodage :
<meta charset="latin1">
3) Accessibilité (A11y)
3.1 Pourquoi ?
- Rendre ton site utilisable par le plus grand nombre (personnes en situation de handicap, navigation vocale, lecteurs d’écran).
- Obligations légales (en France → RGAA, en Europe → directives d’accessibilité numérique).
3.2 Attribut
alt pour les images
- Toujours obligatoire sur
<img>. - Sert de texte alternatif pour les lecteurs d’écran ou si l’image ne se charge pas.
Exemple :
<img src="chaton.jpg" alt="Un chaton tigré qui dort dans un panier">Cas particuliers :
- Image décorative →
alt=""(vide). - Logo →
alt="Nom de l’entreprise".
3.3 Labels pour les formulaires
Chaque champ de formulaire doit être associé à un label :
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email">- Accessibilité : le label est lu avec le champ.
- Ergonomie : clic sur le label → focus dans le champ.
3.4 Attributs ARIA
- ARIA = Accessible Rich Internet Applications.
- Sert à décrire le rôle ou l’état d’éléments interactifs complexes.
- Exemples :
<nav aria-label="Menu principal">
<ul>
<li><a href="/accueil">Accueil</a></li>
<li><a href="/contact">Contact</a></li>
</ul>
</nav>
<button aria-expanded="false" aria-controls="menu">Menu</button>
<div id="menu" hidden>…</div>3.5 Autres bonnes pratiques A11y
- Contrastes suffisants (ratio recommandé : 4.5:1).
- Navigation clavier fluide (
tabindex, éviteroutline: none). - Titres hiérarchisés (
<h1>puis<h2>, etc.). - Éviter les textes en image (préférer du texte + CSS).
4) Bonnes pratiques vs mauvaises pratiques
4.1 Code obsolète ou à éviter
- Mauvais :
<font color="red">Texte</font>
<center>Texte centré</center>
<b>Texte en gras</b>
<i>Texte en italique</i>- Bon :
<p style="color: red;">Texte</p> <!-- encore inline -->
<p class="important">Texte</p> <!-- mieux -->
<strong>Texte important</strong> <!-- sémantique -->
<em>Texte mis en valeur</em> <!-- sémantique -->Avec CSS :
.important { color: red; font-weight: bold; }4.2 Séparation contenu / style / comportement
- HTML = contenu et structure.
- CSS = présentation.
- JavaScript = interaction et logique.
Ne mélange pas :
<!-- Mauvais -->
<p style="color: blue;" onclick="alert('ok')">Clique</p>
<!-- Bon -->
<p class="lien-action">Clique</p>.lien-action { color: blue; cursor: pointer; }document.querySelector('.lien-action')
.addEventListener('click', () => alert('ok'));4.3 Indentation et lisibilité
- Indente ton code (2 ou 4 espaces, mais constant).
- Utilise des noms de classes/ids explicites.
- Ferme les balises, même si facultatif
(
<li>,<p>). - Organise ton projet (dossier
assets/pour CSS, JS, images).
5) Outils développeur des navigateurs
5.1 L’inspecteur d’éléments
- Clic droit → « Inspecter » ou touche F12.
- Permet de voir le DOM en temps réel, les styles appliqués, la hiérarchie des balises.
- Tu peux modifier le HTML/CSS à la volée pour tester.
5.2 La console
- Affiche les erreurs JavaScript et messages
(
console.log()). - Sert à tester du code JS directement. Exemple :
console.log("Bonjour !");5.3 L’onglet « Réseau » (Network)
- Suivi des requêtes HTTP (fichiers CSS, images, scripts…).
- Vérifie les codes de réponse (200, 404, 500…).
- Analyse les temps de chargement.
5.4 L’onglet « Performances » / « Lighthouse »
- Mesure le temps de rendu, l’accessibilité, le SEO, les bonnes pratiques.
- Donne un score et des recommandations.
6) Documentation fiable
6.1 MDN Web Docs
- https://developer.mozilla.org/
- Référence la plus fiable pour HTML, CSS, JS.
- Explications claires, exemples, compatibilité navigateur.
6.2 Spécifications
- WHATWG HTML Living Standard : https://html.spec.whatwg.org/
- W3C : https://www.w3.org/TR/html/ (versions publiées, moins récentes)
6.3 Autres ressources
- Can I use : https://caniuse.com/ (compatibilité des fonctionnalités web).
- Web.dev (Google) : https://web.dev/ (bonnes pratiques web modernes).
- Évite les sites non officiels (W3Schools peut servir d’introduction, mais pas toujours exact).
7) Exercice
But :
- Écris un petit document HTML volontairement erroné (ex :
balises non fermées, usage de
<center>, image sansalt). - Vérifie-le avec https://validator.w3.org/
- Corrige les erreurs.
- Ajoute une image avec
alt, un formulaire avec deslabel, et unaria-labelsur une navigation. - Utilise les outils développeur de ton navigateur pour tester l’affichage et la console.
8) Corrigé possible
Mauvaise version :
<!DOCTYPE html>
<html>
<head>
<title>Test</title>
</head>
<body>
<center><h1>Bienvenue</h1></center>
<img src="chat.jpg">
<form>
<input type="text" placeholder="Nom">
<input type="email">
<button>Envoyer</button>
</form>
</body>
</html>Version corrigée :
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="utf-8">
<title>Exemple corrigé</title>
</head>
<body>
<header>
<h1>Bienvenue</h1>
</header>
<main>
<img src="chat.jpg" alt="Un chat gris assis sur une chaise">
<form action="/contact" method="post">
<div>
<label for="nom">Nom</label>
<input type="text" id="nom" name="nom" required>
</div>
<div>
<label for="email">E-mail</label>
<input type="email" id="email" name="email" required>
</div>
<button type="submit">Envoyer</button>
</form>
</main>
<nav aria-label="Menu principal">
<ul>
<li><a href="#">Accueil</a></li>
<li><a href="#">Contact</a></li>
</ul>
</nav>
</body>
</html>9) Mini-quiz
- À quoi sert https://validator.w3.org/ ?
- Donne un exemple où
alt=""est la bonne pratique. - Pourquoi
<center>et<font>sont-ils à éviter ? Quelle alternative utiliser ? - Comment associer correctement un label et un champ ?
- Quelle différence entre
aria-labelet<label>? - Quel outil permet de tester la compatibilité des fonctionnalités web dans les navigateurs ?
- Quelle est la meilleure source de documentation HTML/CSS/JS ?
Réponses :
- Vérifier la conformité HTML/CSS et détecter des erreurs.
- Pour une image purement décorative.
- Balises obsolètes → utiliser CSS (
text-align,color). - En reliant
for="id"du<label>avec l’idde l’<input>. aria-labelfournit un libellé invisible (accessibilité) ;<label>associe visuellement et sémantiquement.- Can I use (https://caniuse.com/).
- MDN Web Docs.
10) Fiche-mémo
Validation : https://validator.w3.org/ (HTML), https://jigsaw.w3.org/css-validator/ (CSS).
Accessibilité :
altobligatoire ;alt=""pour images décoratives.<label>obligatoire pour les champs.aria-*pour rôles/états supplémentaires.- Contrastes, navigation clavier, titres hiérarchisés.
Évite :
<font>,<center>, styles inline,onclick="…".Sépare : HTML (contenu), CSS (style), JS (logique).
Outils dev navigateur : Inspecteur, Console, Réseau, Performances/Lighthouse.
Docs fiables : MDN, WHATWG HTML Living Standard, W3C TR, Can I use, web.dev.