Analyse d'accessibilité web

Comment fonctionne cette vérification

Scanaris analyse le HTML que ta page sert, sans exécuter de JavaScript ni ouvrir de navigateur, et passe huit tests d'accessibilité qui se décident avec certitude sur le code. Trois sont de sévérité moyenne : que la balise <html> déclare la langue avec lang, que la <meta name="viewport"> existe, et qu'aucun champ de formulaire (input, select, textarea, hors champs cachés et boutons) ne manque d'étiquette accessible, c'est-à-dire qu'il ait un <label for>, soit dans un <label>, ou porte aria-label, aria-labelledby ou title. Les cinq autres sont de sévérité faible : images sans attribut alt (un alt="" vide est valable pour les décoratives ; ce qui échoue, c'est l'absence de l'attribut), liens avec href et boutons sans texte, sans aria-label et sans image avec alt à l'intérieur, attributs id répétés, éléments avec tabindex supérieur à zéro, et titres h1 à h6 vides. Chaque test échoué ouvre son propre constat avec le décompte.

Pourquoi c'est important

Environ 15 % de la population a un handicap, et bien plus de gens utilisent le web avec un lecteur d'écran, au clavier seul ou avec le zoom au maximum à certains moments. Pour eux, une image sans alt est un trou, un champ sans étiquette est une case dont on ne sait pas ce qu'elle attend et un bouton qui n'est qu'une icône est annoncé comme « bouton » sans plus. Au-delà de l'éthique, c'est la loi : la directive européenne sur l'accessibilité s'applique depuis juin 2025 à la plupart des services numériques des entreprises, et aux États-Unis les procès pour sites inaccessibles se comptent par milliers chaque année. Et c'est du SEO : le alt, la langue et la structure des titres sont exactement ce que Google lit.

Comment corriger

• Langue : <html lang="fr">. Dans Nuxt, ça se règle dans app.head.htmlAttrs ou le module i18n s'en charge ; dans Next.js, sur le <html> du layout racine ; dans WordPress, language_attributes() l'écrit dans le thème.
• Viewport : <meta name="viewport" content="width=device-width, initial-scale=1">. Sans maximum-scale=1 ni user-scalable=no, qui bloquent le zoom.
• Étiquettes de formulaire : un <label for="email"> pour chaque champ avec son id, ou le champ à l'intérieur du <label>. Si le design n'affiche pas d'étiquette visible, aria-label="Adresse e-mail". Le placeholder ne compte pas : il disparaît quand on tape.
• Images : alt descriptif sur les informatives (« Graphique des ventes du troisième trimestre »), alt="" sur les décoratives. Les composants d'image de Nuxt et Next.js exigent l'attribut.
• Liens et boutons icône : aria-label="Ouvrir le menu", ou un texte masqué visuellement avec une classe sr-only. Les icônes SVG en ligne portent aria-hidden="true".
• Ids dupliqués : viennent généralement de composants répétés avec l'id codé en dur. Dérive l'id d'une prop ou utilise useId().
• Tabindex positifs : passe-les à 0 et ordonne les éléments dans le HTML dans l'ordre où ils doivent être parcourus.
• Titres vides : s'ils servaient à la mise en page, remplace-les par un div ; s'ils contiennent une icône, donne-leur du texte.

Vérifie que c'est corrigé

curl -s https://tondomaine.com | grep -oE '<html[^>]*>|<meta name="viewport"[^>]*>'
curl -s https://tondomaine.com | grep -oE '<img[^>]*>' | grep -vc 'alt='

La première doit montrer lang et le viewport ; la seconde doit donner 0. Pour le reste, le panneau Lighthouse de Chrome (onglet Accessibilité) ou l'extension axe DevTools te listent chaque élément avec son sélecteur.

Questions fréquentes

Passer ces huit tests signifie-t-il que mon site est accessible ?

Non. Ce sont les huit qu'on peut vérifier avec certitude sans navigateur. Le contraste des couleurs, le focus visible, l'ordre de lecture réel et les composants construits en JavaScript demandent une revue avec des outils de navigateur et, pour quelque chose de sérieux, un audit humain. Les passer signifie en revanche que tu ne commets pas les erreurs les plus fréquentes et les plus faciles à éviter.

Mon appli est une SPA et le HTML initial est presque vide.

Alors la vérification voit peu, et Google aussi. C'est une raison de plus pour rendre côté serveur au moins le contenu principal ; contenu sans JavaScript l'explique.

Pourquoi le alt vide est-il correct et l'absence de alt non ?

Parce que alt="" dit au lecteur d'écran « saute cette image, elle est décorative », alors que sans attribut le lecteur lit le nom du fichier, qui ressemble souvent à IMG_4821.jpg. La structure des titres, qui touche à la navigation au lecteur d'écran, est aussi passée en revue par titres.