Rapport client illustratif · 17 octobre 2026

Site vitrine d’agence: évaluation d’accessibilité

Northline Studio · northline.example

Démonstration fictive. Clients, domaines, résultats et preuves sont illustratifs. Ces rapports montrent la structure du livrable, pas des analyses réelles ni des preuves de résultats du produit.

Choisir une offre

Synthèse

Clarifiez d’abord le formulaire et la navigation, nécessaires aux prospects pour découvrir les services et vous contacter. Examinez ensuite la description de l’image de l’étude de cas.

Pages examinées
4
Types de résultats
3
Critique
3
Modéré
0

Les chiffres indiquent les types de résultats de cet exemple, pas les éléments touchés. La gravité indique une priorité, pas un verdict de conformité.

Portée et méthode

Parcours client : Discover services → read a case study → send an inquiry.

Pages d’exemple : //services/work/contact

Méthode : contrôles axe automatisés sur chaque page publique chargée. L’exemple ne couvre pas les espaces connectés, tous les états, le clavier, les lecteurs d’écran ou une évaluation WCAG complète. Les résultats nécessitent confirmation humaine.

Ce rapport présente des résultats automatisés d’accessibilité. Il n’établit pas la conformité légale ; une évaluation manuelle reste nécessaire.

Accessibilité : règles et champ d’application

Résultats prioritaires

PrioritéRésultat Page / règleÉtape suivante
CriticalEmail field has no accessible label/contact
label
Connect a visible label to the email field.
CriticalMenu button has no accessible name/
button-name
Name the menu control and expose its expanded state.
CriticalCase-study image is missing an alternative/work
image-alt
Describe the project image or mark it decorative after reviewing its purpose.

Preuves et corrections

Deux résultats sont détaillés pour illustrer la transmission à l’équipe de réalisation.

Résultat 1 · Critical

Email field has no accessible label

Élément concerné : #contact-form input[type="email"] sur /contact

Pourquoi c’est important : A person using a screen reader needs a reliable name for the field. An unnamed input gives no reliable indication of the information expected.

1 · Schéma de preuve illustratif. Fragment d’interface reconstitué, pas une capture ni une analyse réelle. Illustrative markup contains an email input with no associated label, aria-label, or aria-labelledby.

Correction proposée

Add a visible Work email label, connect it with for/id, and preserve the expected email input type and autofill hint.

Avant · HTML illustratif

<input type="email">

Après · HTML proposé

<label for="email">Work email</label>
<input id="email" name="email" type="email"
  autocomplete="email" required>

Vérifier la correction : Re-run the label rule. Tab into the field and confirm that a screen reader announces Work email, its input type, and required state. Submit an invalid email and review the error message separately.

Résultat 2 · Critical

Menu button has no accessible name

Élément concerné : header button.menu-toggle sur /

Pourquoi c’est important : An icon alone does not tell a screen reader user what the button does. The expanded state helps people understand whether navigation is open.

1 · Schéma de preuve illustratif. Fragment d’interface reconstitué, pas une capture ni une analyse réelle. Illustrative markup contains only an SVG inside a button; the SVG is decorative and supplies no accessible name.

Correction proposée

Give the button an accessible name. Update aria-expanded when the menu opens or closes and connect aria-controls to the navigation container.

Avant · HTML illustratif

<button class="menu-toggle">
  <svg aria-hidden="true">…</svg>
</button>

Après · HTML proposé

<button class="menu-toggle" aria-label="Menu"
  aria-controls="site-nav" aria-expanded="false">
  <svg aria-hidden="true">…</svg>
</button>

Vérifier la correction : Re-run the button-name rule, then open and close the menu with Enter and Space. Confirm the state is announced, links are reachable, and focus remains predictable when the menu closes.

Transmission recommandée

  1. Confirmez les résultats dans l’interface réelle et convenez des responsables et de la portée.
  2. Résolvez d’abord les résultats critiques ; examinez chaque changement dans son contexte.
  3. Testez le parcours avec un clavier et des technologies d’assistance.
  4. Relancez les mêmes pages, notez les vérifications manuelles restantes et partagez les changements.
v0.1.55cb04db
Exemple de rapport · AccessiPulse