Accessibilité des PDF en C# : Créer, convertir et valider des documents PDF/UA

Le point de basculement juridique

Trois évolutions réglementaires ont convergé pour rendre la conformité aux normes PDF/UA urgente.

Ce ne sont pas des risques théoriques. Les poursuites judiciaires liées à l'accessibilité ont augmenté d'année en année, et les tribunaux ont constamment statué que les documents numériques relevaient du champ d'application du droit de la discrimination fondée sur le handicap. Les organisations qui considèrent l'accessibilité comme une préoccupation future se retrouvent de plus en plus souvent à devoir se défendre contre des plaintes, des conclusions d'audits et des litiges concernant des documents produits par leurs logiciels il y a des mois, voire des années.

L'article 508 de la loi sur la réadaptation a exigé que les États-Unis Les agences fédérales et leurs sous-traitants doivent produire depuis des années des technologies de l'information électronique accessibles. Les fichiers PDF sont explicitement pris en compte. Si votre logiciel génère des documents utilisés par ou pour le compte d'une agence fédérale, ces documents doivent être accessibles. Le ministère de la Justice enquête sur les plaintes et engage des poursuites contre les organisations non conformes.

Le titre II de l'ADA étend les obligations d'accessibilité aux gouvernements des États et aux administrations locales. La règle finale du ministère de la Justice, publiée en 2024, fixait les délais de mise en conformité à avril 2026 pour les entités comptant 50 000 habitants ou plus et à avril 2027 pour les entités plus petites. Le champ d'application est vaste : tout PDF publié sur un site web gouvernemental, distribué par courriel ou généré par une application destinée aux citoyens doit respecter le niveau AA des WCAG 2.1. Cela inclut les ordres du jour des réunions, les documents budgétaires, les demandes de permis, les dossiers judiciaires, les cartes de zonage et les procès-verbaux du conseil, parmi de nombreux autres types de documents.

La loi européenne sur l'accessibilité (EAA) est entrée en vigueur en juin 2025 et exige que les produits et services vendus dans l'UE répondent aux exigences d'accessibilité. Pour les éditeurs de logiciels qui desservent des clients de l'UE, les documents produits par vos applications doivent être accessibles. Cela ne se limite pas au gouvernement ; Elle s'applique aux produits et services du secteur privé dans un large éventail de catégories.

Ce que PDF/UA exige réellement

La norme PDF/UA (ISO 14289) définit les exigences techniques qu'un PDF doit satisfaire pour que les technologies d'assistance puissent le traiter de manière fiable. Un document conforme doit comporter :

Une structure de balisage complète. Chaque élément de contenu significatif doit être représenté dans un arbre de structure logique utilisant des balises PDF standard : <h1> à <h6> pour les en-têtes, <p> pour les paragraphes, <Table> pour les tableaux de données, <Figure> pour les images, et <l> pour les listes. Tout contenu purement décoratif doit être signalé comme un artefact afin que les lecteurs d'écran puissent l'ignorer.

Un ordre de lecture correct. L'arborescence des balises doit refléter l'ordre logique de lecture du contenu, et non l'ordre visuel de son apparition sur la page. Pour les mises en page à plusieurs colonnes ou les documents avec barres latérales, cette distinction est très importante.

Texte alternatif pour le contenu non textuel. Chaque image, graphique, et diagramme transmettant des informations doit avoir un texte alternatif attaché à sa balise <Figure>. Les images décoratives doivent être signalées comme des objets décoratifs.

