PDF Accessibility in C#: Create, Convert, and Validate PDF/UA Documents

The Legal Tipping Point

Three regulatory developments have converged to make PDF/UA compliance urgent.

These are not theoretical risks. Accessibility lawsuits have increased year over year, and courts have consistently held that digital documents fall within the scope of disability discrimination law. Organizations that treat accessibility as a future concern are increasingly finding themselves defending complaints, audit findings, and litigation over documents their software produced months or years ago.

Section 508 of the Rehabilitation Act has required U.S. federal agencies and their contractors to produce accessible electronic information technology for years. PDFs are explicitly covered. If your software generates documents consumed by or on behalf of a federal agency, those documents must be accessible. The Department of Justice investigates complaints and brings enforcement actions against non-compliant organizations.

ADA Title II extends accessibility obligations to state and local governments. The DOJ's final rule, published in 2024, set compliance deadlines of April 2026 for entities with populations of 50,000 or more and April 2027 for smaller entities. The scope is broad: every PDF published on a government website, distributed via email, or generated through a constituent-facing application must meet WCAG 2.1 Level AA. That's meeting agendas, budget documents, permit applications, court records, zoning maps, and council minutes, among many other document types.

The European Accessibility Act (EAA) came into force in June 2025 and requires that products and services sold in the EU meet accessibility requirements. For software companies serving EU customers, the documents your applications produce need to be accessible. This is not limited to government; it applies to private-sector products and services across a wide range of categories.

What PDF/UA Actually Requires

PDF/UA (ISO 14289) defines the technical requirements a PDF must satisfy for assistive technologies to process it reliably. A compliant document must have:

A complete tag structure. Every piece of meaningful content must be represented in a logical structure tree using standard PDF tags: <H1> through <H6> for headings, <P> for paragraphs, <Table> for data tables, <Figure> for images, and <L> for lists. Content that is purely decorative must be marked as an artifact so screen readers skip it.

A correct reading order. The tag tree must reflect the logical order in which content should be read, not the visual order in which it appears on the page. For multi-column layouts or documents with sidebars, this distinction matters significantly.

Alternative text for non-text content. Every image, chart, and diagram that conveys information must have alt text attached to its <Figure> tag. Decorative images must be marked as artifacts.

Proper metadata. The document must declare its natural language (e.g., "en" for English), have a meaningful title, and include the PDF/UA identifier in its XMP metadata.

Embedded fonts with Unicode mappings. All fonts must be embedded, and Unicode character mappings (ToUnicode CMap) must be present so that text can be extracted and read aloud accurately.

PDF/UA vs WCAG: How the Two Standards Work Together

Developers often ask whether they should target PDF/UA or WCAG. The answer is both, because they operate at different layers.

WCAG (Web Content Accessibility Guidelines) defines accessibility principles and success criteria for web content. It is the standard referenced by Section 508, ADA Title II, and the EAA. WCAG tells you what accessible content should achieve: perceivable, operable, understandable, and robust.

PDF/UA tells you how to achieve those goals inside a PDF file. It is the technical implementation standard. A PDF that meets PDF/UA will satisfy the WCAG success criteria that apply to document content. The two standards are complementary, not competing. In practice, if your workflow produces tagged, well-structured PDFs that pass PDF/UA validation, you are in strong shape for WCAG compliance as well.

The Retroactive Requirement

One detail that catches organizations off guard: these regulations do not only apply to new documents. Existing PDFs published on websites or distributed through applications may also need to be remediated. ADA Title II requires that web content (including PDFs) published by state and local governments meet WCAG 2.1 Level AA. There is no blanket exemption for legacy documents.

This makes programmatic conversion tools essential. Manually remediating thousands of PDFs is not practical. We'll cover batch remediation patterns later in this tutorial.

PDF/UA-1 (ISO 14289-1, Based on PDF 1.7)

PDF/UA-1 was published in 2012 and remains the most widely adopted version of the standard. It builds on the PDF 1.7 specification and defines a comprehensive set of requirements for tagged PDF structure, metadata, fonts, and assistive technology compatibility. Most validation tools, including veraPDF and Adobe Acrobat's accessibility checker, support PDF/UA-1 as their primary target.

If you're starting a new accessibility project and need broad compatibility with existing tools and workflows, PDF/UA-1 is the safe default. It satisfies the requirements of Section 508, ADA Title II, and the EU Accessibility Act.

PDF/UA-2 (ISO 14289-2:2024, Based on PDF 2.0)

