The European Accessibility Act (Directive (EU) 2019/882) came into force across all 27 Member States on 28 June 2025. 2026 is the first full year national authorities are actively supervising against it, and the first lawsuits were filed in France in November 2025. For pharma communications teams, this shifts accessibility from a future risk into an active legal liability.
We recently published a WCAG 2.2 audit of two AbbVie Belgian patient-facing sites, jepeux.be and ikkanwel.be. The point was not to single out one brand. AbbVie's sites are well built by industry standards. The point was to show what a real audit against WCAG 2.2 looks like, and what the typical gaps are on a pharma corporate estate in 2026.
What we found there is what we find almost everywhere.
How do you run a WCAG 2.2 audit on a pharma website
A credible audit is not a scan report. Automated tools catch roughly 30 to 40 percent of accessibility barriers, according to accessibility testing research. The remaining 60 percent needs manual testing with assistive technologies across real user workflows: screen readers, keyboard-only navigation, voice control, and zoom to 400 percent.
The method we use on pharma estates has four stages:
- Scope mapping: patient portals, disease awareness sites, HCP platforms, and any hosted PDFs or videos are all in scope under the EAA.
- Automated scan across the design system to catch mechanical failures at volume. Our internal sample report scanned 1,098 nodes across three pages to establish a design-system baseline.
- Manual review of critical user journeys with a screen reader and keyboard, focused on consent flows, forms, and clinical content.
- Prioritised backlog, split between design-system fixes (which cascade across the estate) and page-level fixes.
AI assists the review at the scan and triage stages. Designers and accessibility specialists decide what to fix and how. That split matters, because WCAG conformance is a design judgement, not a scanner output.
What are the most common WCAG failures on pharmaceutical websites
Four patterns repeat across almost every pharma site we audit. They are worth flagging for anyone responsible for a digital estate in the EU.
Corporate colour palettes fail contrast at small text sizes. WCAG 2.2 AA requires a 4.5:1 contrast ratio for normal text. Most pharma brand books were written years before accessibility became a legal requirement, and the palette guardians never had WCAG in the room. Pale grey body text on white, or brand-coloured links that fall below threshold, are the single most common failure we log.
Cookie banners and consent flows are frequently the least accessible part of the site. That is ironic, because they are the first thing every visitor touches. Keyboard traps, focus that vanishes into the modal, buttons with no accessible name, and consent choices that cannot be operated by a screen reader are routine. On a patient-facing pharma site, that means a blind user cannot legally consent before entering the content.
PDFs hosted on the site are almost never tagged for screen readers. Patient brochures, dosing guides, and information leaflets are usually exported straight from InDesign or Word without accessibility tags, reading order, or alt text. Under the EAA, any document that is part of the service is in scope.
Video content rarely has proper captions or audio description, even when it is patient-facing. Auto-generated YouTube captions do not meet WCAG 2.2. Health information cannot rely on machine transcription of drug names and side effects.
How to make patient brochure PDFs accessible for screen readers
PDFs are the quiet failure point. They sit on the site for years, get updated by MedInfo or Regulatory without a designer in the loop, and never get audited.
Accessible pharma PDFs need tagged structure (headings, lists, tables), a defined reading order, alt text on every image including molecular diagrams and dosing charts, language metadata set correctly, and form fields that are labelled if the PDF is interactive. For patient leaflets translated across markets, each language version needs its own accessibility pass. A French version tagged as English will confuse every screen reader on the market.
The workable pattern we recommend to clients: fix the PDF template once at the design-system level, then run every new export through a short QA checklist before it goes live. Retrofitting hundreds of legacy PDFs page by page is not economic. Fixing the template and the process is.