Are PDFs covered by RGAA accessibility requirements?

Yes. Under RGAA 4.1 (based on WCAG 2.1 AA), any document published online and necessary for the user to access information or complete a process must be accessible. This explicitly includes downloadable PDFs. If a PDF is offered on a public-sector website or a site that falls under French accessibility law, it must meet the same level of accessibility as the web pages themselves.

Can I just provide an HTML alternative instead of fixing a PDF?

Providing an accessible HTML alternative is one accepted strategy under RGAA. However, the alternative must contain strictly equivalent information and be easy to find. Simply linking to a generic page is not sufficient. In many cases, remediating the PDF itself is more practical and ensures full compliance regardless of how users reach the document.

What is the fastest way to check if my PDF is accessible?

Start with Adobe Acrobat Pro's built-in Accessibility Checker (Full Check). Then validate with PAC 2024 (PDF Accessibility Checker), which tests against the PDF/UA (ISO 14289) standard. Finally, perform a manual screen-reader test with NVDA or JAWS. This three-step workflow catches the vast majority of issues.

PDF Accessibility: Making Documents RGAA Compliant (Full Guide)

Most organizations invest significant effort into making their web pages accessible. They run audits, fix contrast ratios, add ARIA labels, and test with screen readers. Then they upload a 47-page PDF generated from a Word document nobody tagged — and undo months of work in a single click.

Here is the uncomfortable truth: downloadable documents are part of your legal accessibility obligation under RGAA. Criterion 13.3 of RGAA 4.1 explicitly states that every downloadable document must be accessible, or an accessible alternative must be provided. For French public-sector organizations and an increasing number of private-sector companies, non-compliant PDFs represent a direct legal risk.

And the numbers are striking:

A 2023 study by the European Accessibility Resource Centre found that over 78% of PDFs on government websites failed basic PDF/UA validation.
According to WebAIM’s 2024 screen-reader survey, PDF documents remain the number-one frustration reported by users of assistive technology.
The French Défenseur des Droits reported a 35% year-over-year increase in accessibility complaints, many citing inaccessible downloadable forms.

If your site hosts invoices, contracts, brochures, annual reports, or any form in PDF format, this guide is for you.

Understanding the Legal and Technical Framework

RGAA, WCAG, and PDF/UA: How They Connect

It is easy to get lost in acronym soup, so let’s clarify the relationship between the three standards that govern PDF accessibility in France.

Standard	Scope	Governing Body	Key Focus
RGAA 4.1	French national accessibility framework	DINUM (French government)	Web content + downloadable documents
WCAG 2.1 AA	International web accessibility guidelines	W3C	Perceivable, Operable, Understandable, Robust
PDF/UA (ISO 14289-1)	Universal accessibility standard for PDF	ISO / PDF Association	Tagged structure, reading order, metadata

RGAA is built on top of WCAG 2.1 AA. When RGAA says a PDF must be accessible, it means the PDF must satisfy WCAG success criteria — and the most reliable technical pathway to achieve that is conformance with the PDF/UA standard.

In practical terms, if your PDF passes PDF/UA validation, it will satisfy the vast majority of RGAA requirements for documents.

What RGAA Specifically Requires for Downloadable Documents

RGAA addresses downloadable documents primarily under Theme 13 — Consultation:

Criterion 13.3: Each downloadable office document has an accessible version, if necessary.
Criterion 13.4: For each downloadable office document with an accessible version, does this version provide the same information?

This means you have two paths:

Make the PDF itself accessible (preferred).
Provide an equivalent accessible alternative (HTML page, accessible DOCX, etc.).

Option 1 is almost always better. It avoids synchronization issues, reduces maintenance, and guarantees users get the same experience regardless of format.

The Anatomy of an Accessible PDF

Before jumping into tools and workflows, you need to understand what makes a PDF accessible at the structural level. An accessible PDF is not simply a PDF that “looks nice.” It is a PDF whose underlying tagged structure accurately represents its content semantics.

Essential Structural Elements

An RGAA-compliant PDF must include:

