Web · FrontendDébutant≈ 2h15 · 7 chapitres

Introduction à HTML et CSS

Structurer une page avec HTML sémantique, la mettre en page avec Flexbox et Grid, la rendre responsive et accessible. Les bases solides du web moderne.

À la fin du cours, tu sais

Écrire une structure HTML5 sémantique propre
Comprendre la cascade et la spécificité CSS
Maîtriser Flexbox pour les layouts 1D
Maîtriser CSS Grid pour les layouts 2D
Concevoir une page responsive mobile-first
Intégrer l'accessibilité de base (contraste, focus, sémantique)

Prérequis

Savoir ouvrir un éditeur et un navigateur
Idéalement : avoir suivi le cours « Bien démarrer son environnement »

Chapitre 11 / 10

Chapitre 1

Anatomie d'une page HTML5

Toute page web démarre par un squelette standard qui indique au navigateur comment interpréter le document.

Toute page web, de la plus simple à la plus complexe, repose sur le même squelette de départ. Ce n'est pas une formalité : chaque ligne du <head> donne au navigateur une information dont il a besoin pour interpréter correctement ton document. Sauter ou bâcler cette base, c'est s'exposer à des accents cassés, un affichage mobile raté ou un référencement dégradé — des problèmes qu'on traîne ensuite sans comprendre d'où ils viennent.

Les éléments à connaître, détaillés ci-dessous : <!DOCTYPE html> active le mode standard HTML5 ; lang="fr" annonce la langue, essentielle pour les lecteurs d'écran et le référencement (SEO) ; <meta charset="UTF-8"> garantit que les accents et les emojis s'affichent ; <meta name="viewport"> est indispensable pour que le mobile n'affiche pas une version miniature du bureau ; et <title> nomme l'onglet et le résultat dans Google. Ces cinq lignes, tu les écriras des centaines de fois — autant les comprendre une bonne fois.

Le cœur de HTML5, c'est la sémantique : choisir des balises qui décrivent le sens du contenu, pas seulement son apparence. Un <div> ne dit rien à personne ; un <nav> annonce « voici la navigation », un <main> « voici le contenu principal », un <article> « voici un contenu autonome ». Ce vocabulaire (header, nav, main, section, article, aside, footer) est lu par le navigateur, les lecteurs d'écran et les moteurs de recherche. Bien choisir sa balise, c'est gagner gratuitement en accessibilité et en SEO — sans une ligne de CSS ou de JavaScript en plus.

Le squelette obligatoire

<!DOCTYPE html>
<html lang="fr">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Mon profil</title>
  </head>
  <body>
    <header>
      <h1>Bonjour, c'est moi</h1>
    </header>
    <main>
      <!-- Contenu principal -->
    </main>
    <footer>
      <p>© 2026</p>
    </footer>
  </body>
</html>

Les éléments clés du <code>head</code>

