Document Accessibility Testing

Document accessibility testing checks whether PDFs, Word files, spreadsheets and slide decks can be read and completed by people using screen readers, keyboards and magnification. A reliable test has three layers: an automated checker such as the free PAC 2026 or Adobe Acrobat’s Accessibility Checker, a manual review of tags, reading order, alt text, tables and form fields, and a real screen reader pass with NVDA. Documents are judged against WCAG (Section 508 uses WCAG 2.0 AA, the ADA Title II rule uses WCAG 2.1 AA) and, for PDFs, the PDF/UA standard (ISO 14289).

This guide is written by HalfAccessible founder Mohammad Shadab Saifi, who holds the IAAP CPACC, WAS and CPWA certifications, is a DHS Section 508 Trusted Tester and leads our document audits and remediation for companies, universities and public bodies. It is practical guidance, not legal advice.

Document Accessibility Deadlines At A Glance

• Apr 26, 2027: ADA Title II deadline for state and local entities with a population of 50,000 or more (documents count as web content) (Source: ADA.gov web rule fact sheet (opens in a new tab))
• Apr 26, 2028: ADA Title II deadline for smaller public entities and special district governments (Source: ADA.gov web rule fact sheet (opens in a new tab))
• WCAG 2.1 AA: Technical standard the DOJ Title II rule sets for web content, including PDFs and office files posted online (Source: ADA.gov web rule fact sheet (opens in a new tab))
• Free: PAC 2026 PDF Accessibility Checker for PDF/UA and WCAG machine checks (Windows) (Source: PAC PDF Accessibility Checker (opens in a new tab))

Choose Your Next Step

Want a quick first look at the web pages that host your files? Run a free one-page scan on AccessibilityScore.in (opens in a new tab); it is a starting point that complements manual document testing, not a replacement. For a full website audit of up to 25 templates, see the $2,000 Complete Audit on our pricing page.

Free 30-Minute Call

Best for: first conversations, scoping a document set and quotes

Tell us what you publish and who uses it. We suggest what to sample, which tools to run and what testing or remediation will cost. No technical prep needed.

Book a free 30-minute call (opens in a new tab)

PDF Remediation Quote

Best for: libraries of PDFs, forms and reports that need fixing

Founder-led testing against WCAG and PDF/UA, then tagged repairs and a re-test. Document work is quoted per set, not by the hour.

Get a PDF remediation quote

$100 Technical Consultation

Best for: teams stuck on failing PAC results or audit findings

A one-hour working session to walk through an existing PDF audit, review failing files with the person who builds them, or check a sample live.

Book the $100 technical hour

What Is Document Accessibility Testing?

Document accessibility testing evaluates digital files such as PDFs, Word documents, Excel spreadsheets and PowerPoint presentations to make sure people with disabilities can read, navigate and complete them.

Many organizations focus heavily on website accessibility while overlooking documents that contain critical information: application forms, policies, annual reports, menus, invoices and course materials. Accessible documents help ensure equal access to content while supporting regulatory compliance.

Why Accessible Documents Matter

Accessible documents improve usability for people who rely on screen readers, keyboard navigation, magnification software, reflow and other assistive technologies.

Supports Legal and Regulatory Compliance

Documents are covered by most accessibility laws, not just websites:

• Section 508 (US federal agencies and their suppliers): the Revised 508 Standards require electronic content, including PDFs, Word files, spreadsheets and presentations, to conform to WCAG 2.0 Level A and AA (E205.4). Non-web documents are exempt from only four criteria: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification. Section508.gov publishes guides to creating accessible documents and accessible PDFs.
• ADA Title II (US state and local government, public schools and universities): the DOJ rule treats documents as web content and sets WCAG 2.1 Level AA. After the April 2026 interim final rule, the compliance date is April 26, 2027 for entities with a population of 50,000 or more and April 26, 2028 for smaller entities and special district governments (ADA.gov fact sheet). Older PDFs, Word, presentation and spreadsheet files posted before the compliance date are usually exempt, but not if people still use them to apply for, access or take part in a service, such as an application form.
• ADA Title III (US businesses): there is no DOJ technical standard for private websites, but documents customers need, such as menus, forms, policies and statements, can be cited in demand letters and lawsuits, and settlements commonly reference WCAG 2.1 or 2.2 AA.
• EU and UK: EN 301 549 has a dedicated clause 10 for non-web documents. The Web Accessibility Directive covers public sector office files published from 23 September 2018, and older ones still needed for active administrative processes. The European Accessibility Act can bring documents that are part of covered services, such as e-commerce and banking, into scope.

