Accessibility in Digital Package Inserts: What WCAG 2.1 AA Means in Practice

RDC 885/2024 requires WCAG 2.1 Level AA compliance. But what does that mean in practice? And why would most pharmaceutical portals that claim to be "accessible" fail a serious audit?

WCAG 2.1 AA: what is actually required

The guidelines are organized into 4 principles, 13 guidelines, and 50 success criteria at Level AA. For digital inserts, the most relevant criteria include:

• Perceivable: Alt text for non-text content, semantic structure (proper headings, table headers), minimum 4.5:1 contrast ratio, text resizable to 200%
• Operable: Full keyboard accessibility, skip navigation links, descriptive headings for each insert section
• Understandable: Correct lang attribute, labels on search fields (not just placeholders)
• Robust: Correct ARIA roles on interactive components (TTS buttons, section selectors, audio controls)

The 5 most common mistakes in insert portals

1. "Accessible" PDF is not accessible: PDFs are significantly worse than native HTML for screen reader navigation, especially on mobile. RDC 885 requires web-native format.
2. Decorative headings: Using h2/h3 tags for visual style only, without respecting hierarchy, confuses screen reader navigation completely.
3. Audio controls without ARIA: TTS play/pause buttons without aria-label or aria-pressed are invisible to screen readers.
4. Dosage tables without headers: Without th with scope attributes, a screen reader reads table data as an incomprehensible linear sequence.
5. Invisible focus: Removing focus outline (outline: none) makes it impossible for keyboard users to know where they are on the page.

How to test correctly

1. Automated validators: axe-core, WAVE, Lighthouse. They capture about 30-40% of problems. Use as a first filter, not final validation.
2. Manual keyboard testing: Navigate the entire insert using only Tab, Enter, Escape, and arrows.
3. Screen reader testing: NVDA (Windows, free), VoiceOver (macOS/iOS), TalkBack (Android). Read the entire insert without seeing the screen.

The combination covers over 90% of accessibility problems. The remaining 10% requires testing with real users with disabilities, which we strongly recommend at least once before go-live.