PDF/UA-2 was published in 2024 and represents a significant update. Built on the PDF 2.0 specification (ISO 32000-2:2020), it introduces improved handling of modern PDF features including annotations, form fields, multimedia content, and complex document structures. PDF/UA-2 also provides better alignment with evolving web accessibility standards.

IronPDF supports both versions. You can specify which one to target when exporting, as we'll demonstrate in code examples below.

WTPDF (Well-Tagged PDF) and How It Relates

You may encounter references to WTPDF, which stands for Well-Tagged PDF. Published by the PDF Association, WTPDF is a set of technical guidance that clarifies how to create properly tagged PDFs. It is not a separate standard but rather a practical companion to PDF/UA-2 and PDF 2.0. WTPDF provides detailed rules for tag usage, structure element mapping, and content tagging that go beyond what the PDF/UA specification itself defines. Think of it as the implementation guide that sits alongside the formal standard.

Which Version Should you Target?

For most projects today, PDF/UA-1 is the right choice. It has the broadest tool support, the most mature validation ecosystem, and satisfies every current regulatory requirement. Choose PDF/UA-2 if you specifically need PDF 2.0 features such as enhanced form field semantics, improved annotation handling, or forward compatibility with emerging standards.

IronPDF defaults to PDF/UA-1 and makes it straightforward to switch to PDF/UA-2 when you're ready.

Writing Accessibility-Ready HTML

Accessible HTML translates naturally into accessible tagged PDF structure. Here are the practices that matter most:

Use semantic HTML elements. Structure your content with <h1> through <h6> for headings, <p> for paragraphs, <ul> and <ol> for lists, <table> with <thead>, <tbody>, and <th> for data tables, and <nav>, <main>, <article>, and <section> for page structure.

Provide alt text for every meaningful image. Use the alt attribute on all <img> tags. For decorative images, use an empty alt="" to signal that the image should be treated as an artifact.

Maintain a logical heading hierarchy. Start with a single <h1>, and don't skip levels. A document that jumps from <h1> to <h3> will produce a broken heading tree in the PDF output.

Label form fields. If your HTML includes form elements, associate every input with a <label> element using the for attribute.

Set the document language. Include the lang attribute on your <html> element (e.g., <html lang="en">).

Rendering HTML to PDF/UA with 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");

Preserving Structure Through Conversion

IronPDF uses an embedded Chromium rendering engine, the same technology that powers Google Chrome and Microsoft Edge. This matters for accessibility because Chromium already understands HTML semantics. When IronPDF renders your HTML to PDF/UA, it maps HTML elements to their PDF tag equivalents:

<h1> through <h6> become <H1> through <H6> heading tags. <p> becomes <P> paragraph tags. <table>, <tr>, <th>, and <td> become <Table>, <TR>, <TH>, and <TD> structure elements. <ul> and <ol> become <L> (List) with <LI> (List Item) children. <img> with alt text becomes <Figure> with an /Alt entry.

This mapping happens automatically. You don't need to manually construct a PDF tag tree or write any structure-element code.

Common HTML Patterns That Break Accessibility

Even developers who write generally clean HTML sometimes use patterns that produce inaccessible PDF output. Watch for these:

Using <div> for everything. A document built entirely from unstyled <div> elements produces a flat, unstructured tag tree. Screen readers can't navigate it meaningfully. Use semantic elements instead.

Simulating tables with CSS grids or flexbox. Data presented in a visual grid layout using CSS but not actual <table> elements won't produce proper table tags in the PDF. If the content is tabular data, use a real <table>.

Skipping heading levels. Jumping from <h1> to <h3> creates a gap in the heading hierarchy that accessibility checkers will flag as a failure.

Images without alt text. Any <img> tag missing the alt attribute will produce a <Figure> tag with no alternative text, which is a direct PDF/UA violation.

Text embedded in images. If your HTML includes text rendered as an image (screenshots of tables, rasterized charts), that content is invisible to screen readers. Use real HTML text wherever possible, and provide comprehensive alt text for any remaining images.