A tag tree — the equivalent of HTML DOM for PDF. Every piece of content (heading, paragraph, image, table, list) must have a corresponding tag.
Correct reading order — assistive technology reads tags in sequence. The visual layout may differ from the logical reading order, and the tags must reflect the logical order.
Document language declaration — the PDF metadata must specify the primary language (e.g., fr-FR or en-GB).
Alternative text for images — every informative image tag must carry alt text. Decorative images must be marked as artifacts.
Properly tagged headings — <H1> through <H6> tags that reflect the document hierarchy.
Tagged tables with headers — <Table>, <TR>, <TH>, and <TD> tags with proper scope attributes.
Tagged lists — <L>, <LI>, <Lbl>, and <LBody> tags.
Bookmarks for documents exceeding 20 pages (RGAA best practice and PDF/UA requirement).
No scanned-image-only content — if the PDF is a scan, OCR must be applied and tags must be added.

Common Failures: What Usually Goes Wrong

In our experience at Lueur Externe, the most frequent issues we encounter during accessibility audits fall into a predictable pattern:

No tag tree at all — the PDF was exported without the “tagged PDF” option. Screen readers receive a wall of undifferentiated text.
Auto-generated tags that are wrong — software like InDesign or Word produces tags, but headings are tagged as <P>, tables have no <TH> cells, and reading order is chaotic.
Missing language attribute — the document language is blank or set to the wrong locale.
Images without alt text — or worse, alt text that reads “image1.png.”
Fillable form fields without labels — form fields exist visually but have no associated label tags, making them unusable with a screen reader.

Creating Accessible PDFs From the Source

The most efficient strategy is to build accessibility into the source document before exporting to PDF. Remediating a PDF after the fact is always more expensive and error-prone.

From Microsoft Word

Word is the most common source for PDFs in business environments. Here is a reliable workflow:

Use built-in heading styles (Heading 1, Heading 2, etc.) — never fake headings with bold + large font.
Add alt text to all images — right-click > Edit Alt Text.
Use Word’s table tools — insert tables via the Table menu, specify a header row, avoid merged cells when possible.
Use the built-in Accessibility Checker — Review > Check Accessibility. Fix all errors before exporting.
Set the document language — File > Options > Language.
Export with tags — File > Save As > PDF > Options > check “Document structure tags for accessibility.”

From Adobe InDesign

InDesign offers more layout control but requires more manual accessibility work:

Map all paragraph styles to PDF tags — open the Tags panel (Window > Utilities > Tags) and assign export tags to each style.
Use the Articles panel to define and verify reading order.
Set alt text on image frames — Object > Object Export Options > Alt Text.
Set the language — in File > File Setup or at the story level.
Export as PDF/UA — File > Export > Adobe PDF (Print), check “Create Tagged PDF” and “Use Structure for Tab Order.”

From HTML (Programmatic PDF Generation)

Many organizations generate PDFs dynamically — invoices, reports, certificates. When you control the code, you can embed accessibility from the start.

Here is an example using a popular approach with tagged PDF generation in Python using the reportlab library:

from reportlab.lib.pagesizes import A4
from reportlab.platypus import SimpleDocTemplate, Paragraph, Spacer
from reportlab.lib.styles import getSampleStyleSheet
from reportlab.lib.units import cm

doc = SimpleDocTemplate(
    "accessible_report.pdf",
    pagesize=A4,
    title="Annual Accessibility Report 2024",
    author="Lueur Externe",
    subject="RGAA Compliance",
    lang="en-GB"  # Document language
)

styles = getSampleStyleSheet()
story = []

# Tagged heading
story.append(Paragraph("Annual Accessibility Report", styles['Heading1']))
story.append(Spacer(1, 0.5 * cm))

# Tagged paragraph
story.append(Paragraph(
    "This report summarizes the accessibility audit findings "
    "for all public-facing digital assets, including 247 PDFs.",
    styles['BodyText']
))

# Build with tagging enabled
doc.build(story)

For more robust PDF/UA output, tools like Apache FOP (with accessibility extensions), Antenna House, or Prince XML offer full tagged-PDF generation with proper role mapping.

When Lueur Externe builds e-commerce platforms on Prestashop or content-driven sites on WordPress, we ensure that any dynamically generated PDF — invoices, order confirmations, product datasheets — passes PDF/UA validation out of the box. This proactive approach eliminates the costly remediation cycle.

Remediating Existing PDFs

Most organizations have hundreds or thousands of existing PDFs that were never created with accessibility in mind. Here is a practical remediation workflow.

Step 1: Triage and Prioritize

Not every PDF warrants full remediation. Prioritize by:

