PDF accessibility for developers: Meeting WCAG 2.2, Section 508, and PDF/UA with an SDK

If your application serves PDFs, those documents must meet accessibility standards — Web Content Accessibility Guidelines (WCAG) 2.2, Section 508, and PDF/UA — so screen reader users, keyboard-only users, and people relying on assistive technologies can read and interact with them. Regulations like the Americans with Disabilities Act (ADA)(opens in a new tab), Section 508(opens in a new tab), and the European Accessibility Act (EAA)(opens in a new tab) require it.

The challenge is that PDF accessibility involves multiple standards, platform-specific behaviors, and ongoing testing. Nutrient SDKs handle the heavy lifting across web, iOS, and Android — so you can focus on your application, not accessibility plumbing.

The standards you need to meet

Four standards define the rules for PDF accessibility. Here’s what each one covers and where it applies.

WCAG 2.2

The WCAG 2.2(opens in a new tab) guidelines apply to all web content, including PDFs. Most regulations reference Level AA, which requires text contrast ratios of 4.5:1, keyboard operability, and meaningful content structure. WCAG 2.2 also added criteria for focus appearance and dragging movements, which is relevant for interactive PDF viewers.

Section 508

Section 508(opens in a new tab) is a U.S. federal law that references WCAG 2.0 Level AA. It applies to federal agencies, their vendors, and documents published on government websites. Meeting WCAG 2.2 AA satisfies Section 508.

PDF/UA

PDF/UA (ISO 14289) defines the technical requirements for the PDF file itself: all content tagged or marked as artifacts, a logical reading order, alt text on images, embedded fonts, and a specified language. PDF/UA-2(opens in a new tab), published in 2024, adds new structure tags and builds on PDF 2.0.

European Accessibility Act

The EAA(opens in a new tab), effective as of June 2025, requires businesses operating in the EU to make digital products accessible, referencing the EN 301 549(opens in a new tab) standard. PDFs published as part of digital services fall under this requirement.

PDF/UA vs. WCAG vs. Section 508: Which standard applies?

The three standards answer different questions, and most projects need more than one. WCAG defines what accessible content means, Section 508 and the EAA define who is legally required to comply, and PDF/UA defines how the PDF file itself must be built. A 508-compliant PDF is one that meets WCAG 2.0 Level AA; a PDF/UA-conformant file goes further by pinning down the file-format requirements WCAG leaves open.

In practice: Content published for a U.S. government audience needs Section 508, which WCAG 2.2 AA satisfies; EU-facing digital services need the EAA via EN 301 549; and the reliable way to make the PDF file itself hold up under assistive technologies is PDF/UA conformance. The PDF/UA compliance guide covers the file-format requirements in depth.

What makes a PDF accessible

Here’s what you need to get right — and how Nutrient helps at each step.

1. Document tags

Tags define the structure — headings, paragraphs, lists, tables, figures. Without them, a screen reader sees flat text with no way to navigate.

Nutrient Web SDK renders tagged PDFs and PDF/UA documents with their full structure intact, so screen readers can navigate by heading, table, or section out of the box.

2. Reading order

Tags must reflect how content should be read, and not where it sits on the page. A two-column layout needs tags that read left column first, then right.

Nutrient preserves and renders the tag-defined reading order. Developers can customize focus order with the instance#setPageTabOrder() API.

3. Alt text on images

Every meaningful image needs a text alternative. Decorative images should be marked as artifacts so screen readers skip them.

4. Descriptive link text

Replace “click here” and other vague text with text that describes the destination, e.g. “download the accessibility report” or “view WCAG 2.2 guidelines.”

5. Color contrast

WCAG 2.2 Level AA requires 4.5:1 for normal text and 3:1 for large text. Nutrient’s default light and dark themes meet WCAG 2.2(opens in a new tab) Level AAA for text contrast and at least AA for icons, with no custom theming required.

6. Labeled form fields

Every form field needs a label that screen readers can announce, and users need to Tab between fields in a logical order. Nutrient renders form fields with proper labels and supports keyboard-only interaction across all platforms. See the forms guide for more information.

7. Document properties

Set the document language, add a descriptive title, and embed all fonts. PDF/UA requires all three.

8. Security settings

Some PDF encryption blocks screen readers. If you apply security, keep the accessibility permission enabled.

9. Scanned PDFs

