Déclaration d’accessibilité
Dernière mise à jour : 23 août 2026
Cette traduction est fournie à titre indicatif. Seule la version anglaise de cette page fait foi.
1. Mon engagement
Je souhaite que ce site soit utilisable par tout le monde, y compris par les personnes qui naviguent au clavier, avec un lecteur d’écran, avec un agrandissement, ou avec un réglage de mouvement réduit ou de contraste élevé. L’accessibilité est traitée ici comme partie intégrante de la construction, et non comme une vérification finale : plusieurs des mesures ci-dessous sont garanties par des tests automatisés qui font échouer la compilation en cas de régression.
2. État de conformité
Ce site vise la conformité aux Règles pour l’accessibilité des contenus web (WCAG) 2.2 au niveau AA. J’estime qu’il est substantiellement conforme, c’est-à-dire qu’il satisfait aux critères de succès de niveau AA au mieux de ma connaissance et de mes tests.
Je ne revendique délibérément pas une conformité totale. Aucun audit d’accessibilité indépendant n’a été réalisé, et il n’existe pas de rapport d’évaluation WCAG-EM formel pour ce site. C’est une limite portant sur les preuves qui étayent cette affirmation, non un défaut connu — lorsque je constate un défaut, il figure à la section 5.
3. Ce qui est en place
Clavier et focus
- Un lien d’évitement est le premier élément focusable de chaque page portant la navigation du site, et il déplace le focus vers le contenu principal plutôt que de s’y faire simplement défiler.
- Chaque élément interactif affiche un indicateur de focus visible. La règle qui le dessine ne peut être désactivée par aucune classe utilitaire, ce qu’un test garantit.
- Le menu mobile est un piège à focus : le focus y entre à l’ouverture, y circule avec Tab, se ferme avec Échap et revient au bouton qui l’a ouvert.
-
Aucun élément ne prend un
tabindexpositif, de sorte que l’ordre de tabulation suit la page.
Structure et lecteurs d’écran
-
Exactement un point de repère
mainpar page et — partout où l’en-tête et le pied de page du site sont présents — unbanneret uncontentinfo, ainsi que des points de repère de navigation nommés. -
Exactement un
h1par page, avec des titres imbriqués dans l’ordre en dessous et sans niveau sauté. - Chaque image porte un texte alternatif, et les éléments graphiques décoratifs sont masqués aux technologies d’assistance plutôt que dotés de descriptions de remplissage.
- Lorsqu’une icône porte le sens d’une commande, celle-ci possède un nom textuel — l’intitulé visible commence toujours ce nom, afin que la commande vocale puisse l’adresser par ce qui est écrit.
- La langue de la page est déclarée, et chaque page a un titre unique et descriptif.
Couleur, contraste et typographie
- Les couleurs de texte et d’interface sont dérivées à la compilation et vérifiées par rapport à leurs propres arrière-plans : le texte courant est tenu à au moins 4,5:1, le texte principal à 7:1, et tout aplat de bouton est assombri jusqu’à ce que son intitulé dépasse 4,5:1.
- Aucun texte du site n’est rendu en dessous de 12 px. C’est un plancher, garanti par un test.
-
La couleur n’est jamais le seul vecteur d’une information : les états sélectionnés portent
aussi un intitulé, une forme ou une valeur
aria-current. - Un thème clair et un thème sombre sont disponibles. Le site s’ouvre en sombre plutôt que de lire votre réglage système, et retient celui que vous choisissez avec le bouton de l’en-tête.
Mouvement, zoom et pointeur
- Le mouvement réduit est respecté. Si votre système le demande, les animations d’entrée, les révélations au défilement et les transitions de vue sont supprimées.
- Le contraste augmenté et le mode contraste élevé de Windows sont pris en charge : le texte en dégradé revient à une couleur unie, et les états signalés uniquement par un aplat reçoivent une bordure aux couleurs du système.
- Le zoom n’est pas bloqué. La page peut être agrandie à 500 %, et à la largeur de 320 px que spécifie le critère WCAG 1.4.10 « Redistribution », elle s’affiche sur une seule colonne sans défilement horizontal. Chaque largeur entre 320 px et 1920 px est vérifiée, et pas seulement les points de rupture nommés.
- Les commandes interactives présentent une cible d’au moins 44 × 44 px, ce qui dépasse le minimum WCAG 2.2 de 24 × 24 px. Lorsqu’une commande est dessinée plus petite, sa zone cliquable est agrandie derrière elle plutôt que laissée petite. La seule exception est un lien au sein d’une phrase, qui relève de l’exemption « en ligne » du critère WCAG 2.5.8 — y imposer une hauteur fixe casserait l’interlignage du paragraphe qui l’entoure.
Formulaires
-
Chaque champ possède un nom associé par programmation. Lorsqu’un formulaire comporte plus d’un
champ — le formulaire de contact et le panneau de préférences de cookies —, ce nom est un
<label>visible. Les commandes à champ unique (inscription à la newsletter, recherche dans les listes, zone de commentaire, invite de connexion par e-mail) tirent leur nom d’unaria-label, le titre, l’icône ou le bouton voisin portant le même sens à l’écran. - Les erreurs sont décrites en toutes lettres à côté du champ concerné, et non par la seule couleur, et lui sont liées afin qu’un lecteur d’écran annonce le message lorsque le champ reçoit le focus.
- Soumettre un formulaire comportant un champ invalide déplace le focus vers ce champ : le problème vient à vous, et non l’inverse.
- Les champs de texte s’affichent à 16 px sur les appareils tactiles, afin que les activer ne déclenche pas un zoom iOS que vous ne pouvez pas annuler.
4. Comment cela a été évalué
Par auto-évaluation, à l’aide de vérifications automatisées et manuelles :
- Des tests automatisés dans la suite de tests du projet, qui font échouer la compilation en cas de régression des indicateurs de focus, de la taille minimale du texte, de la taille des cibles, de la structure des points de repère, des textes alternatifs et de l’ordre des titres.
- Un contraste mesuré à partir des pixels rendus, en composant les couches translucides plutôt qu’en lisant les couleurs déclarées.
- Un balayage de fenêtre d’affichage de 320 px à 1920 px vérifiant, à chaque pas intermédiaire, le débordement horizontal, le chevauchement d’éléments et le texte tronqué — pas seulement aux points de rupture nommés.
- Des parcours manuels au clavier et des vérifications sur plusieurs moteurs : Chromium, Firefox et WebKit.
5. Limites connues
- Pas d’audit indépendant. Tout ce qui précède est auto-évalué. Un audit mené par une personne autre que l’auteur constituerait une base plus solide pour la déclaration de conformité de la section 2.
- Tests limités avec les technologies d’assistance. La structure et le comportement sont vérifiés via l’arbre d’accessibilité et au clavier, mais le site n’a pas été testé de bout en bout avec tous les principaux lecteurs d’écran.
- Contenus tiers. La prise de rendez-vous est assurée par un service de réservation externe, sur son propre domaine. Je ne maîtrise pas son accessibilité. Si cela constitue un obstacle pour vous, utilisez plutôt l’un des moyens de contact de la section 6 — un appel peut toujours être organisé par e-mail.
- Médias intégrés. Aucune vidéo n’est publiée sur ce site aujourd’hui. La vidéo de présentation annoncée sur la page « À propos » n’est pas encore enregistrée ; lorsqu’elle le sera, les critères WCAG 1.2.2 et 1.2.3 exigeront des sous-titres et une transcription pour le niveau de conformité revendiqué ci-dessus.
6. Retours et comment me joindre
Si vous rencontrez un obstacle sur ce site, dites-le-moi — c’est le moyen le plus rapide de le faire corriger, et vos signalements sont les bienvenus même si vous n’êtes pas certain que le problème vienne de mon côté.
- Écrivez à contact@mhsaeed.com — indiquez « Accessibilité » en objet si vous souhaitez que ce soit traité en priorité.
- Ou utilisez le formulaire de contact.
Je réponds sous 24 heures, le même engagement que celui de la page de contact. Merci de décrire la page, ce que vous cherchiez à faire, ainsi que le navigateur ou la technologie d’assistance que vous utilisiez, si vous êtes à l’aise de le partager — cela rend le problème bien plus rapide à reproduire.