Contrôle d’accessibilité
Voyez ce qu’un lecteur d’écran trouvera dans votre PDF — et ce qui lui manquera.
Vos fichiers ne quittent jamais votre appareilDéposez votre PDF ici
Rien n’est modifié : ce contrôle se contente de lire le document.
Comment contrôler l’accessibilité d’un PDF, étape par étape
Ce contrôle en onze points lit ce qu’un lecteur d’écran peut réellement exploiter dans un PDF — titre, langue, structure, contraste — sans jamais modifier le fichier.
Déposez le PDF à contrôler
Glissez le fichier ou cliquez pour le choisir. Le contrôle s’exécute aussitôt, entièrement dans votre navigateur.
Lisez l’état de chaque point
Titre, langue déclarée, texte réel ou image scannée, balisage, images avec texte de remplacement, titres hiérarchisés, signets, champs de formulaire, contraste estimé, identifiant PDF/UA et restrictions d’accès : chaque point est marqué conforme, à améliorer, bloquant ou non vérifié.
Suivez les liens « Corriger avec » quand ils existent
Une page sans texte se rattrape par la reconnaissance de caractères, des restrictions se lèvent avec l’outil de déverrouillage — mais le balisage de structure et les textes de remplacement se font dans le logiciel qui a produit le document, pas dans VellumPDF.
Téléchargez le rapport
Le bouton « Télécharger le rapport » produit un document reprenant les onze points, la date du contrôle et le nom du fichier examiné.
Ce contrôle ne remplace pas une conformité PDF/UA (ISO 14289-1) complète : il ne vérifie ni l’ordre de lecture réel, ni les tableaux et listes balisés avec leurs en-têtes, ni la pertinence des textes de remplacement — seulement leur présence. Sur un fichier chiffré, les points concernés restent « non vérifiés » plutôt que déclarés conformes.
Questions fréquentes
Ce contrôle remplace-t-il une validation PDF/UA complète ?
Non, et le rapport le dit lui-même. Aucune bibliothèque libre ne valide la norme PDF/UA (ISO 14289-1) dans un navigateur : veraPDF est écrit en Java, les moteurs en WebAssembly sont sous licence payante, et les vérificateurs gratuits en ligne reçoivent votre fichier sur leur serveur. VellumPDF contrôle donc ce qui se lit sans ambiguïté dans le fichier, et termine par la liste de ce qu’il ne vérifie pas : la conformité PDF/UA complète, l’ordre de lecture réel, les tableaux et les listes balisés, et la qualité des textes de remplacement.
Que vérifie exactement le rapport ?
Onze points. Le titre du document (dans les informations et dans le XMP) et la demande de l’afficher dans la barre du lecteur ; la langue déclarée et sa validité ; la présence de texte réel page par page, par opposition à l’image d’un scan ; le balisage du document (MarkInfo /Marked et arbre de structure) ; les images balisées /Figure et leur texte de remplacement ; les titres hiérarchisés H1 à H6 ; les signets au-delà de vingt pages ; les info-bulles des champs de formulaire ; une estimation du contraste ; l’identifiant PDF/UA du XMP ; et les restrictions qui interdiraient l’extraction du texte à des fins d’accessibilité. Ces points suivent les clauses 6.2, 7.1, 7.2 et 7.3 du profil de validation PDF/UA-1 de veraPDF, relevé le 17.09.2026.
Pourquoi le contraste est-il annoncé comme une estimation ?
Parce que c’en est une. VellumPDF dessine les dix premières pages à définition réduite (environ 100 points par pouce), regroupe les couleurs, retient la plus fréquente comme fond, écarte les teintes intermédiaires bien moins peuplées qu’une encre plus sombre — ce sont les pixels de lissage des bords de lettres —, puis calcule le rapport de contraste WCAG entre le fond et chaque couleur d’encre restante. Le seuil retenu est 4,5:1, celui du critère 1.4.3 de WCAG 2.1 au niveau AA (w3.org/TR/WCAG21, consulté le 17.09.2026). Cette mesure ne connaît pas la taille des caractères — WCAG n’exige que 3:1 au-delà de 18 points —, ne distingue pas un texte posé sur une photographie, laisse passer une ligne isolée de gris clair noyée dans un long texte noir, et ne regarde pas au-delà de la dixième page.
VellumPDF peut-il corriger ce que le rapport signale ?
En partie seulement, et il le dit point par point. Une page sans texte se rattrape avec la reconnaissance de caractères ; un titre manquant s’écrit avec l’outil Métadonnées ; des restrictions de chiffrement se lèvent avec l’outil Déverrouiller. En revanche VellumPDF ne sait pas ajouter les balises de structure ni les textes de remplacement des images : cela demande de comprendre le sens du document, et se fait dans le logiciel qui l’a produit. L’outil Métadonnées de VellumPDF n’écrit pas non plus la langue du document ni la demande d’afficher le titre, deux réglages qui vivent ailleurs dans le fichier.
Qui est tenu de rendre ses PDF accessibles ?
En Suisse, la loi sur l’égalité pour les personnes handicapées (LHand, RS 151.3, en vigueur depuis 2004) impose aux autorités de rendre leurs prestations numériques utilisables par tous, et l’administration fédérale applique pour cela le standard eCH-0059, dont la version 3.0 a été approuvée le 25.06.2020 et reprend WCAG 2.1 au niveau AA. Dans l’Union européenne, l’European Accessibility Act (directive (UE) 2019/882) s’applique depuis le 28.06.2025 à de nombreux produits et services privés. Sources relevées le 17.09.2026 : ebgb.admin.ch, ech.ch et le centre AccessibleEU de la Commission européenne.