Métadonnées correctes. Le document doit déclarer sa langue naturelle (par exemple, " en " pour l'anglais), avoir un titre pertinent et inclure l'identifiant PDF/UA dans ses métadonnées XMP.

Polices incorporées avec correspondance Unicode. Toutes les polices doivent être incorporées et les correspondances de caractères Unicode (ToUnicode CMap) doivent être présentes pour que le texte puisse être extrait et lu à voix haute avec précision.

PDF/UA vs WCAG : Comment les deux normes fonctionnent ensemble

Les développeurs se demandent souvent s'ils doivent cibler PDF/UA ou WCAG. La réponse est les deux, car elles opèrent à des niveaux différents.

Les WCAG (Web Content Accessibility Guidelines) définissent les principes d'accessibilité et les critères de réussite pour le contenu web. Il s'agit de la norme à laquelle font référence la section 508, le titre II de l'ADA et l'EAA. Les WCAG vous indiquent ce que doit accomplir un contenu accessible : être perceptible, utilisable, compréhensible et robuste.

PDF/UA décrit comment atteindre ces objectifs au sein d'un fichier PDF. Il s'agit de la norme technique d'implémentation. Un PDF conforme à la norme PDF/UA satisfera aux critères de succès WCAG applicables au contenu du document. Les deux normes sont complémentaires, et non concurrentes. En pratique, si votre flux de travail produit des PDF balisés et bien structurés qui réussissent la validation PDF/UA, vous êtes également bien placé pour la conformité aux WCAG.

L'exigence rétroactive

Un détail qui prend les organisations au dépourvu : ces réglementations ne s'appliquent pas seulement aux nouveaux documents. Les fichiers PDF existants publiés sur des sites web ou distribués via des applications peuvent également nécessiter une correction. Le titre II de l'ADA exige que le contenu Web (y compris les PDF) publié par les gouvernements étatiques et locaux respecte le niveau AA des WCAG 2.1. Il n'existe pas d'exemption générale pour les documents anciens.

Cela rend les outils de conversion programmatique indispensables. Corriger manuellement des milliers de fichiers PDF n'est pas envisageable. Nous aborderons les modèles de correction par lots plus loin dans ce tutoriel.

PDF/UA-1(ISO 14289-1, basé sur PDF 1.7)

La normePDF/UA-1a été publiée en 2012 et reste la version la plus largement adoptée. Elle s'appuie sur la spécification PDF 1.7 et définit un ensemble complet d'exigences concernant la structure des PDF balisés, les métadonnées, les polices et la compatibilité avec les technologies d'assistance. La plupart des outils de validation, y compris veraPDF et le vérificateur d'accessibilité d'Adobe Acrobat, prennent en chargePDF/UA-1comme cible principale.

Si vous démarrez un nouveau projet d'accessibilité et que vous avez besoin d'une large compatibilité avec les outils et les flux de travail existants, le formatPDF/UA-1est la valeur par défaut la plus sûre. Il satisfait aux exigences de la section 508, du titre II de l'ADA et de la loi européenne sur l'accessibilité.

PDF/UA-2(ISO 14289-2:2024, basé sur PDF 2.0)

Le documentPDF/UA-2a été publié en 2024 et représente une mise à jour importante. Basé sur la spécification PDF 2.0 (ISO 32000-2:2020), il introduit une gestion améliorée des fonctionnalités PDF modernes, notamment les annotations, les champs de formulaire, le contenu multimédia et les structures de documents complexes. Le formatPDF/UA-2offre également une meilleure adéquation avec l'évolution des normes d'accessibilité web.

IronPDF prend en charge les deux versions. Vous pouvez spécifier l'élément cible lors de l'exportation, comme nous le démontrerons dans les exemples de code ci-dessous.

WTPDF (PDF bien balisé) et son lien

Vous pourriez rencontrer des références à WTPDF, qui signifie Well-Tagged PDF. Publié par la PDF Association, WTPDF est un ensemble de directives techniques qui expliquent comment créer des PDF correctement balisés. Il ne s'agit pas d'une norme distincte, mais plutôt d'un complément pratique aux normesPDF/UA-2et PDF 2.0. WTPDF fournit des règles détaillées pour l'utilisation des balises, le mappage des éléments de structure et le balisage du contenu qui vont au-delà de ce que définit la spécification PDF/UA elle-même. Considérez-le comme le guide d'implémentation qui complète la norme officielle.

Quelle version cibler ?

Pour la plupart des projets actuels, le format PDF/UA-1 est le choix idéal. Il offre la prise en charge d'outils la plus étendue, l'écosystème de validation le plus abouti et répond à toutes les exigences réglementaires en vigueur. ChoisissezPDF/UA-2si vous avez spécifiquement besoin des fonctionnalités PDF 2.0 telles que la sémantique améliorée des champs de formulaire, une gestion améliorée des annotations ou la compatibilité ascendante avec les normes émergentes.

IronPDF utilise par défaut le format PDF/UA-1 et permet de passer facilement au formatPDF/UA-2lorsque vous êtes prêt.

Rédiger du code HTML accessible

Le HTML accessible se traduit naturellement en une structure PDF balisée accessible. Voici les pratiques qui comptent le plus :

Utilisez des éléments HTML sémantiques. Structurez votre contenu avec <h1> à <h6> pour les en-têtes, <p> pour les paragraphes, <ul> et <ol> pour les listes, <table> avec <thead>, <tbody>, et <th> pour les tableaux de données, et <nav>, <main>, <article>, et <section> pour la structure de la page.

Fournissez un texte alternatif pour chaque image significative. Utilisez l'attribut alt sur toutes les balises <img>. Pour les images décoratives, utilisez une balise alt="" vide pour indiquer que l'image doit être considérée comme un artefact.

Maintenez une hiérarchie d'en-têtes logique. Commencez par un seul <h1>, et ne sautez pas de niveaux. Un document qui passe de <h1> à <h3> produira un arbre d'en-têtes cassé dans la sortie PDF.

Étiquetez les champs de formulaire. Si votre HTML inclut des éléments de formulaire, associez chaque entrée à un élément <label> en utilisant l'attribut for.

Définissez la langue du document. Incluez l'attribut lang sur votre élément <html> (par exemple, <html lang="en">).

Rendu HTML vers PDF/UA avec RenderHtmlAsPdfUA

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-render-html.cs

using IronPdf;

ChromePdfRenderer renderer = new ChromePdfRenderer();

string accessibleHtml = @"
<!DOCTYPE html>
<html lang='en'>
<head>
    <meta charset='UTF-8'>
    <title>Quarterly Accessibility Report</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            line-height: 1.6;
            color: #333;
            max-width: 800px;
            margin: 0 auto;
            padding: 20px;
        }
        h1 {
            color: #1a1a1a;
            border-bottom: 2px solid #0066cc;
            padding-bottom: 8px;
        }
        h2 {
            color: #2a2a2a;
            margin-top: 24px;
        }
        table {
            border-collapse: collapse;
            width: 100%;
            margin: 16px 0;
        }
        th, td {
            border: 1px solid #ccc;
            padding: 10px;
            text-align: left;
        }
        th {
            background-color: #f0f0f0;
            font-weight: bold;
        }
        .summary {
            background-color: #f9f9f9;
            padding: 16px;
            border-left: 4px solid #0066cc;
            margin: 16px 0;
        }
    </style>