Default Output (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");

Exporting as PDF/UA-2 with the Version Parameter

: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");

When to Use PDF/UA-2

Consider PDF/UA-2 when your documents rely on PDF 2.0 features that PDF/UA-1 can't fully address. This includes enhanced form field accessibility with richer semantic information, improved annotation handling for comments, markup, and review workflows, better support for multimedia content embedded in PDFs, and forward compatibility with emerging accessibility standards built on PDF 2.0.

For most compliance projects today, PDF/UA-1 gets the job done. PDF/UA-2 is the forward-looking choice for new systems that won't need to process the output in legacy tooling.

Validating with veraPDF

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

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

Understanding the Matterhorn Protocol

The Matterhorn Protocol is a set of test conditions published by the PDF Association that defines exactly how to check a PDF for PDF/UA-1 compliance. It organizes checks into 31 checkpoints covering 136 specific failure conditions. Each failure condition maps to a clause in the PDF/UA-1 specification.

For example, Checkpoint 01 covers whether the document catalog contains the required PDF/UA identifier. Checkpoint 06 covers whether all fonts are embedded with valid Unicode mappings. Checkpoint 13 covers whether graphics have appropriate alternative text.

Understanding the Matterhorn Protocol helps you interpret validation results and prioritize fixes. Not all failure conditions carry equal weight. A missing document title is a five-minute fix. A completely untagged document requires full conversion.

Common Compliance Failures and How to Fix Them

: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, Color Spaces, and Metadata Requirements

PDF/UA has specific requirements around visual presentation that automated tools check. All fonts must be embedded with correct ToUnicode mappings. Text must be extractable as Unicode characters. Color spaces must be device-independent or have an associated ICC profile. Form fields must have proper labels and descriptions.

IronPDF addresses the font embedding, color space, and structural requirements automatically during conversion. Language and metadata are straightforward to set in code, as shown in the examples throughout this tutorial.

Manual Checks That Automation Can't Catch

Some aspects of accessibility require human review. Automated validators can tell you that an image has alt text, but they can't judge whether the alt text is actually useful. They can confirm that headings exist, but they can't verify that the heading text accurately describes the content that follows.

Build a manual review step into your workflow for high-priority documents. Focus on whether alt text accurately describes image content, whether the reading order makes logical sense when consumed linearly, whether link text is descriptive (not just "click here"), and whether the language declaration matches the actual content of the document.

Additional Validation Tools

veraPDF is the standard for automated PDF/UA conformance checking, but other tools can be useful alongside it:

Adobe Acrobat Pro includes an accessibility checker under Tools > Accessibility > Full Check. It is useful for quick visual spot-checks during development and generates a human-readable report. Coverage is less comprehensive than veraPDF for PDF/UA-1, but it is widely available on most teams.

PAC 2024 (PDF Accessibility Checker, free for Windows) from the PDF Association offers visual tag-tree inspection alongside conformance checks against PDF/UA and WCAG. It is particularly useful for inspecting reading order and heading structure visually rather than through a text report.

Acrobat Reader lets you open the Tags panel directly under View > Show/Hide > Navigation Panes > Tags. This is not a validator, but it gives a quick visual inspection of the structure tree without needing Acrobat Pro.

The most reliable approach is to combine veraPDF for automated CI/CD checks with a manual pass in Acrobat or PAC for high-priority documents.

Batch Converting Document Libraries to 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
);

Achieving 80-90% Automated Accessibility Conversion

The remaining 10-20% of compliance work requires human judgment: meaningful alt text for complex images, reading order corrections for unusual layouts, and semantic heading assignments for documents that were never properly structured in the source. Plan for a manual review step on your highest-priority documents after the automated pass completes.

Prioritizing Remediation

Not all documents carry equal compliance risk. Focus your remediation efforts strategically:

Public-facing documents first. Anything published on your website, distributed to customers, or submitted to a government agency is the highest priority. These are the documents most likely to trigger complaints or audits.

Frequently accessed internal documents second. Training materials, policy handbooks, and HR forms that many employees use regularly should be remediated promptly.

Archival and low-traffic documents last. Older documents that receive minimal access can be remediated on a rolling basis or converted on demand when someone requests them.

This triage approach lets you demonstrate compliance progress on the most visible documents while working through the long tail of your archive over time.

Combining PDF/UA with Merging, Signatures, and Metadata Workflows

: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();

When You Need Both Archival and Accessibility

: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");

Combining PDF/UA with Digital Signatures

Accessible documents that also require authentication can combine PDF/UA conversion with digital signatures. Apply the PDF/UA conversion first, then sign the 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");

Future-Proofing Documents for Evolving Standards

Accessibility standards continue to evolve. WCAG 2.2 was published in 2023, and work on WCAG 3.0 is underway. PDF/UA-2 aligns more closely with modern web standards than PDF/UA-1 does. By building PDF/UA compliance into your document pipelines now, you create a foundation that can be updated as standards evolve, rather than facing a complete retrofit later.

The investment in accessible document infrastructure pays dividends beyond compliance. Properly tagged PDFs are more searchable, reflow better on mobile devices, produce better text extraction results, and work more reliably across different PDF viewers and platforms. Accessibility isn't just a legal requirement. It's better engineering.