Public bodies preparing for the Title II dates can use our government accessibility audit request to scope websites and document libraries together.

Expands Access to Information

Accessible documents let every user find, understand and act on content independently, without asking for an alternative format.

Improves User Experience

Well-structured documents are easier for everyone to navigate, search and reuse, and they convert to other formats more reliably.

Which Standards Apply to Documents?

• WCAG 2.x: WCAG 2.2 is written for web content, but documents published on a website are web content too. For documents that are not on the web, the W3C’s WCAG2ICT note explains how to interpret each criterion, and the W3C publishes PDF techniques for meeting WCAG in PDF files.
• PDF/UA (ISO 14289): the international standard for universally accessible PDF. It defines how a PDF must be tagged and structured so assistive technology can use it. PDF/UA-1 (ISO 14289-1) applies to PDF 1.7 files and is the version the Section 508 standards and most checkers still reference. PDF/UA-2 (ISO 14289-2:2024), published in March 2024, applies the same idea to PDF 2.0 and adds features such as MathML support; it does not replace PDF/UA-1.
• The Matterhorn Protocol: the PDF Association’s testing model for PDF/UA-1. Version 1.1 lists 136 failure conditions grouped into 31 checkpoints: 87 can be determined by software alone, 47 usually need human judgement (for example, whether text that looks like a heading is tagged as one, or whether alt text is accurate) and 2 have no specific test. That split is why an automated pass is never the whole test.

Testing PDFs vs Word, Excel and PowerPoint

Office files and PDFs need different testing paths:

• Word, Excel and PowerPoint: use the built-in Accessibility Checker (Review, then Check Accessibility), then check headings in the Navigation Pane, alt text on images, table header rows, sheet names in Excel, slide titles and reading order in PowerPoint, and meaningful link text. Fixing the source file is usually far quicker than fixing the PDF exported from it.
• PDFs: check that the file is tagged, then test the tag tree, reading order, alt text, tables, forms, bookmarks and metadata with a PDF checker, then confirm with a screen reader and the keyboard.

How to Do Document Accessibility Testing: Step by Step

1. Start with the source. If the PDF came from Word, PowerPoint or InDesign, check and fix the source first and re-export with tags.
2. Run an automated checker. The free PDF Accessibility Checker (PAC) tests against PDF/UA and WCAG; Adobe Acrobat Pro has a built-in Accessibility Checker as well. WebAIM’s guide to PDF accessibility in Acrobat covers the Acrobat workflow.
3. Inspect the tags and reading order. In Acrobat, open the Tags and Reading Order panels. Check that headings use H1 to H6 tags in a logical order, lists use list tags, tables have header cells, and decorative content is marked as an artifact.
4. Check alternative text and links. Every informative image needs alt text, and link text should make sense on its own.
5. Test forms. Fields must have labels (tooltips in PDF), a logical tab order and clear instructions.
6. Check document properties. A meaningful title set to display in the title bar, the document language, and bookmarks for long documents.
7. Test with a screen reader and keyboard. Read the document with NVDA or JAWS and Acrobat Reader, move by headings, Tab through links and fields, and confirm reading order. Our screen reader testing guide covers the basics.
8. Check colour and contrast for text and important graphics.

The University of Washington’s guide to checking PDFs for accessibility is a clear, step-by-step companion to this process.

Document Accessibility Testing Tools (Including Free Section 508 Options)

No single tool proves a document is accessible, but the right combination finds most problems quickly. These are the tools our testers use:

If you are looking for “508 testing software”, note that every tool above checks only part of WCAG. Section 508 conformance for a document still needs a person to judge alt text, reading order and meaning.

Document Accessibility SDKs and APIs for Automated Testing

If you are looking for a document accessibility SDK or a PDF accessibility testing API, two options are worth knowing. The veraPDF validation library is available as a Java archive through Maven for developers who want PDF/UA checks inside their own software, as well as a desktop app and a command line application. Adobe’s PDF Accessibility Auto-Tag API automatically tags tables, paragraphs, lists and headings in native and scanned PDFs. Both are useful in a publishing pipeline, but auto-tagging and automated validation are a starting point: someone still has to review reading order, alt text and table headers before a PDF can be called accessible.

