TL;DR
The European Accessibility Act (EAA, Directive 2019/882) has been in force since June 28, 2025, and through 2026 enforcement is ramping up. Customer-facing PDFs — invoices, statements, contracts, policy pages, product info — must be accessible, which in practice means real, selectable, machine-readable text that assistive technology can parse, aligned with PDF/UA and WCAG 2.1 AA. A flat, screenshot-style PDF fails that test instantly: a screen reader sees one big image and nothing else. Convert: Web to PDF produces true PDFs with selectable text, real headings, working links, and embedded fonts — the same output as Chrome's native print engine — so the documents you capture start from an accessible foundation instead of a dead image.
The short answer: image PDFs can't be accessible
If you take one thing away: a PDF that is secretly an image of a page can never be made WCAG- or PDF/UA-compliant, no matter what you do to it afterward. There is no text to read, no heading structure to navigate, no link to follow. Many browser extensions and "screenshot to PDF" tools produce exactly this — a flat raster wrapped in a PDF container. Under the EAA, that's a non-starter for any document a customer might need to read with assistive technology.
A real PDF — one generated by a print engine rather than a screenshotter — carries the text as text, preserves the heading levels, keeps links live, and embeds fonts. It's not automatically fully PDF/UA-tagged, but it's the only kind of capture you can build accessibility on. You can't tag pixels.
What the EAA actually requires for documents
The EAA aims to harmonize accessibility rules across the EU single market. For digital documents, the relevant standard is EN 301 549, which adopts WCAG 2.1 Level AA as its benchmark, and for PDFs specifically the industry target is PDF/UA (ISO 14289). In plain terms, an accessible PDF needs:
- Selectable, extractable text — not an image of text
- A logical reading order so a screen reader moves through content the way a sighted reader would
- Real heading structure (H1, H2, H3) for navigation
- Alt text on meaningful images
- Document language and title metadata
- Tagged tables, lists, and links
Different tools get you different distances up that list. The key insight is where you start: from real text and structure, or from a flat image.
| Capture method | Selectable text? | Heading structure preserved? | Links live? | Accessible foundation? |
|---|---|---|---|---|
| Screenshot-to-PDF extension | No (image only) | No | No | No — dead end |
| Online URL→PDF (PrintFriendly, PDFCrowd) | Usually yes | Sometimes flattened | Sometimes | Partial; can't reach gated pages |
| Browser "Print → Save as PDF" | Yes | Often, but breaks on modern CSS | Yes | Good, with layout caveats |
| Convert: Web to PDF (local) | Yes | Yes (Article Mode preserves semantics) | Yes | Strong starting point |
(Note: no automated capture tool produces a fully PDF/UA-tagged document with zero human review. Alt text and final tag verification still need a person and a checker like PAC or Adobe's accessibility tools. But starting from real text instead of an image is the difference between "needs review" and "impossible.")
Where web-page-to-PDF capture fits in an EAA workflow
A surprising amount of regulated content lives on web pages before it ever becomes a PDF: a terms-of-service page, an account statement rendered in a customer portal, a policy document published as HTML, a knowledge-base article. When compliance or legal teams need a fixed, archivable, accessible version of that page, the capture step decides whether the result is salvageable.
Here's a realistic scenario. A compliance officer at an EU fintech needs to archive the customer-facing version of a fee-schedule page — the exact thing a customer with a screen reader would have seen — as evidence and as an accessible downloadable. The page sits behind a login. An online converter can't reach it (it only sees the public web), and a screenshot tool would produce an unreadable image. Capturing it locally with a tool that uses the authenticated session and outputs real selectable text gives them a document a remediation team can actually tag and ship.
How to capture an accessible-ready PDF from a web page
- Install Convert: Web to PDF — free, no account.
- Open the page, including login-protected portals. The extension uses your existing session, so gated content captures correctly.
- Use Article Mode to strip navigation, ads, and clutter that would muddy the reading order, leaving the main content with its heading hierarchy intact. Or remove specific distracting elements by hand.
- Set paper size and margins. Preview.
- Download. The output is a true PDF: selectable text, preserved headings, working links, embedded fonts.
- Hand off to your accessibility/remediation step — run it through a PDF/UA checker, confirm tags and reading order, add alt text where needed.
Because conversion runs entirely in your browser via Chrome's DevTools Protocol, sensitive customer pages never leave your device — which matters when the same documents fall under GDPR as well as the EAA.
Why "local and free" isn't a contradiction here
Compliance teams are used to accessibility tooling being expensive enterprise software. The capture step doesn't have to be. We build small, free, privacy-first extensions on principle — our manifesto commits to free-not-freemium and privacy-by-default — so the part of your EAA workflow that turns a live page into an accessible-ready PDF costs nothing and sends nothing to a server. The heavy remediation tooling (PAC, Adobe, axe) does what it does best on top of a clean foundation.
For accessible documents built from files rather than web pages — converting Markdown documentation, HTML reports, or CSV data into PDFs — Convert: Anything to PDF keeps text as text the same way.
Frequently asked questions
Does the EAA apply to my PDFs?
If you sell products or services to consumers in the EU and provide customer-facing digital documents — invoices, statements, contracts, forms, manuals — then in-scope documents must meet the EAA's accessibility requirements, which align with EN 301 549 / WCAG 2.1 AA and, for PDFs, PDF/UA. Scope depends on your sector and size; check with counsel for your specific obligations.
Can a screenshot-based PDF ever be made accessible?
No. A flat image has no text, no structure, and no links for assistive technology to read. You'd have to re-create the document from scratch. Always capture from a tool that outputs real selectable text.
Does Convert: Web to PDF produce a fully PDF/UA-tagged file automatically?
No automated capture tool does. What it gives you is the accessible foundation: real selectable text, preserved heading structure, live links, embedded fonts. Final PDF/UA conformance — verified tags, reading order, alt text — still needs a remediation pass and a checker. Starting from real text is what makes that pass possible.
Can it capture pages behind a customer login?
Yes. Conversion runs locally using your authenticated browser session, so portal pages, account statements, and gated policy documents capture correctly. Online converters can't do this — they only see public pages.
Will customer data leave my device?
No. The extension makes zero network requests during conversion. Everything happens in your browser, which keeps GDPR-relevant content on your machine.
What paper sizes and options does it support?
A3, A4, A5, Letter, Legal, Tabloid, and Ledger, with selectable orientation, margins, and scale per conversion.
Which browsers does it work on?
Any Chromium browser — Chrome, Edge, Brave, Arc, Opera, Vivaldi. Not Firefox or Safari.
Bottom line
EAA compliance for PDFs starts long before the remediation step — it starts at capture. Screenshot exports are dead on arrival; only real, selectable-text PDFs can be made accessible. Convert: Web to PDF gives you that foundation for free, locally, from any web page including login-protected ones — so your accessibility team builds on real text instead of trying to tag an image.