</head>
<body>
    <h1>Q3 2025 Accessibility Compliance Report</h1>

    <div class='summary'>
        <p>This report summarizes the accessibility remediation progress
        for all public-facing PDF documents across the organization.</p>
    </div>

    <h2>Document Inventory</h2>
    <p>The following table shows the current status of document
    remediation by department.</p>

    <table>
        <thead>
            <tr>
                <th scope='col'>Department</th>
                <th scope='col'>Total Documents</th>
                <th scope='col'>Compliant</th>
                <th scope='col'>Pending</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>Legal</td>
                <td>1,247</td>
                <td>892</td>
                <td>355</td>
            </tr>
            <tr>
                <td>Finance</td>
                <td>3,891</td>
                <td>3,102</td>
                <td>789</td>
            </tr>
            <tr>
                <td>Human Resources</td>
                <td>567</td>
                <td>401</td>
                <td>166</td>
            </tr>
        </tbody>
    </table>

    <h2>Key Findings</h2>
    <p>Three areas require immediate attention before the
    April 2026 deadline:</p>
    <ol>
        <li>Legacy court filing templates lack heading
        structure entirely.</li>
        <li>Financial statement PDFs generated before 2023
        have no tagged content.</li>
        <li>HR onboarding packets contain scanned images
        without OCR text layers.</li>
    </ol>

    <h2>Remediation Timeline</h2>
    <p>The project team recommends prioritizing public-facing
    documents first, followed by internal documents accessed by
    more than 50 employees.</p>

    <img src='timeline-chart.png'
         alt='Gantt chart showing remediation phases: Phase 1
         covers public documents from October through December
         2025, Phase 2 covers internal documents from January
         through March 2026.' />
</body>
</html>";

// Render directly to PDF/UA-compliant output
PdfDocument pdf = renderer.RenderHtmlAsPdfUA(accessibleHtml);