<!DOCTYPE html> active le mode HTML5 du navigateur
<html lang="fr"> indique la langue (essentiel pour les lecteurs d'écran et le SEO)
<meta charset="UTF-8"> support des accents et emojis
<meta name="viewport"> indispensable pour le mobile
<title> affiché dans l'onglet et dans Google

Les balises sémantiques HTML5

<header> : en-tête de page ou de section
<nav> : navigation principale
<main> : contenu principal, un seul par page
<section> : regroupement thématique
<article> : contenu indépendant (article de blog, carte produit)
<aside> : contenu lié mais secondaire (encart, related)
<footer> : pied de page ou de section

Pourquoi la sémantique

Un <div> ne dit rien. Un <nav> dit « voici la navigation » au navigateur, au lecteur d'écran, à Google. Le SEO et l'accessibilité gagnent gratuitement quand tu choisis la bonne balise.

Chapitre 2

Texte, liens et médias

Le contenu repose sur quelques balises bien choisies. Pas besoin de tout connaître.

HTML compte plus d'une centaine de balises, mais rassure-toi : une quinzaine suffit à écrire l'immense majorité des pages. L'important n'est pas de toutes les connaître, mais de choisir la bonne pour chaque contenu. Les titres, en particulier, ne sont pas qu'une question de taille : la hiérarchie <h1> à <h6> structure le document comme le plan d'un mémoire. Un seul <h1> par page, puis des sous-titres imbriqués sans saut de niveau — c'est ce plan que suit un lecteur d'écran pour naviguer.

Une distinction que beaucoup de débutant·es ratent : privilégie <strong> et <em> plutôt que <b> et <i>. Visuellement le rendu est identique (gras et italique), mais <strong> et <em> portent un sens — une importance, une insistance — que les technologies d'assistance restituent, là où <b> et <i> ne sont que du style. Pour les liens, deux réflexes : ajoute rel="noopener noreferrer" sur les liens externes ouverts dans un nouvel onglet (sécurité), et surtout rends leur texte descriptif. Un lecteur d'écran qui liste les liens hors contexte ne doit pas entendre « Cliquez ici, Cliquez ici » mais « Lire l'article complet », « Nous contacter ».

Pour les images, tout se joue sur l'attribut alt, qui est obligatoire. S'il porte du sens, décris-le (alt="Photo d'Anaïs souriante") ; s'il est purement décoratif, mets un alt vide (alt="") pour signaler au lecteur d'écran de l'ignorer. Le pire des cas est l'absence totale d'alt : le lecteur d'écran se rabat alors sur le nom du fichier et annonce quelque chose comme « IMG underscore 4573 point jpg », ce qui est aussi inutile qu'agaçant. Ajoute loading="lazy" sur les images hors écran pour ne les charger qu'au moment où elles deviennent visibles.

Titres et texte

<h1> à <h6> : hiérarchie de titres. Un seul h1 par page.
<p> : paragraphe
<strong> : emphase forte (sémantique). Pas <b>
<em> : emphase légère. Pas <i>
<ul> / <ol> / <li> : listes

Liens

<!-- Lien interne -->
<a href="/contact">Nous contacter</a>

<!-- Lien externe : noopener noreferrer pour la sécurité -->
<a href="https://example.fr" target="_blank" rel="noopener noreferrer">
  Site externe
</a>

Pas de « Cliquez ici »

Le texte du lien doit décrire la destination, pas l'action. Un lecteur d'écran qui liste les liens hors contexte verra « Cliquez ici, Cliquez ici, Cliquez ici ». Préfère « Lire l'article complet ».

Images

<!-- Image porteuse de sens : alt descriptif -->
<img src="/avatar.jpg" alt="Photo d'Anaïs souriante" />

<!-- Image purement décorative : alt vide -->
<img src="/separateur.svg" alt="" />

<!-- Lazy loading pour les images hors écran -->
<img src="/photo.jpg" alt="..." loading="lazy" />

alt est obligatoire. alt="" (vide) signale au lecteur d'écran d'ignorer l'image décorative. Sans alt, le lecteur d'écran lit le nom du fichier, c'est catastrophique.

Chapitre 3

Formulaires accessibles

Un formulaire utilisable, c'est d'abord des labels associés aux inputs. Le reste suit.

Les formulaires sont l'endroit où l'accessibilité se joue le plus concrètement : c'est là qu'on demande une action à l'utilisateur·ice, et donc là qu'un défaut bloque vraiment. La règle fondatrice tient en un mot : chaque champ doit avoir un label associé. On relie le <label> à l'<input> en faisant correspondre l'attribut for du label à l'id du champ (ou en enveloppant l'input dans le label). Ce lien rend deux services : cliquer sur le texte place le curseur dans le champ, et surtout le lecteur d'écran annonce le bon libellé au bon moment. Un champ sans label, c'est un champ que certaines personnes ne peuvent tout simplement pas remplir.

Le bon type fait beaucoup de travail gratuitement. type="email", "tel", "number" ou "date" déclenchent sur mobile le clavier adapté (le pavé numérique pour un téléphone, le @ visible pour un email) et activent une validation native du navigateur. Ajoute autocomplete pour laisser les gestionnaires de mots de passe et l'autofill remplir le champ, required pour marquer l'obligation, et aria-describedby pour rattacher un texte d'aide au champ. Ces attributs, invisibles à l'œil, transforment l'expérience réelle de saisie.

