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

If your application serves PDFs, evaluate both the documents and the viewer for accessibility. WCAG, PDF/UA, and legal requirements may apply, depending on the entity, service, and jurisdiction. Examples of legal requirements include Section 508(opens in a new tab), the Americans with Disabilities Act (ADA)(opens in a new tab), and the European Accessibility Act (EAA)(opens in a new tab).

The challenge is that PDF accessibility involves multiple standards, platform-specific behaviors, and ongoing testing. Nutrient SDKs provide accessibility features for web, iOS, and Android. Your source PDFs, custom UIs, and complete application still require validation.

Standards and legal requirements to evaluate

The following standards and laws address different parts of accessibility. Determine which apply to your project.

WCAG 2.2

The WCAG 2.2(opens in a new tab) guidelines apply to all web content, including PDFs. Level AA criteria include keyboard operability, meaningful structure, and minimum text contrast of 4.5:1 for normal text or 3:1 for large text. WCAG 2.2 added criteria for focus visibility and dragging movements that are relevant to interactive PDF viewers; focus appearance is a Level AAA criterion.

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. WCAG conformance addresses the referenced content criteria; evaluate any other applicable Section 508 requirements separately.

PDF/UA

PDF/UA (ISO 14289) defines the technical requirements for the PDF file itself. These include 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) applies to specified products and services, including e-commerce, consumer banking, and eBooks, with requirements applying from 28 June 2025. It doesn’t cover every document from every EU business. Assess whether your service and PDFs are in scope, including exemptions and national implementation. EN 301 549(opens in a new tab) is a related information and communication technology accessibility standard.

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. Section 508 incorporates WCAG 2.0 Level AA for covered content, while PDF/UA defines PDF structure requirements. File conformance and legal compliance are separate assessments.

In practice, establish the applicable legal and procurement requirements. Then evaluate the PDF and the application against the relevant technical standards. 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, and figures. Without them, a screen reader sees flat text with no way to navigate.

Nutrient Web SDK provides screen reader support. Test the reading and navigation experience with your actual tagged PDFs and target assistive technologies. The viewer doesn’t add missing semantic tags to the source file.

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.

Verify content reading order in the source PDF and in the target viewer. Developers can customize page tab order with instance#setPageTabOrder(); tab order doesn’t replace the document’s semantic reading order.

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. The Web SDK accessibility guide describes text and icon contrast goals for its default themes. Verify the contrast of your selected theme, custom controls, and PDF content; a viewer theme doesn’t fix low-contrast content in a PDF.

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 — adding searchable text layers. Correct OCR errors and add semantic structure before assessing accessibility.

Nutrient features that support accessibility

Nutrient provides features that support accessibility work. Availability varies by platform, and the features below aren’t a conformance certificate:

Nutrient SDK simplifies building accessible PDFs with features for web, iOS, and Android platforms. For document remediation capabilities, see the document accessibility SDK.

Web

Nutrient Web SDK provides:

• Screen reader support — The user interface (UI) works with NonVisual Desktop Access (NVDA)(opens in a new tab) and JAWS(opens in a new tab). The UI correctly announces the name, role, and value of menus, buttons, and annotations.

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

• Text-to-speech — Extract available PDF text and pass it to the browser’s speech synthesis. This doesn’t supply missing alternatives for non-text content. See the text-to-speech guide for more information.
• Accessible UI semantics — WAI-ARIA(opens in a new tab) attributes support assistive technologies. Test document reading and navigation separately from the viewer controls.
• 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 — The SDK exposes PDF page text 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 — Descriptive voice announcements accompany keyboard or touch navigation 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 provide screen reader support, keyboard navigation, text-to-speech integration, Reader View, and OCR capabilities across supported platforms. Combine the appropriate features with source-document remediation and application testing.

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