// Set document metadata (required by PDF/UA)
pdf.MetaData.Title  = "Q3 2025 Accessibility Compliance Report";
pdf.MetaData.Author = "Compliance Department";

pdf.SaveAs("accessibility-report-pdfua.pdf");

Préserver la structure par conversion

IronPDF utilise un moteur de rendu Chromium intégré, la même technologie qui alimente Google Chrome et Microsoft Edge. Cela est important pour l'accessibilité car Chromium comprend déjà la sémantique HTML. IronPDF convertit votre HTML en PDF/UA, il associe les éléments HTML à leurs balises PDF équivalentes :

<h1> à <h6> deviennent des balises d'en-tête <h1> à <h6>. <p> devient des balises de paragraphe <p>. <table>, <tr>, <th> et <td> deviennent des éléments de structure <Table>, <tr>, <th>, et <td>. <ul> et <ol> deviennent <l> (Liste) avec les enfants <li> (Élément de liste). <img> avec texte alternatif devient <Figure> avec une entrée /Alt.

Ce mappage s'effectue automatiquement. Vous n'avez pas besoin de construire manuellement une arborescence de balises PDF ni d'écrire de code pour les éléments de structure.

Modèles HTML courants qui compromettent l'accessibilité

Même les développeurs qui écrivent du code HTML généralement propre utilisent parfois des modèles qui produisent un résultat PDF inaccessible. Attention à ces points :

Utiliser <div> pour tout. Un document entièrement construit à partir d'éléments <div> non stylisés produit un arbre de balises plat et non structuré. Les lecteurs d'écran ne peuvent pas naviguer de manière pertinente sur ce document. Utilisez plutôt des éléments sémantiques.

Simuler des tableaux avec des grilles CSS ou flexbox. Les données présentées dans une disposition de grille visuelle utilisant CSS mais sans éléments <table> réels ne produiront pas de balises de table appropriées dans le PDF. Si le contenu est des données tabulaires, utilisez un vrai <table>.

Sauter des niveaux d'en-tête. Passer de <h1> à <h3> crée un trou dans la hiérarchie des en-têtes que les vérificateurs d'accessibilité signaleront comme un échec.

Images sans texte alternatif. Toute balise <img> manquant l'attribut alt produira une balise <Figure> sans texte alternatif, ce qui constitue une violation directe du PDF/UA.

Texte intégré aux images. Si votre code HTML inclut du texte rendu sous forme d'image (captures d'écran de tableaux, graphiques rasterisés), ce contenu est invisible pour les lecteurs d'écran. Utilisez du texte HTML valide autant que possible et fournissez un texte alternatif complet pour les images restantes.

Sortie par défaut (PDF/UA-1)

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-default-output.cs

using IronPdf;

PdfDocument pdf = PdfDocument.FromFile("standard-report.pdf");

// Default: saves as PDF/UA-1
pdf.SaveAsPdfUA("accessible-report.pdf");

Exporter au formatPDF/UA-2avec le paramètre de version

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-export-pdfua2.cs

using IronPdf;

PdfDocument pdf = PdfDocument.FromFile("modern-form.pdf");

// Export as PDF/UA-2 (based on PDF 2.0)
pdf.SaveAsPdfUA("accessible-form-ua2.pdf", PdfUAVersions.PdfUA2);

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-in-memory-pdfua2.cs

using IronPdf;

PdfDocument pdf = PdfDocument.FromFile("complex-document.pdf");

// Convert to PDF/UA-2 in memory
pdf.ConvertToPdfUA(PdfUAVersions.PdfUA2);

// Perform additional modifications
pdf.MetaData.Title = "Complex Document - Accessible Version";

// Save the converted document
pdf.SaveAs("complex-document-accessible.pdf");

Quand utiliser le PDF/UA-2

Envisagez le formatPDF/UA-2lorsque vos documents dépendent de fonctionnalités PDF 2.0 que le formatPDF/UA-1ne peut pas prendre entièrement en charge. Cela inclut une accessibilité améliorée des champs de formulaire avec des informations sémantiques plus riches, une meilleure gestion des annotations pour les commentaires, le balisage et les flux de travail de révision, une meilleure prise en charge du contenu multimédia intégré dans les PDF et une compatibilité ascendante avec les normes d'accessibilité émergentes basées sur PDF 2.0.