Deux points pour finir. Quand plusieurs champs forment un groupe (des boutons radio, des cases à cocher liées), enveloppe-les dans un <fieldset> avec une <legend> : le lecteur d'écran annonce alors la question commune avant chaque option, ce qui donne le contexte. Et surtout, ne supprime jamais l'outline du focus sans le remplacer par un style bien visible : les personnes qui remplissent un formulaire au clavier ont besoin de voir en permanence dans quel champ elles se trouvent. Un formulaire accessible n'est pas un formulaire « en plus » — c'est simplement un formulaire qui fonctionne pour tout le monde.

Le pattern de base

<label for="email">Adresse e-mail</label>
<input
  id="email"
  type="email"
  name="email"
  autocomplete="email"
  required
  aria-describedby="email-help"
/>
<p id="email-help" class="help">
  On ne partagera jamais ton email.
</p>

Les attributs essentiels

for du label = id de l'input : obligatoire
type="email", tel", number", date" : clavier adapté sur mobile, validation native
autocomplete : aide les password managers et l'autofill
required : champ obligatoire
aria-describedby : lie un texte d'aide à l'input

Grouper plusieurs champs liés

<fieldset>
  <legend>Préférences de contact</legend>

  <label>
    <input type="radio" name="contact" value="email" />
    Email
  </label>

  <label>
    <input type="radio" name="contact" value="telephone" />
    Téléphone
  </label>
</fieldset>

Jamais outline: none sans remplacement

Ne supprime jamais l'outline du focus sans la remplacer par un autre style visible. Les personnes qui naviguent au clavier ont besoin de voir où elles en sont.

Chapitre 4

CSS : sélecteurs, cascade, spécificité

CSS applique des styles via des sélecteurs, avec une logique de priorité. Comprendre ces règles évite 90 % des problèmes « mon CSS ne s'applique pas ».

CSS repose sur un principe simple : tu vises des éléments avec un sélecteur, puis tu leur appliques des styles. La difficulté n'est pas d'écrire une règle, mais de comprendre laquelle gagne quand plusieurs règles visent le même élément. C'est là que se cache la fameuse frustration « mon CSS ne s'applique pas » : neuf fois sur dix, ton style est bien écrit, mais une autre règle plus prioritaire l'écrase. Maîtriser la cascade et la spécificité, c'est se débarrasser de 90 % de ces énigmes.

