HTML sémantique & accessibilité

En React Native, presque tout est une View : le sens d'un écran vit dans ta tête et dans le nom de tes composants. Le web te donne un vocabulaire riche — header, nav, main, button, label — et il récompense ceux qui l'emploient : lecteurs d'écran qui comprennent la page, clavier qui marche tout seul, moteurs de recherche qui s'y retrouvent, évaluateurs de tests techniques qui hochent la tête. Ce module t'apprend à choisir la bonne balise, et à voir ta page comme la « voit » une personne qui ne la voit pas.

Le HTML porte du sens, pas juste des boîtes

Depuis le module sur le navigateur, tu sais que ton HTML devient un arbre — le DOM — que le navigateur peint. Mais une fois le CSS appliqué, toutes les balises peuvent se ressembler : un <div> stylé en bouton a l'air d'un bouton, un <span> en gros caractères a l'air d'un titre. Alors pourquoi choisir la « bonne » balise, si le pixel final est identique ? Parce que le pixel n'est pas le seul consommateur de ta page. Ton HTML est lu par quatre publics, dont trois ne voient rien :

• Les technologies d'assistance — lecteurs d'écran (VoiceOver, TalkBack, NVDA), plages braille, commandes vocales. Elles ne lisent pas l'écran, elles lisent la structure : une balise sémantique leur dit quoi annoncer.
• Les moteurs de recherche — Google lit ton HTML pour comprendre le sujet de la page ; un <h1> pèse plus lourd qu'un <span> en gras. C'est un pan entier du SEO (Search Engine Optimization).
• Les autres développeurs, toi dans six mois inclus — un fichier fait de <nav>, <main> et <article> se lit comme un plan ; quarante <div> imbriqués se lisent comme un labyrinthe.
• Le navigateur lui-même — il attache des comportements gratuits aux bonnes balises : un <a> s'ouvre dans un nouvel onglet au clic-molette, un <form> se soumet avec Entrée.

Deux familles de balises cohabitent. Les neutres — <div> (boîte de bloc) et <span> (boîte en ligne) — n'ont aucun sens et servent uniquement à regrouper pour la mise en page ; c'est très bien comme ça. Les sémantiques déclarent un rôle : <header>, <nav>, <main> (le contenu principal, unique), <section> (une section thématique), <article> (un contenu autonome, qui aurait du sens seul : un billet, une carte de service), <aside> (périphérique), <footer>. La règle de décision : s'il existe une balise qui décrit ce que tu fais, utilise-la ; sinon seulement, prends une div.

La page bien structurée : titres, listes, landmarks

Trois piliers. Le premier : la hiérarchie de titres. Les balises <h1> à <h6> ne sont pas « six tailles de texte » : ce sont les niveaux d'un plan. Le <h1> est le titre de la page (unique), les <h2> ses grandes parties, les <h3> les sous-parties. Deux règles : un seul h1, et pas de saut de niveau (on ne passe pas de h1 à h4 parce que « la taille du h4 était jolie » — la taille, c'est le CSS). C'est capital parce que les utilisateurs de lecteurs d'écran naviguent par titres : une commande leur liste tous les titres comme une table des matières, et ils sautent à la section voulue. Une hiérarchie cassée, c'est une table des matières mensongère.