Pour la plupart des projets de conformité actuels, le formatPDF/UA-1fait l'affaire. Le formatPDF/UA-2est le choix d'avenir pour les nouveaux systèmes qui n'auront pas besoin de traiter les données de sortie avec des outils traditionnels.

Validation avec veraPDF

verapdf --profile ua1 output-quarterly-report-accessible.pdf

verapdf --profile ua1 output-quarterly-report-accessible.pdf

Comprendre le protocole Matterhorn

Le protocole Matterhorn est un ensemble de conditions de test publiées par la PDF Association qui définit précisément comment vérifier la conformité d'un PDF à la norme PDF/UA-1. Il organise les contrôles en 31 points de contrôle couvrant 136 conditions de défaillance spécifiques. Chaque condition de défaillance correspond à une clause de la spécification PDF/UA-1.

Par exemple, le point de contrôle 01 vérifie si le catalogue de documents contient l'identifiant PDF/UA requis. Le point de contrôle 06 vérifie si toutes les polices sont intégrées avec des mappages Unicode valides. Le point de contrôle 13 vérifie si les graphiques comportent un texte alternatif approprié.

Comprendre le protocole Matterhorn vous aide à interpréter les résultats de validation et à prioriser les corrections. Toutes les causes de défaillance n'ont pas la même importance. Un titre de document manquant se corrige en cinq minutes. Un document totalement dépourvu de balises nécessite une conversion complète.

Les défaillances courantes en matière de conformité et comment les corriger

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-fix-document-title.cs

using IronPdf;

PdfDocument pdf = PdfDocument.FromFile("input.pdf");

// Set the required document title
pdf.MetaData.Title = "Annual Budget Report - FY2025";

pdf.SaveAsPdfUA("budget-report-accessible.pdf");

Fonts, espaces de couleurs et exigences en matière de métadonnées

Le format PDF/UA impose des exigences spécifiques en matière de présentation visuelle que les outils automatisés vérifient. Toutes les polices doivent être incorporées avec des correspondances ToUnicode correctes. Le texte doit pouvoir être extrait sous forme de caractères Unicode. Les espaces colorimétriques doivent être indépendants du périphérique ou posséder un profil ICC associé. Les champs de formulaire doivent comporter des étiquettes et des descriptions appropriées.

IronPDF gère automatiquement l'intégration des polices, l'espace colorimétrique et les exigences structurelles lors de la conversion. La langue et les métadonnées sont faciles à définir dans le code, comme le montrent les exemples tout au long de ce tutoriel.

Contrôles manuels que l'automatisation ne peut pas détecter

Certains aspects de l'accessibilité nécessitent une vérification humaine. Les validateurs automatisés peuvent vous indiquer qu'une image possède un texte alternatif, mais ils ne peuvent pas juger si ce texte alternatif est réellement utile. Ils peuvent confirmer l'existence des titres, mais ils ne peuvent pas vérifier que le texte du titre décrit fidèlement le contenu qui suit.

Intégrez une étape de révision manuelle dans votre flux de travail pour les documents prioritaires. Vérifiez si le texte alternatif décrit précisément le contenu de l'image, si l'ordre de lecture est logique lorsqu'il est consulté linéairement, si le texte du lien est descriptif (et pas seulement " cliquez ici ") et si la déclaration de langue correspond au contenu réel du document.

Outils de validation supplémentaires

veraPDF est la norme pour la vérification automatisée de la conformité PDF/UA, mais d'autres outils peuvent être utiles en complément :

Adobe Acrobat Pro inclut un outil de vérification d'accessibilité accessible via Outils > Accessibilité > Vérification complète. Il est utile pour des vérifications visuelles rapides pendant le développement et génère un rapport lisible par l'homme. La couverture est moins exhaustive que celle de veraPDF pour PDF/UA-1, mais elle est largement disponible dans la plupart des équipes.