Il existe plusieurs familles de sélecteurs, du plus général au plus précis : par balise (p), par classe (.card, de loin le plus utilisé), par identifiant (#header, rare car trop fort), par attribut (input[type="email"]), sans oublier les pseudo-classes (:hover, :focus-visible) et pseudo-éléments (::first-letter). Quand deux règles entrent en conflit, la plus spécifique l'emporte, selon un ordre à connaître par cœur : !important d'abord (à fuir), puis le style en ligne, puis les identifiants, puis les classes et pseudo-classes, et enfin les balises. À spécificité égale, c'est la règle écrite en dernier qui gagne.

Deux conseils de survie. D'abord, évite !important : si tu en as besoin pour faire passer un style, c'est généralement le symptôme d'un sélecteur trop puissant ailleurs (souvent un #id) — mieux vaut corriger la cause en ajoutant une classe précise que d'empiler les !important, ingérables à plusieurs. Ensuite, apprivoise les sélecteurs modernes qui simplifient la vie : :has() permet enfin de styler un parent selon ses enfants, :is() et :where() regroupent des sélecteurs sans se répéter, et :not() exclut des cas. Bien utilisés, ils rendent ton CSS plus court et plus lisible.

Les types de sélecteurs

/* Par tag */
p { color: blue; }

/* Par classe (le plus utilisé) */
.card { padding: 1rem; }

/* Par id (rare, trop spécifique) */
#header { background: white; }

/* Par attribut */
input[type="email"] { border-color: green; }

/* Pseudo-classes */
a:hover { text-decoration: underline; }
button:focus-visible { outline: 2px solid currentColor; }

/* Pseudo-éléments */
p::first-letter { font-size: 2em; }

La spécificité

Quand deux règles s'appliquent au même élément, la plus spécifique gagne. Ordre de priorité :

!important (à éviter, dernier recours)
Style inline (style="...")
ID (#header)
Classe / attribut / pseudo-classe (.card, :hover)
Tag (p, div)

Éviter !important

Si tu as besoin d'!important pour faire passer ton style, c'est souvent qu'il y a un sélecteur trop fort ailleurs. Préfère ajouter une classe plus précise. !important en cascade dans une équipe devient vite ingérable.

Les sélecteurs modernes utiles

/* :has() : styler un parent selon ses enfants (depuis 2023) */
.card:has(img) {
  padding-block: 1rem;
}

/* :is() / :where() : grouper sans répéter */
:is(h1, h2, h3) {
  font-family: 'DM Serif Display', serif;
}

/* :focus-visible : focus visible uniquement clavier */
button:focus-visible {
  outline: 2px solid var(--accent);
}

/* :not() : exclusion */
.btn:not(.btn-primary) {
  background: transparent;
}

Chapitre 5

Box Model, Flexbox, Grid

Tout élément HTML est une boîte. Le layout moderne utilise Flexbox (1D) ou Grid (2D). On n'utilise plus les floats pour le layout en 2025.

Pour maîtriser la mise en page, il faut d'abord accepter une idée : en CSS, tout élément est une boîte. Chaque boîte se compose de son contenu, entouré d'un rembourrage interne (padding), d'une bordure (border) et d'une marge externe (margin). Le piège classique du débutant vient du calcul de la largeur : par défaut, width ne concerne que le contenu, si bien qu'ajouter du padding fait déborder la boîte de la taille prévue. Le réflexe universel qui règle ça une fois pour toutes, montré ci-dessous, est de passer tout le document en box-sizing: border-box — la largeur inclut alors padding et bordure, ce qui est bien plus intuitif.

Pour agencer ces boîtes, on dispose de deux outils modernes, et il est essentiel de savoir lequel choisir. Flexbox gère les dispositions en une dimension : une rangée ou une colonne d'éléments, comme une barre de navigation, une liste de tags qui s'enroule, ou un centrage parfait. Grid gère les dispositions en deux dimensions : des lignes et des colonnes structurées simultanément, comme une sidebar + contenu ou une galerie de cartes. La règle simple : une seule direction → Flexbox ; une vraie grille → Grid. Et on n'utilise plus les floats pour la mise en page : c'était un détournement d'un outil prévu pour habiller du texte autour d'une image.

Un dernier réflexe qui change le quotidien : la propriété gap. Autrefois, espacer des éléments imposait de mettre une marge sur chacun puis de l'annuler sur le dernier — pénible et source de bugs. Aujourd'hui, tu poses gap: 1rem sur le conteneur et l'espacement entre les enfants est symétrique et automatique. Détail utile : gap est née dans Grid mais fonctionne désormais aussi bien en Flexbox. Avec box-sizing, le bon choix Flex/Grid et gap, tu tiens déjà de quoi construire la quasi-totalité des mises en page que tu rencontreras.

Box Model

Une boîte CSS = content + padding + border + margin. Par défaut, la largeur d'un élément ne compte que le content, ce qui rend les calculs pénibles.

Le réflexe universel : box-sizing global

*, *::before, *::after {
  box-sizing: border-box;
}

Avec border-box, width: 200px inclut padding et border. Beaucoup plus intuitif.

Flexbox : layouts 1D

/* Une barre de navigation : items alignés horizontalement */
.nav {
  display: flex;
  gap: 1.5rem;
  align-items: center;
  justify-content: space-between;
}

/* Une grille de tags qui s'enroule */
.tags {
  display: flex;
  flex-wrap: wrap;
  gap: 0.5rem;
}

/* Centrer parfaitement n'importe quoi */
.centre {
  display: flex;
  align-items: center;
  justify-content: center;
}

Grid : layouts 2D

/* Un layout sidebar + contenu */
.app {
  display: grid;
  grid-template-columns: 240px 1fr;
  gap: 2rem;
}

/* Une grille de cartes responsive */
.cartes {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 1.5rem;
}

gap remplace les margins

Avant : margin-right: 1rem sur chaque item, puis &:last-child { margin-right: 0 }. Aujourd'hui : gap: 1rem sur le parent, symétrique, simple. Marche en Flex et Grid.

Vrai ou faux ?

La propriété gap fonctionne aussi bien en Flexbox qu'en Grid pour espacer les éléments.

Chapitre 6

Responsive moderne et variables CSS

On conçoit mobile-first (le mobile par défaut, on adapte vers le grand écran). Et on utilise des variables CSS pour éviter de répéter ses tokens.

Le web se consulte majoritairement sur mobile : on conçoit donc mobile-first. Concrètement, tes styles de base visent le petit écran, et tu ajoutes progressivement des ajustements pour les écrans plus larges à l'aide de @media (min-width: …). Cette approche a une vertu cachée : elle t'oblige à décider ce qui est essentiel (ce qui tient sur mobile) avant d'enrichir, plutôt que de tout entasser puis de tenter de faire rentrer sur petit écran. On raisonne en min-width croissant, du plus petit au plus grand.

À côté des media queries classiques (qui réagissent à la taille de l'écran), CSS propose désormais les container queries, qui réagissent à la taille du conteneur parent. La différence est majeure : un même composant — une carte, par exemple — peut ainsi s'afficher en une colonne dans une sidebar étroite et en deux colonnes dans la zone principale large, sans savoir quoi que ce soit de l'écran global. C'est l'outil qui rend enfin les composants vraiment réutilisables d'un contexte à l'autre. Pour les tailles elles-mêmes, la fonction clamp() permet des valeurs fluides entre un minimum et un maximum (par exemple une taille de titre qui grandit avec l'écran sans jamais devenir énorme ni minuscule).

Dernier pilier, les variables CSS (custom properties). Plutôt que de répéter la même couleur ou le même espacement des dizaines de fois, tu les définis une fois dans :root (--color-accent, --space-2…) et tu les réutilises partout avec var(). Le jour où tu changes une couleur de marque, tu modifies une seule ligne. Ces variables débloquent aussi un thème sombre quasi gratuit : redéfinis simplement tes --color-* à l'intérieur de @media (prefers-color-scheme: dark) et tout ton site bascule. C'est cette centralisation des « tokens » qui fait la différence entre un CSS bricolé et un CSS maintenable, comme le montre le scénario ci-dessous sur une grille qui casse en mobile.

Media queries (mobile-first)

/* Mobile par défaut */
.layout {
  padding: 1rem;
}

/* Tablette et au-dessus */
@media (min-width: 48rem) {
  .layout {
    padding: 2rem;
  }
}

/* Desktop */
@media (min-width: 80rem) {
  .layout {
    max-width: 72rem;
    margin-inline: auto;
  }
}

Container queries (depuis 2023)

Un composant s'adapte à la taille de son conteneur, pas du viewport. Indispensable quand le même composant vit dans plusieurs contextes (sidebar étroite + zone principale large).

.card {
  container-type: inline-size;
}

@container (min-width: 30rem) {
  .card .layout {
    display: grid;
    grid-template-columns: 1fr 2fr;
  }
}

Variables CSS (custom properties)

:root {
  --color-text: #1a1523;
  --color-accent: #e86b2c;
  --space-1: 0.5rem;
  --space-2: 1rem;
  --space-3: 1.5rem;
  --radius: 0.75rem;
}

.btn {
  background: var(--color-accent);
  padding: var(--space-1) var(--space-2);
  border-radius: var(--radius);
  color: white;
}

Thèmes sombres en 1 ligne

Avec prefers-color-scheme + variables, tu fais un dark mode en 5 lignes : redéfinis tes --color-* dans @media (prefers-color-scheme: dark) { :root { ... } }. Tout ton site bascule.

Unités fluides

/* Tailles qui s'adaptent au viewport entre un min et un max */
h1 {
  font-size: clamp(1.5rem, 4vw, 3rem);
}

.container {
  padding-inline: clamp(1rem, 5vw, 4rem);
}

🧭 Mise en situation : ta page casse sur mobile

Un client te signale que ta grille de cartes déborde de l'écran sur son téléphone. Tu ouvres le projet. Par quoi tu commences ?

Tu reproduis le bug dans les DevTools en mode mobile. La grille a grid-template-columns: repeat(3, 1fr) en dur. Que fais-tu ?

Chapitre 7

Accessibilité et bonnes pratiques

L'accessibilité fait partie de la qualité du code, pas d'une option. Quelques réflexes couvrent 80 % des besoins.

L'accessibilité (souvent abrégée a11y) n'est pas une couche cosmétique qu'on ajoute à la fin : elle fait partie intégrante de la qualité d'une page, au même titre que la performance ou la sécurité. Une page accessible est utilisable par une personne aveugle avec un lecteur d'écran, par quelqu'un qui navigue au clavier faute de pouvoir tenir une souris, par une personne malvoyante qui zoome à 200 %. Bonne nouvelle : tu n'as pas besoin d'être expert·e pour couvrir l'essentiel — quelques réflexes réglés dès l'écriture du HTML et du CSS traitent environ 80 % des besoins.

Les fondamentaux tiennent en cinq points : du HTML sémantique d'abord (un vrai <button> est nativement accessible, un <div onclick> ne l'est pas) ; un contraste d'au moins 4.5:1 entre le texte et son fond (niveau AA des WCAG) ; un focus toujours visible ; une navigation clavier complète (Tab, Entrée, Échap) ; et une hiérarchie de titres cohérente, sans saut de niveau. Aucun de ces points ne demande d'outil particulier — juste de bons choix au moment d'écrire le code.

Quand le HTML ne suffit pas, on complète avec les attributs ARIA : aria-label pour nommer un bouton-icône sans texte, aria-current="page" pour marquer le lien actif, aria-hidden="true" pour masquer une décoration au lecteur d'écran. Mais retiens la règle d'or : HTML d'abord, ARIA en dernier. Un ARIA mal posé est pire que pas d'ARIA, parce qu'il ment aux technologies d'assistance. Enfin, teste vraiment : navigue ta page uniquement au clavier, lance un audit Lighthouse, essaie un lecteur d'écran (VoiceOver sur Mac, NVDA sur Windows) et zoome à 200 %. Ces quatre gestes rapides révèlent la plupart des problèmes avant tes utilisateur·ices.

Les bases à intégrer

HTML sémantique d'abord : un <button> est nativement accessible, un <div onclick> non
Contraste minimum 4.5:1 pour le texte courant (WCAG AA)
Focus toujours visible : ne jamais supprimer l'outline sans remplacement
Navigation clavier : Tab, Enter, Échap doivent fonctionner partout
Hiérarchie de titres cohérente : h1 → h2 → h3, pas de saut

Quelques attributs ARIA utiles

aria-label="..." : nom accessible si pas de texte visible (icône-bouton)
aria-describedby="id" : aide complémentaire (texte d'aide d'un input)
aria-current="page" : lien actif dans une nav
aria-hidden="true" : cacher du lecteur d'écran (icône décorative)

HTML d'abord, ARIA en dernier

Les attributs ARIA sont une réparation. Si tu peux exprimer la sémantique en HTML pur, fais-le. <nav> > <div role="navigation">. <button> > <div role="button">.

Tester son accessibilité

Naviguer ta page uniquement au clavier (Tab, Shift+Tab, Enter, Échap)
Lancer un audit Lighthouse (panneau Accessibility) dans les DevTools
Tester avec un lecteur d'écran (VoiceOver sur Mac, NVDA sur Windows)
Zoomer à 200 % et vérifier que tout reste utilisable