Scanned documents are image-only — no text layer, no screen reader access. You need optical character recognition (OCR) to extract text before any other accessibility step applies.

Nutrient provides OCR across Java, iOS, Android, and .NET — turning scanned pages into searchable, accessible text layers.

How Nutrient handles accessibility for you

Instead of building accessibility support from scratch, Nutrient SDK covers the core WCAG requirements across platforms:

Nutrient SDK simplifies building accessible PDFs — for a fully managed option, see the document accessibility SDK — with robust features for web, iOS, and Android platforms.

Web

Nutrient Web SDK provides:

• Screen reader support — The user interface (UI) works with NVDA(opens in a new tab) and JAWS(opens in a new tab). Menus, buttons, and annotations are correctly announced with their name, role, and value.

• Keyboard-only annotation placement — Users can place text, note, and comment annotations using Enter, Space, and arrow keys.

• Text-to-speech — Extract text from any PDF and pass it to the browser’s speech synthesis. See the TTS guide for more information.
• WCAG-compliant rendering — Complies with WAI-ARIA(opens in a new tab) guidelines. Tagged PDFs and PDF/UA documents render with their full structure.
• Localized accessibility strings — All built-in strings are localized. Customize them with the localization guide.
• Keyboard-navigable signatures — Users can type signatures without a pointer device.
• Accessible forms — Form fields are labeled and keyboard-navigable. See the forms guide for more information.

For more details, read how we’re improving accessibility on Nutrient Web SDK.

iOS

Nutrient iOS SDK supports:

• VoiceOver — PDF page text is exposed with intelligent paragraph separation. Bookmark lists, document information, and the comments UI all support VoiceOver.
• Reader View — Reformats content with adjustable text sizes, including larger accessibility sizes. Helps with cognitive accessibility (WCAG 1.4.8).
• Dynamic Type — Respects system font size preferences.
• Dark Mode — The UI follows system Dark Mode. Page content can optionally render in inverted mode.
• Speak Selection — iOS reads selected text aloud.
• Hardware keyboard — Full keyboard navigation with shortcuts for annotation selection.
• Trackpad and mouse — Enhanced pointing device support. See the trackpad guide for more information.

Explore the iOS demo:

Android

Nutrient Android SDK supports:

• TalkBack — Navigating via keyboard or touch is accompanied by descriptive voice announcements for every UI element. Install the Android Accessibility Suite(opens in a new tab) to enable it.
• Keyboard navigation — Full Tab and arrow key navigation throughout the UI. Works with TalkBack. Read more in our post on keyboard navigation in the Android SDK.
• Screen reader integration — Build text-to-speech using android.speech.tts.TextToSpeech(opens in a new tab) and PdfActivity. See the screen reader guide and example code(opens in a new tab).
• Reader View — Simplified, reflowable layout for easier reading (WCAG 1.4.8). Enable with the enableReaderView setting in PdfActivityConfiguration. See the Reader View guide for more information.
• Dark Mode and theming — Customize the UI for better contrast. See customizing appearance.

Explore the Android demo:

Testing accessibility

Building accessible PDFs is only half the work — validate with these tools:

• PDF Accessibility Checker (PAC)(opens in a new tab) — Free PDF/UA conformance checker.
• Screen readers — Test with NVDA(opens in a new tab) (free, Windows), JAWS(opens in a new tab) (commercial, Windows), or VoiceOver (macOS/iOS).
• Firefox Accessibility Inspector(opens in a new tab) — Built into DevTools, useful for web-based PDF viewers.
• WebAIM Contrast Checker(opens in a new tab) — Verify color contrast ratios against WCAG thresholds.

Test across multiple assistive technologies, since each interprets PDF structure differently.

Conclusion

PDF accessibility requires tagged structure, alt text, reading order, form labels, contrast, and testing — across WCAG 2.2, Section 508, and PDF/UA.

Nutrient SDKs handle this across web, iOS, and Android with screen reader support, keyboard navigation, WCAG AAA contrast, text-to-speech, Reader View, and OCR for scanned documents. Instead of building accessibility infrastructure yourself, integrate Nutrient and ship compliant PDF applications faster.

Ready to get started? Explore Nutrient SDK today and build accessibility-first applications. Contact our Sales team for more details, and try the product for free to see how it can benefit your project.

Try Nutrient for free or explore the demo.

FAQ