PAC 2024 (vérificateur d'accessibilité PDF, gratuit pour Windows) de la PDF Association offre une inspection visuelle de l'arborescence des balises ainsi que des contrôles de conformité aux normes PDF/UA et WCAG. Il est particulièrement utile pour examiner visuellement l'ordre de lecture et la structure des titres plutôt que par le biais d'un rapport textuel.

Acrobat Reader vous permet d'ouvrir le panneau Balises directement via Affichage > Afficher/Masquer > Volets de navigation > Balises. Il ne s'agit pas d'un validateur, mais d'un outil permettant une inspection visuelle rapide de l'arborescence de la structure sans nécessiter Acrobat Pro.

L'approche la plus fiable consiste à combiner veraPDF pour les contrôles CI/CD automatisés avec une vérification manuelle dans Acrobat ou PAC pour les documents prioritaires.

Conversion par lots de bibliothèques de documents au format PDF/UA

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-batch-conversion.cs

using IronPdf;
using System;
using System.Collections.Concurrent;
using System.IO;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;

public class PdfUaBatchConverter
{
    private readonly SemaphoreSlim _semaphore;
    private readonly ConcurrentBag<string> _failures;
    private int _processed;

    public PdfUaBatchConverter(int maxConcurrency = 4)
    {
        _semaphore = new SemaphoreSlim(maxConcurrency);
        _failures  = new ConcurrentBag<string>();
        _processed = 0;
    }

    public async Task ConvertDirectoryAsync(
        string inputDirectory,
        string outputDirectory,
        NaturalLanguages language = NaturalLanguages.English)
    {
        Directory.CreateDirectory(outputDirectory);

        string[] pdfFiles  = Directory.GetFiles(inputDirectory, "*.pdf");
        int      totalFiles = pdfFiles.Length;

        Console.WriteLine($"Starting PDF/UA conversion: {totalFiles} files");
        Console.WriteLine($"Concurrency: {_semaphore.CurrentCount} parallel operations");
        Console.WriteLine($"Language: {language}");
        Console.WriteLine(new string('-', 50));

        var stopwatch = System.Diagnostics.Stopwatch.StartNew();

        var tasks = pdfFiles.Select(async inputPath =>
        {
            await _semaphore.WaitAsync();
            try
            {
                string fileName  = Path.GetFileName(inputPath);
                string outputPath = Path.Combine(outputDirectory, fileName);

                using (PdfDocument pdf = PdfDocument.FromFile(inputPath))
                {
                    pdf.SaveAsPdfUA(outputPath, NaturalLanguage: language);
                }

                int count = Interlocked.Increment(ref _processed);

                // Log progress every 10 files
                if (count % 10 == 0 || count == totalFiles)
                {
                    double rate = count / stopwatch.Elapsed.TotalSeconds;
                    Console.WriteLine(
                        $"  [{count}/{totalFiles}] " +
                        $"{rate:F1} files/sec");
                }
            }
            catch (Exception ex)
            {
                _failures.Add(
                    $"{Path.GetFileName(inputPath)}: {ex.Message}");
                Interlocked.Increment(ref _processed);
            }
            finally
            {
                _semaphore.Release();
            }
        });

        await Task.WhenAll(tasks);

        stopwatch.Stop();

        // Summary report
        Console.WriteLine(new string('-', 50));
        Console.WriteLine($"Completed in {stopwatch.Elapsed.TotalSeconds:F1}s");
        Console.WriteLine(
            $"Succeeded: {totalFiles - _failures.Count}  " +
            $"Failed: {_failures.Count}");

        if (_failures.Any())
        {
            Console.WriteLine("\nFailed files:");
            foreach (string failure in _failures)
                Console.WriteLine($"  - {failure}");

            // Write failures to log file for later review
            File.WriteAllLines(
                Path.Combine(outputDirectory, "_failures.log"),
                _failures);
        }
    }
}

// Usage
var converter = new PdfUaBatchConverter(
    maxConcurrency: Environment.ProcessorCount);

await converter.ConvertDirectoryAsync(
    inputDirectory:  @"C:\Documents\Legacy",
    outputDirectory: @"C:\Documents\Accessible",
    language: NaturalLanguages.English
);

Atteindre un taux de conversion d'accessibilité automatisée de 80 à 90 %

Les 10 à 20 % restants du travail de mise en conformité nécessitent un jugement humain : textes alternatifs pertinents pour les images complexes, corrections de l'ordre de lecture pour les mises en page inhabituelles et attribution de titres sémantiques aux documents qui n'ont jamais été correctement structurés dans la source. Prévoyez une étape de vérification manuelle de vos documents les plus prioritaires une fois le traitement automatisé terminé.

Prioriser la remédiation

Tous les documents ne présentent pas le même risque de non-conformité. Orientez vos efforts de remédiation de manière stratégique :

Les documents destinés au public en premier. Tout ce qui est publié sur votre site web, distribué à vos clients ou soumis à un organisme gouvernemental est prioritaire. Ce sont les documents les plus susceptibles de déclencher des plaintes ou des audits.

En second lieu, les documents internes fréquemment consultés. Les supports de formation, les manuels de politiques et les formulaires RH que de nombreux employés utilisent régulièrement doivent être corrigés rapidement.

Les documents archivés et peu consultés sont conservés en dernier. Les documents plus anciens, peu consultés, peuvent être restaurés progressivement ou convertis à la demande.

Cette approche de triage vous permet de démontrer les progrès en matière de conformité sur les documents les plus visibles tout en traitant progressivement l'ensemble de vos archives.

Combinaison de PDF/UA avec les flux de travail de fusion, de signatures et de métadonnées

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-merge-metadata.cs

using IronPdf;

// Load and convert to PDF/UA in memory
PdfDocument report = PdfDocument.FromFile("financial-report.pdf");
report.ConvertToPdfUA();

// Set comprehensive metadata
report.MetaData.Title   = "Annual Financial Report 2025";
report.MetaData.Author  = "Finance Department";
report.MetaData.Subject = "Year-end financial summary and analysis";

// Merge with a cover page (also converted to PDF/UA)
PdfDocument coverPage = PdfDocument.FromFile("cover-page.pdf");
coverPage.ConvertToPdfUA();

PdfDocument finalDocument = PdfDocument.Merge(coverPage, report);

// Save the combined, accessible document
finalDocument.SaveAs("annual-report-final-accessible.pdf");

// Dispose of intermediate documents
report.Dispose();
coverPage.Dispose();

Quand vous avez besoin à la fois d'archivage et d'accessibilité

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-dual-compliance.cs

using IronPdf;

PdfDocument pdf = PdfDocument.FromFile("government-record.pdf");

// Convert to PDF/UA for accessibility
pdf.ConvertToPdfUA();

// Set required metadata
pdf.MetaData.Title  = "Public Hearing Minutes - January 2025";
pdf.MetaData.Author = "City Clerk's Office";

// Convert to PDF/A for archival compliance
pdf.SaveAsPdfA("government-record-archive.pdf");

Combinaison de PDF/UA et de signatures numériques

Les documents accessibles qui nécessitent également une authentification peuvent combiner la conversion PDF/UA avec des signatures numériques . Commencez par effectuer la conversion PDF/UA, puis signez le document :

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-digital-signature.cs

using IronPdf;
using IronPdf.Signing;

PdfDocument pdf = PdfDocument.FromFile("contract.pdf");
pdf.ConvertToPdfUA();

pdf.MetaData.Title = "Service Agreement - Executed Copy";

// Apply a digital signature to the accessible document
var signature = new PdfSignature("certificate.pfx", "password");
pdf.Sign(signature);

pdf.SaveAs("contract-accessible-signed.pdf");

Documents pérennes face à l'évolution des normes

Les normes d'accessibilité continuent d'évoluer. La version 2.2 des WCAG a été publiée en 2023, et les travaux sur la version 3.0 sont en cours. Le formatPDF/UA-2est plus conforme aux normes web modernes que le format PDF/UA-1. En intégrant dès maintenant la conformité PDF/UA à vos flux de documents, vous créez une base qui pourra être mise à jour au fur et à mesure de l'évolution des normes, plutôt que de devoir procéder à une refonte complète ultérieurement.

L'investissement dans une infrastructure documentaire accessible rapporte des bénéfices qui vont bien au-delà de la simple conformité. Les fichiers PDF correctement balisés sont plus faciles à rechercher, s'adaptent mieux aux appareils mobiles, produisent de meilleurs résultats d'extraction de texte et fonctionnent de manière plus fiable sur différentes visionneuses et plateformes PDF. L'accessibilité n'est pas seulement une obligation légale. C'est une meilleure ingénierie.