Phase 10 — Validation technique

Le code valide n'est pas une formalité

Un HTML invalide passe peut-être visuellement, mais il peut être mal interprété par certains navigateurs ou lecteurs d'écran. Une erreur JS en console peut casser une fonctionnalité uniquement chez certains utilisateurs, sans que vous le voyiez. La validation technique est l'étape qui détecte ce que vos yeux n'ont pas vu.

Objectifs de la phase

Cette phase couvre la section 10 de la checklist finale :

🔴 Critique	🟠 Important	🟢 Bonus
HTML valide (W3C Validator)	CSS valide	Score WAVE sans erreurs
	Pas d'erreurs JS en console	Testé avec lecteur d'écran
	Score Lighthouse Accessibility > 90

Validation HTML (W3C)

Le W3C Markup Validator vérifie que votre HTML respecte la spécification. C'est gratuit, rapide, et l'outil officiel.

URL : validator.w3.org

Trois modes d'utilisation

Mode	Quand
By URI	Site déjà en ligne — coller l'URL
By File Upload	Fichier HTML local
By Direct Input	Copier-coller le code

Lire les résultats

Niveau	Action
🔴 Error	À corriger obligatoirement — votre HTML est cassé
🟡 Warning	À examiner — souvent un attribut deprecated ou ambigu
ℹ️ Info	Pour information, pas d'action requise

Erreurs HTML les plus fréquentes

• Balise non fermée : <div> sans </div>
• Attribut alt manquant sur <img>
• id dupliqué dans la même page
• Balise interdite à cet endroit : ex. <div> dans <p>, <li> hors d'<ul>/<ol>
• Label sans for ou champ sans id associé

Validation CSS (W3C)

Le W3C CSS Validator vérifie votre CSS. Moins critique que le HTML (les navigateurs sont tolérants avec le CSS), mais utile pour repérer les propriétés inventées ou les fautes de frappe.

URL : jigsaw.w3.org/css-validator

Si vous utilisez Sass/SCSS

Validez le CSS compilé (le .css final), pas votre .scss source. Sass utilise une syntaxe qui n'est pas du CSS valide.

Console JavaScript propre

Une console pleine d'erreurs en production est un signal d'amateurisme et souvent le symptôme de fonctionnalités cassées.

Comment vérifier

1. Ouvrir votre site en navigation privée (pour exclure les extensions)
2. F12 (DevTools) → onglet Console
3. Recharger la page
4. Naviguer dans toutes les pages, cliquer sur les principales actions
5. 0 erreur rouge attendue

Types d'erreurs courantes

Type	Exemple	Cause typique
404	GET /img/photo.jpg 404	Image renommée, lien cassé
TypeError	Cannot read property 'x' of null	Élément DOM cherché avant d'exister
CORS	blocked by CORS policy	API tierce mal configurée
Mixed content	Blocked: mixed-content	HTTP chargé depuis HTTPS

Les warnings comptent aussi

Une page « 0 erreur rouge » mais 30 warnings jaunes mérite quand même un nettoyage. Beaucoup de warnings = code à risque le jour d'une mise à jour navigateur.

Lighthouse Accessibilité

Lighthouse (intégré Chrome DevTools, déjà présenté en Phase 7) produit un score d'accessibilité de 0 à 100.

Cible

Score	Évaluation
≥ 90	🟠 Attendu pour cette phase
≥ 95	🟢 Excellent
< 80	🔴 À corriger d'urgence

Points d'attention

Lighthouse n'audite que ce qui est testable automatiquement (60 % des critères WCAG environ). Un score de 100 ne garantit pas un site accessible — il garantit l'absence d'erreurs automatisables. Pour les 40 % restants, voir tests avec lecteur d'écran ci-dessous.

WAVE — audit visuel d'accessibilité

WAVE (Web Accessibility Evaluation Tool, par WebAIM) annote visuellement votre page avec les problèmes d'accessibilité.

URL : wave.webaim.org — aussi disponible en extension Chrome/Firefox.

Lire les résultats

Icône	Sens
🔴 Errors	Problèmes WCAG bloquants à corriger
🟠 Alerts	Risques probables (à examiner)
🟢 Features	Bonnes pratiques détectées (positif)
🟦 Structural	Structure de la page (titres, régions)
📋 ARIA	Attributs ARIA présents
🎨 Contrast errors	Contraste insuffisant texte/fond

Force de WAVE vs Lighthouse

Lighthouse donne un score chiffré, WAVE annote directement la page. Les deux sont complémentaires : Lighthouse pour le passage/échec rapide, WAVE pour comprendre où sont les problèmes visuellement.

Tests avec lecteur d'écran

Pour comprendre l'expérience des utilisateurs aveugles ou malvoyants, testez au moins une fois votre site avec un lecteur d'écran. C'est l'exercice qui révèle le plus de problèmes invisibles à l'œil.

Outil	Plateforme	Activation
VoiceOver ⭐	macOS / iOS (intégré)	Mac : Cmd+F5 · iOS : Réglages → Accessibilité → VoiceOver
NVDA	Windows (gratuit)	nvaccess.org — Ctrl+Alt+N
TalkBack	Android (intégré)	Paramètres → Accessibilité → TalkBack

Raccourcis essentiels (NVDA / VoiceOver Mac)

Action	NVDA	VoiceOver (Mac)
Démarrer / arrêter	Ctrl+Alt+N	Cmd+F5
Lire la page	NVDA+↓	VO+A
Naviguer par titres	H	VO+Cmd+H
Naviguer par liens	K	VO+Cmd+L

Ce qu'il faut vérifier

• L'ordre de lecture est logique (titre, contenu principal, navigation, footer)
• Toutes les images significatives ont un alt lu correctement
• Les liens annoncés sont compréhensibles hors contexte (« en savoir plus » seul = mauvais)
• Les formulaires annoncent chaque champ avec son label
• La navigation peut se faire au clavier uniquement (Tab, Enter, Espace)

Tests automatisés (CI/CD)

Pour les projets plus avancés, automatiser ces vérifications dans la CI :

Outil	Usage
Pa11y	CLI accessibilité — npm i -g pa11y puis pa11y https://votre-site.com
axe-core	Lib JS pour intégrer dans Cypress / Playwright / Vitest

# Pa11y — exemple
pa11y https://votre-site.com --reporter html > rapport.html

// Cypress + axe-core
import 'cypress-axe';

describe('Accessibilité', () => {
  it('ne doit pas avoir de violations', () => {
    cy.visit('/');
    cy.injectAxe();
    cy.checkA11y();
  });
});

Checklist de la Phase 10

• HTML validé via W3C Validator (0 erreur)
• CSS validé via W3C CSS Validator
• Console navigateur propre (0 erreur rouge)
• Score Lighthouse Accessibility > 90 (mode mobile)
• WAVE lancé sur les pages principales (0 erreur rouge)
• Testé au clavier uniquement (Tab → tous les éléments accessibles)
• Bonus : testé avec lecteur d'écran (VoiceOver, NVDA, TalkBack)

Prochaine étape

Le code est techniquement valide. Passez à la Phase 11 — Contenu pour vérifier que le contenu textuel est prêt à être publié.