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.
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. Vellum 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 ?
Dix 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. Vellum 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.
Vellum 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 Vellum 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 Vellum 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.