WCAG Success Criteria Most Relevant to Documents

Does WCAG 2.2 change PDF testing? Not much. PAC’s own introduction to PAC 2026 notes that its technical tests are based on WCAG 2.1, because the improvements in WCAG 2.2 are relevant to websites and PDF viewer programs rather than to PDF document content. PAC also runs additional quality checks, which are recommended best practices rather than an official standard.

Common Accessibility Issues Found in Documents

Untagged or Scanned PDFs

A PDF with no tags, or a scanned image of a page, gives a screen reader nothing to read. Scanned documents need OCR, and the recognised text must be checked for errors.

Missing Heading Structure

Documents without proper headings are hard for screen reader users to navigate; large bold text is not a heading unless it is tagged as one.

Images Without Alternative Text

Visual content must include meaningful descriptions when it is needed to understand the document. Our alt text guide explains how to write them.

Incorrect Reading Order

Screen readers may present content in a confusing sequence if the document structure is not properly defined, particularly in multi-column layouts, sidebars and text boxes.

Inaccessible Tables

Complex tables often lack header cells and relationships, making them difficult to interpret.

Decorative Content Not Marked as Artifacts

Page numbers, running headers, lines and background shapes get read aloud on every page.

Unlabelled Form Fields and Unclear Links

Fields with no tooltip are announced as “edit text”, and links such as “click here” give no context.

Missing Bookmarks, Title or Language

Long documents without bookmarks are hard to move around, and a missing language setting makes screen readers mispronounce the text.

Automated Checks vs Manual Document Testing

Checkers like PAC and Acrobat are essential for finding missing tags, alt text, title and language settings quickly. They cannot judge whether alt text is accurate, whether the reading order makes sense, or whether a heading is tagged at the right level. Like automated website testing, they are the first step; human review with assistive technology confirms the result.

Document Accessibility Testing Checklist

For a full guide to creating accessible PDFs yourself, read our PDF accessibility guide.

How a Professional Document Accessibility Audit Works

If you publish more than a handful of documents, testing every file yourself is slow, and fixing them one by one is slower. A HalfAccessible document accessibility audit is led by founder Mohammad Shadab Saifi (CPACC, WAS, CPWA and DHS Section 508 Trusted Tester) and works like this:

1. Inventory and sample. We group your PDFs, Word, Excel and PowerPoint files by template and purpose, and prioritise forms, applications, policies and anything people need to use a service.
2. Test. Each sampled document goes through PAC or veraPDF, a manual tag, reading order, table and form review, and an NVDA screen reader and keyboard pass, mapped to WCAG and PDF/UA.
3. Report. Every issue comes with its location, the WCAG criterion or Matterhorn failure condition, its severity and how to fix it in the source file or the PDF. See a sample audit report.
4. Fix and re-test. Our PDF and document remediation team repairs the files or your templates, then we re-test them.

Document work is quoted per document set, because 10 simple letters and 10 long, form-heavy reports are very different jobs. Our guide to accessibility audit cost explains what moves the price. Websites are audited at fixed prices through our accessibility audit services: a $500 Quick Audit for up to 5 templates or a $2,000 Complete Audit for up to 25 templates or key user flows, both on our pricing page. US federal suppliers can pair documents with an ADA and Section 508 accessibility audit.

A document accessibility audit is a good fit if you:

• publish applications, forms, policies or statements as PDFs that people need to use a service;
• are a public body working toward the ADA Title II dates (use our government accessibility audit request);
• sell software or services to government buyers who ask for an accessibility conformance report (see VPAT and ACR documentation);
• have a library of reports or brochures to fix and want a fixed quote for PDF and document remediation.

Work With Us

Not sure whether your PDFs, Word documents or reports would pass? Tell us what you publish and we will reply within 2 business days with a recommended scope.

First conversation or not sure of scope? Book a free 30-minute call to tell us what you publish, find out where your documents stand and get a quote for testing or remediation. Prefer to write it down? Get a free accessibility needs assessment (four short questions, no commitment).

Need technical answers now? Book the $100 one-hour consultation, a hands-on session to walk through an existing PDF audit, go over failing files with the person who builds them, or review a sample of your documents live.

Ready to fix a document library? See our PDF and document remediation service, or start a $500 Quick Audit of the website your documents live on.