Deuxième pilier : les listes, <ul> (non ordonnée), <ol> (ordonnée, quand l'ordre compte) et leurs <li>. Un lecteur d'écran annonce « liste, 4 éléments » avant de la lire : l'utilisateur sait combien d'items l'attendent et peut sauter le bloc entier. Trois <div> empilés ne disent rien de tout ça.

Troisième pilier : les landmarks (« points de repère »), le nom que les technologies d'assistance donnent aux grandes régions déclarées par <header>, <nav>, <main>, <aside>, <footer>. Comme pour les titres, une commande « liste-moi les régions » permet de sauter au contenu principal sans se retaper le menu à chaque page — l'équivalent, pour l'oreille, de ce que tes yeux font en une demi-seconde quand ils scannent une page.

<header>
  <img src="/logo.svg" alt="Clinique RendezVous" />
  <nav aria-label="Navigation principale">
    <ul>
      <li><a href="/">Accueil</a></li>
      <li><a href="/services">Services</a></li>
      <li><a href="/rendez-vous">Prendre rendez-vous</a></li>
    </ul>
  </nav>
</header>

<main>
  <h1>Prendre rendez-vous</h1>

  <section>
    <h2>Choisissez un service</h2>
    <ul>  <!-- une carte par service : liste, pas des div -->
      <li><article><h3>Consultation générale</h3> ...</article></li>
      <li><article><h3>Physiothérapie</h3> ...</article></li>
    </ul>
  </section>

  <section>
    <h2>Vos coordonnées</h2>
    <form> ... </form>  <!-- détaillé plus bas, et aux modules Formulaires -->
  </section>
</main>

<footer>
  <p>© Clinique RendezVous — 514 555-0199</p>
</footer>

<main>
  <h1>Prendre rendez-vous</h1>

  <h3>Choisissez un service</h3>
  <div class="titre-service">Physiothérapie</div>
  <p>Séance de 45 minutes.</p>

  <h2>Vos coordonnées</h2>
</main>

Les éléments interactifs natifs : le navigateur travaille pour toi

C'est ici que la sémantique cesse d'être une affaire de bon goût pour devenir une affaire de fonctionnalités gratuites. Compare un vrai <button> à un <div onClick=...> stylé pareil : visuellement identiques, mais le vrai bouton reçoit du navigateur, sans une ligne de code :

• Le focus clavier : Tab s'arrête dessus. Le div est invisible pour le clavier — un utilisateur sans souris ne peut jamais l'atteindre.
• L'activation clavier : Entrée et Espace déclenchent le clic. Sur le div, ces touches ne font rien.
• Le rôle : le lecteur d'écran annonce « Confirmer, bouton ». Le div passe pour du texte inerte — l'utilisateur ignore qu'on peut agir dessus.
• L'état désactivé : disabled retire le bouton du parcours clavier et l'annonce comme grisé — encore un comportement à recoder à la main sur un div.

Deuxième distinction, très demandée en entrevue : <a> vs <button>. La règle tient en quatre mots : naviguer ou agir ? Un lien (<a href="...">) emmène quelque part ; un bouton fait quelque chose ici (soumettre, ouvrir une fenêtre). Ce n'est pas cosmétique : un lien s'ouvre dans un nouvel onglet, se copie, se met en favori, et le lecteur d'écran annonce « lien » ou « bouton », ce dont l'utilisateur déduit ce qui va se passer. Un <a> sans href qui sert de bouton trahit cette attente — et l'inverse aussi.

Enfin, les éléments de formulaire natifs : <input> et ses types (type="email", "tel", "date", "number"…), <select>, <textarea>. Le bon type change le clavier affiché sur mobile (le @ pour un email, le pavé numérique pour un téléphone), active une validation native et déclenche l'autocomplétion. Les modules « Formulaires 1 — contrôlé ou non » et « Formulaires 2 — validation & erreurs » y consacrent deux chapitres entiers.

<!-- Version A : la « soupe de div » -->
<div class="card">
  <div class="card-title">Physiothérapie</div>
  <div class="card-text">Séance de 45 minutes.</div>
  <div class="btn" onclick="choisir('physio')">Choisir</div>
</div>

<!-- Version B : sémantique -->
<article class="card">
  <h3>Physiothérapie</h3>
  <p>Séance de 45 minutes.</p>
  <button type="button" onclick="choisir('physio')">Choisir</button>
</article>

{/* Ouvre un panneau de créneaux, sans quitter la page */}
<a onClick={() => setPanneauOuvert(true)}>Voir les créneaux</a>

{/* Emmène sur la page /services */}
<button onClick={() => router.push('/services')}>Nos services</button>

L'arbre d'accessibilité : ce que la machine « voit »

Tu connais le DOM, l'arbre que le navigateur construit à partir de ton HTML. Il en construit un deuxième, dérivé du premier : l'arbre d'accessibilité (accessibility tree), la version « résumée pour les technologies d'assistance » de ta page. Le décoratif en est élagué, et chaque élément restant y est décrit par trois informations :

• Le rôle : ce que c'est — bouton, lien, titre de niveau 2, champ de saisie, région de navigation. Il découle de la balise : voilà pourquoi la balise compte.
• Le nom accessible : comment on l'appelle — le texte du bouton, le <label> du champ, l'alt d'une image, ou un aria-label. Un élément sans nom accessible est annoncé « bouton »… et c'est tout.
• L'état : coché ou non, déplié ou replié, désactivé, invalide…

Le lecteur d'écran ne lit ni tes pixels ni ton CSS : il parcourt cet arbre et le met en voix. Sur la page RendezVous, VoiceOver dira à peu près : « Clinique RendezVous, image. Navigation principale, région, liste, 3 éléments. Accueil, lien. […] Contenu principal, région. Prendre rendez-vous, titre de niveau 1. Choisissez un service, titre de niveau 2. Liste, 2 éléments… ». Chaque mot vient d'une balise que tu as choisie — sans le alt="Clinique RendezVous", l'utilisateur entendrait « logo.svg, image ». Tu peux voir cet arbre toi-même : l'onglet Accessibility des DevTools montre le rôle, le nom et les états de chaque élément, sans installer de lecteur d'écran.

label + input : le duo à connaître par cœur

S'il ne fallait retenir qu'un patron de ce module, ce serait celui-ci. Un champ nu — <input type="email" /> avec un texte posé à côté — est anonyme : visuellement tout va bien, mais dans l'arbre d'accessibilité il n'a pas de nom, et le lecteur d'écran annonce « champ de saisie, modifiable » sans dire quoi saisir. La solution est le couple label + input reliés par l'identifiant : le <label> porte un attribut for (en JSX htmlFor, car for est un mot réservé de JavaScript) dont la valeur est exactement l'id du champ.

Ce lien déclenche trois effets gratuits. Un : le texte du label devient le nom accessible du champ (« Courriel, champ de saisie »). Deux : cliquer le label focus le champ — anecdotique en apparence, énorme sur mobile où la cible tactile s'agrandit d'autant, et pour les cases à cocher bien plus faciles à atteindre par leur étiquette. Trois : les outils d'audit (Lighthouse, axe) comme les évaluateurs humains vérifient ce lien en premier — c'est le test décisif du « formulaire fait proprement ».

<label htmlFor="email">Courriel</label>
<input
  id="email"                      // le même identifiant des deux côtés : c'est LE lien
  type="email"                    // bon clavier mobile + validation native
  aria-describedby="email-err"    // « ma description est là-bas » (l'erreur)
  aria-invalid={hasError}         // état invalide annoncé au lecteur d'écran
/>
<p id="email-err" role="alert">Adresse email invalide.</p>

<label for="telephone">Téléphone</label>
<input id="phone" type="text" placeholder="514 555-0199" />

ARIA : puissant, et dangereux si on en abuse

ARIA (Accessible Rich Internet Applications) est un jeu d'attributs — role, aria-* — qui enrichissent à la main l'arbre d'accessibilité quand le HTML natif ne suffit pas. Sa première règle est un paradoxe écrit noir sur blanc dans la spécification : la première règle d'ARIA est de ne pas utiliser ARIA quand un élément natif fait l'affaire. Raison : ARIA ne fait que déclarer, jamais implémenter. Un élément qui promet un comportement sans le tenir est pire qu'un élément muet — l'utilisateur essaie, échoue, et ne comprend pas pourquoi.

Cela dit, ARIA a quatre usages parfaitement légitimes, et tu n'as pas besoin d'en connaître plus pour l'instant :

• aria-label : donner un nom accessible quand aucun texte visible ne peut le faire. Cas d'école, le bouton-icône : <button aria-label="Fermer">✕</button> — sans lui, le lecteur d'écran annonce « multiplication, bouton », ou pire.
• aria-describedby : relier un élément à sa description (le nom dit « quoi », la description dit « comment » ou « pourquoi c'est en erreur »). C'est le pont entre un champ et son message d'aide ou d'erreur : l'id du message dans l'attribut, et le lecteur d'écran le lit à la suite du champ.
• aria-invalid : marquer un champ comme invalide. Le rouge du CSS est invisible pour un lecteur d'écran ; aria-invalid="true" rend l'erreur audible (« Courriel, champ de saisie, données invalides »).
• aria-live : déclarer une zone dont les changements doivent être annoncés spontanément. Par défaut, un lecteur d'écran ne lit que là où l'utilisateur navigue ; un message apparu ailleurs (« Rendez-vous confirmé ! ») passe inaperçu. Une région aria-live="polite" est annoncée dès qu'elle change ; role="alert" (vu dans la formule) en est le raccourci assertif, adapté aux erreurs.

<label htmlFor="email">Courriel</label>
<input
  id="email"
  type="email"
  aria-invalid={true}               // l'état « invalide » devient audible
  aria-describedby="email-err"      // « mon message d'erreur, c'est lui »
/>
{/* role="alert" : le message est annoncé DÈS son apparition */}
<p id="email-err" role="alert">
  Entre une adresse valide, ex. nom@exemple.com
</p>

Le clavier et le focus : l'accessibilité qui se teste en 30 secondes

Beaucoup de gens naviguent sans souris ni écran tactile : utilisateurs de lecteurs d'écran, personnes à mobilité réduite, utilisateurs avancés pressés… et toi-même, le jour où tu remplis un long formulaire. Le contrat du web au clavier est simple : Tab passe d'un élément interactif au suivant, Maj+Tab recule, Entrée active liens et boutons, Espace active boutons et cases à cocher, les flèches circulent dans un <select> ou un groupe de radios. Tout cela vient des éléments natifs ; l'élément actuellement visé est dit focusé, et il n'y en a qu'un à la fois.

L'ordre du focus, d'abord : Tab suit l'ordre du DOM — celui de ton HTML, pas l'ordre visuel du CSS. Si ton CSS remonte un bouton en haut de page alors qu'il est en bas du HTML, le clavier y arrivera en dernier : déroutant. Écris donc le HTML dans l'ordre logique de lecture et laisse Tab suivre. (L'attribut tabindex permet d'intervenir ; retiens surtout que forcer un ordre avec des tabindex positifs est une mauvaise idée célèbre. Et tabindex="0" est ce qu'il faudrait ajouter — avec un role, un onKeyDown pour Entrée et Espace, un style de focus et l'état désactivé — pour rattraper un div cliquable : cinq choses à coder, cinq occasions de se tromper.)

La visibilité du focus, ensuite : l'anneau (souvent bleu) autour de l'élément focusé n'est pas une verrue esthétique, c'est le curseur de l'utilisateur clavier. Le supprimer en CSS (outline: none, classique des années 2010) rend la navigation clavier littéralement aveugle. Le CSS moderne offre la nuance : :focus-visible, une pseudo-classe qui ne matche que quand le navigateur juge l'indicateur utile — au clavier, mais pas après un clic de souris. Tu styles :focus-visible et tout le monde est content.

D'où le test express, sur ta page comme sur celle d'un test technique : pose la souris et fais tout au clavier. Si tu bloques quelque part, tu as trouvé un bug d'accessibilité.

function BookButton({ onReserver }) {
  return (
    <div
      className="btn-primaire"
      onClick={onReserver}
      style={{ outline: 'none' }}
    >
      <img src="/calendrier.svg" />
      Réserver
    </div>
  );
}

<div
  className="btn-primaire"
  role="button"
  tabIndex={0}
  onClick={onReserver}
>
  Réserver
</div>

L'accessibilité en entrevue et en test technique

Parlons stratégie. L'accessibilité (abrégée a11y — un « a », onze lettres, un « y ») est l'un des critères les plus discriminants pour un candidat junior, précisément parce que presque aucun junior ne la maîtrise. Les correcteurs ont des grilles, et « accessibilité » y figure noir sur blanc : un vrai test de stage, examiné pour préparer ce guide, listait « a11y » parmi les manques types des candidatures refusées, aux côtés de la gestion d'erreurs et des états de chargement. Or un formulaire dont chaque champ a son label relié et une hiérarchie de titres propre, ça se voit en trente secondes de lecture — et c'est du HTML gratuit : aucune bibliothèque, aucune heure de plus, juste les bonnes balises dès le départ.

Les cinq réflexes à appliquer dans tout test technique (et à citer en entrevue si on te demande comment tu abordes l'accessibilité) :

1. La bonne balise pour le bon rôle : button pour agir, a pour naviguer, les landmarks pour la structure, un seul h1, pas de saut de titre.
2. Chaque champ a son label relié par htmlFor/id, et le bon type. Jamais un placeholder en guise d'étiquette.
3. Chaque image a un alt : descriptif si elle informe, vide (alt="") si elle décore.
4. Tout marche au clavier : parcours Tab logique, focus visible (:focus-visible), jamais d'outline: none sans remplacement.
5. Les erreurs sont audibles : aria-describedby + aria-invalid + role="alert" — la formule de ce module, exactement.