Legal obligation — public-facing documents required for service access (forms, contracts, policies)
Traffic volume — high-download PDFs first
Recency — archive or remove outdated documents rather than remediating them
Complexity — simple text documents are quick wins; complex multi-column layouts with tables take longer

Step 2: Use Adobe Acrobat Pro for Remediation

Adobe Acrobat Pro DC remains the industry-standard tool for PDF remediation:

Run the Accessibility Check — Accessibility > Full Check (Ctrl+Shift+F5).
Add tags if missing — Accessibility > Autotag Document (then review and correct).
Fix the reading order — Accessibility > Reading Order tool. Click and drag to redefine content regions and assign correct tags.
Add alt text — right-click image tags in the Tags panel > Properties > Alternate Text.
Fix table structure — select table cells in the Tags panel, convert <TD> to <TH> for header cells, add scope attributes.
Set document properties — File > Properties > set Title, Language, and check “Display Document Title” in Initial View.
Tag form fields — Accessibility > Add Form Field Labels.

Step 3: Validate With PAC 2024

After remediation, validate with PAC 2024 (PDF Accessibility Checker by the PDF/UA Foundation). It is free and provides a detailed PDF/UA conformance report.

PAC checks over 100 rules, including:

Tag presence and completeness
Role mapping validity
Reading order consistency
Font embedding (critical for screen readers)
Metadata completeness

A PAC-compliant PDF will meet virtually all RGAA requirements for downloadable documents.

Automated tools catch structural issues but miss experiential ones. Always test with at least one screen reader:

NVDA (free, Windows) — the most widely used free screen reader
JAWS (commercial, Windows) — the enterprise standard
VoiceOver (built-in, macOS/iOS) — essential for Apple users

Key things to verify manually:

Does the reading order make logical sense?
Are headings announced at the correct level?
Can you navigate tables cell-by-cell with header announcements?
Are form fields labeled and usable?
Are decorative elements silent (not announced)?

Accessibility Checklist for RGAA-Compliant PDFs

Use this checklist before publishing any PDF:

Scaling PDF Accessibility Across Your Organization

Templates Are Your Best Friend

Creating an accessible PDF from scratch every time is unsustainable. Instead:

Build accessible Word and InDesign templates with pre-mapped styles and tags.
Distribute them organization-wide with clear usage documentation.
Lock down style options to prevent authors from introducing inaccessible formatting.

Automate What You Can

For dynamically generated PDFs:

Integrate PDF/UA validation into your CI/CD pipeline.
Use libraries that support tagged PDF output natively.
Set up automated checks using PAC’s command-line interface or the Acrobat Preflight API.

Train Your Content Teams

The most common source of inaccessible PDFs is not a technical limitation — it is a knowledge gap. Invest in short, practical training sessions (90 minutes is usually enough) that cover:

Why accessibility matters (legal, ethical, business case)
How to use heading styles correctly
How to add alt text
How to use the Word accessibility checker
How to export a tagged PDF

The Business Case Beyond Compliance

Accessible PDFs are not just a legal checkbox. They deliver tangible business benefits:

Better SEO — tagged PDFs are indexable by search engines. Google can extract headings, text, and structure from well-tagged PDFs, improving your document visibility.
Improved usability for everyone — proper headings and bookmarks make documents easier to navigate for all users, not just those using assistive technology.
Reduced support costs — accessible forms reduce errors and support requests.
Brand credibility — demonstrating accessibility commitment strengthens trust with customers, partners, and regulators.

Conclusion: Accessibility Is Not Optional — And Neither Is Expertise

PDF accessibility is one of the most overlooked aspects of RGAA compliance, yet it is one of the most impactful. Every inaccessible PDF you publish is a barrier — to a visually impaired citizen trying to access a public service, to a customer trying to read your terms of service, to a prospect trying to download your product catalog.

The good news is that with the right processes, tools, and templates, making PDFs accessible becomes routine rather than exceptional. Start at the source, validate rigorously, test with real assistive technology, and scale through templates and training.

If you need expert help auditing your existing PDFs, building accessible templates, or integrating PDF/UA compliance into your WordPress or Prestashop platform, Lueur Externe has been helping organizations across the Alpes-Maritimes and beyond achieve full digital accessibility since 2003. Our team combines deep technical expertise in web development, SEO, and accessibility to deliver solutions that are compliant, performant, and sustainable.

Contact Lueur Externe for a free accessibility audit →

Why PDF Accessibility Is the Biggest Blind Spot in RGAA Compliance