On each web page, does each downloadable office document have, where necessary, an accessible version (except in special cases)?
A screen reader user downloads your organization's annual report in PDF. The file is untagged: no structure, no reading order, no alternatives for graphics. The reader announces "empty page" over and over. The document conveys nothing to them.
This criterion applies only to office documents that contain useful information. If that content disappeared, the user would lose something. In that case, an accessible version must exist—either the document itself complies with the RGAA criteria applicable to office documents, or an accessible alternative is provided alongside the download link.
The formats covered are the most common: PDF, Word (.doc/.docx), OpenDocument (.odt), EPUB and DAISY, as well as HTML files themselves. Each format has its own verification tools: PAC for PDFs (Windows only), Microsoft Office's built-in checker for .docx files, Ace by DAISY App for EPUB. On Mac, PDF checking is done manually.
The accessible alternative does not need to be in the same format. A complex PDF can be accompanied by a structured HTML page containing the same information. The essential point: the user can access the content.
Un test to assess the accessibility of office documents for download
Accessible version or alternative for each office document
- Locate all links and buttons on the page that trigger the download of an office file (PDF, .doc, .docx, .odt, EPUB, DAISY, .html).
- For each file found, verify that an accessible version exists and is clearly identified. Depending on the format:
- PDF → analyze with PAC (PDF Accessibility Checker) on Windows. Only errors referenced in the RGAA "Downloaded office document list" result in non-compliance. On Mac, manual checking.
- .doc / .docx → open Microsoft Office's accessibility checker via File > Information > Check accessibility (Office 2010 minimum). On Mac, manual checking.
- .odt → check manually with OpenOffice or LibreOffice, or convert to .docx to use Microsoft's checker — only for simple documents, conversion alters some accessibility information.
- EPUB / DAISY → analyze with Ace by DAISY App.
- .html → audit as an ordinary web page according to applicable RGAA criteria.
- If each file has a compliant version or an accessible alternative, the test is validated. A single non-compliant file without an alternative is enough to fail the test.
Examples
❌ Non-compliant : Download link without accessible version
<p>
<a href="rapport-annuel-2025.pdf">Download the 2025 annual report (PDF, 4.2 MB)</a>
</p>The PDF is offered without any indication of accessibility or alternative. If the file was generated by virtual printing or basic export, it contains no structure tags. A screen reader user cannot extract any information from it. Criterion 13.3 is non-compliant.
✅ Compliant : Download link with accessible HTML alternative
<p>
<a href="rapport-annuel-2025.pdf">Download the 2025 annual report (PDF, 4.2 MB)</a>
<a href="rapport-annuel-2025.html">View the 2025 annual report in accessible HTML version</a>
</p>A structured HTML alternative is offered alongside the PDF. The user who cannot use the PDF has equivalent access to the content. The HTML version must itself comply with the RGAA criteria applicable to web pages — untagged HTML would be no better than the original PDF.
✅ Compliant : PDF itself accessible, verified and identified
<p>
<a href="guide-procedures-2025.pdf">Download the 2025 procedures guide (accessible PDF, 1.8 MB)</a>
</p>The PDF document itself is compliant: headings tagged with appropriate styles, logical reading order, document language declared, images with alternative text. The mention "accessible PDF" informs the user. Compliance is established via PAC on Windows or manual checking on Mac, with reference to the RGAA criteria list for office documents.
Tips and pitfalls
⚠️ Exporting to PDF from Word is not enough
The vast majority of teams generate their PDFs via "Print > Save as PDF" or via a system export. This process produces a PDF without structure tags: PAC reports critical errors, the screen reader cannot read the document. You must use "File > Save as > PDF" with the "Tagged PDF for accessibility" option checked, and only after structuring the Word document with heading styles.
💡 PAC does not replace a full audit
PAC detects technical structure errors (missing tags, reading order, missing language). It does not detect whether image alternative texts are relevant, or whether link labels are explicit. A document with no PAC errors can still have accessibility defects on these points. Cross-reference PAC with the "Downloaded office document list" for a complete check.
⚠️ Documents published before September 23, 2018: conditional exemption
Private organizations covered by 2° to 4° of I of article 47 of the February 11, 2005 law are not required to make office documents published before that date accessible. The exemption falls if the document is necessary to accomplish an administrative procedure with the organization. In cases covered by the exemption, the criterion is non-applicable — not just non-compliant.
⚠️ Converting .odt to .docx: losses are silent
Converting an .odt file to .docx to access Microsoft Office's checker is tempting, but conversion alters some accessibility information without warning: language indications, image alternatives, merged headers in tables. This method only works for very simple documents. For any document containing tables or informative images, manual checking remains the only reliable option.
💡 Exemption is not a total waiver
In case of granted exemption, the organization is not dispensed from providing access to content: it undertakes to produce an accessible version on request from the user. The page must indicate how to make this request. Total absence of access, even exempt, remains non-compliance.
Frequently asked questions
Which office documents for download must be accessible according to RGAA?
Not all. Criterion 13.3 specifies "if necessary". A purely decorative document, a blank form to print whose content is otherwise described on the page, or an anecdotal file with no useful information is not concerned. As soon as the document conveys information that the user cannot obtain elsewhere on the page, an accessible version is required.
Which formats constitute a valid accessible alternative to a non-compliant RGAA office document?
Any format. A non-compliant PDF report can have a structured HTML page as an alternative; an Excel spreadsheet can be accompanied by an HTML table. The format does not matter: what counts is that the user accesses the same information with the same functionality, regardless of the chosen format.
Why does PAC report PDF/UA errors on a document that is nevertheless compliant with RGAA 13.3?
Yes, in this case. PAC verifies both RGAA criteria (via the "Downloaded office document list") and stricter PDF/UA quality requirements than RGAA. Only errors corresponding to the criteria in this list result in non-compliance with criterion 13.3. A PDF/UA error without an equivalent in the RGAA list does not make the criterion non-compliant.
How can I effectively audit RGAA criterion 13.3 on office documents in practice?
Start by listing all download links on the page — look for .pdf, .doc, .docx, .odt, .epub extensions in href attributes. For each file, first verify whether an accessible alternative version is identified. If yes, analyze this version with the tool appropriate for the format. Allow time: a 50-page unstructured PDF can require an hour of manual checking, especially on Mac without PAC.
Why don't Word heading styles guarantee RGAA compliance of a document?
Not automatically. Heading styles are a necessary but not sufficient condition. You also need: alternative text for all informative images, declared table headers, document language defined, links with explicit labels, and sufficient color contrast. Microsoft Office's accessibility checker detects some of these issues; it does not detect all of them.