EAA 2026: Why Your PDFs Need Real, Selectable Text

TL;DR

The European Accessibility Act (EAA), in force since 28 June 2025, requires many customer-facing PDFs — invoices, statements, contracts, terms — to have extractable, real text so assistive technology can read them. A PDF that's just a screenshot or a flattened image of a page is inaccessible: a screen reader finds nothing to read. A real-text PDF is the necessary starting point for compliance. Convert: Web to PDF produces PDFs with genuine selectable text, clickable links, and embedded fonts — because it uses Chrome's print engine, not a screenshot. But be clear: real text is a prerequisite, not full accessibility. It does not tag the document, add alt text, or make it PDF/UA-compliant on its own. This post explains exactly where the line is.

The answer first: what the EAA actually requires of a PDF

A compliant customer-facing PDF must, at minimum, expose its content as actual text that assistive technology can extract and read aloud — not as a picture of text. That's the floor. Above the floor sit the things that make a document fully accessible: a logical reading order via tags, alternative text for images, correctly marked headings and tables, language metadata, and so on.

The EAA points to European harmonized standards — principally EN 301 549, which incorporates WCAG 2.1 Level AA — for the technical criteria, with PDF/UA (ISO 14289) as the recognized best-practice specification for accessible PDFs. The practical hierarchy looks like this:

1. Real, extractable text — the absolute prerequisite. Without it, nothing else matters, because there's nothing to read.
2. Tagged structure — reading order, headings, lists, tables marked so assistive tech understands the document's shape.
3. Alternative text and metadata — descriptions for images, document title, language.

A document can have step 1 and still fail steps 2 and 3. But a document that fails step 1 fails everything. That distinction is the entire point of this post, and it's where honest tools and marketing-hype tools part ways.

Why a screenshot-PDF is a compliance dead end

Here's the trap a lot of teams fall into. Someone needs a PDF of a web-based invoice or a statement, so they use a "capture the page as PDF" extension. Many of those extensions work by taking a screenshot — rasterizing the visible page into an image and wrapping that image in a PDF container.

To a human eye, that looks fine. To a screen reader, it's a blank wall. There is no text in the file at all — just pixels. A visually impaired customer running assistive technology gets nothing: no amount read aloud, no ability to select or search, no way to reflow the content at a larger size. From an EAA standpoint, that document doesn't just score poorly — it fails at the floor.

This is the single most common accessibility mistake in web-to-PDF workflows, and it's invisible until someone tries to actually use the file. It usually surfaces in the worst way: a customer complaint, an audit finding, or a legal query.

The two failure modes: screenshots and image-only scans

There are two ways a PDF ends up with no real text:

• Screenshot-based capture. A browser extension or tool renders the page to an image and embeds it. Fast, but produces an image-only PDF.
• Image-only scans. A paper document is scanned to PDF without OCR. Same result: pixels, no text.

Both need something extra to become accessible. A screenshot PDF needs to be regenerated from a real-text source. An image-only scan needs OCR to recognize the text before anything can be tagged. Neither is a good starting point when you could have generated real text from the start.

Where Convert: Web to PDF fits — and where it stops

Let's be scrupulously honest, because this is a compliance topic and hand-waving helps nobody.

What Convert: Web to PDF does: It renders the page currently in your browser into a PDF using Chrome's own print engine via the DevTools Protocol — the same engine behind Chrome's native "Print to PDF." The output contains genuine selectable text, clickable links, and embedded fonts. It is not a screenshot. A screen reader can extract the text; a user can select, search, copy, and reflow it. It clears the floor — the real-text prerequisite that a screenshot PDF fails.

What it does not do — and this matters:

• It does not produce a tagged / PDF-UA document. It doesn't add the logical structure tags that convey reading order, headings, and table relationships.
• It does not add alternative text to images. That's authored content a human has to supply.
• It does no OCR. If a source page contains an image of text (say, a logo with words baked in, or an embedded scanned figure), that image stays an image. Real selectable text comes from the parts of the page that were real text to begin with.
• It does not make a document "legally accessible" by itself. Real text is the necessary starting point, not the finish line.

So the accurate framing is: Convert: Web to PDF gets you the prerequisite — a real-text PDF instead of a screenshot — and leaves the remediation steps (tagging, alt text) to a dedicated accessibility remediation tool or workflow. Naming that gap plainly is the point. A tool that claims to make any web page "fully accessible" or "PDF/UA-compliant" in one click is overselling; that's not how PDF accessibility works.

The contrast that actually matters

Read that table carefully. The jump from row one to row three is the jump from unusable to usable-and-fixable. That's the jump that matters most, because you cannot remediate your way out of a screenshot — there's nothing to tag. You have to start with real text. Convert: Web to PDF exists to make sure you start there.

Who this actually helps

Businesses producing customer-facing documents

If your customers receive PDFs — invoices, statements, order confirmations, contracts, T&Cs — the EAA scope likely reaches you. The right first move is to make sure those documents are generated with real text, not captured as images. If your document pipeline pulls from web-rendered pages, generating a real-text PDF (rather than a screenshot) means the output is remediable. From there, a remediation step adds tags and alt text.

The wrong move is to discover, mid-audit, that your archive is full of screenshot PDFs that can't be fixed without regenerating everything.

Government and public-sector bodies

Public-sector accessibility obligations often run ahead of and alongside the EAA. The same logic applies with less wiggle room: image-only PDFs are non-starters. Real-text generation plus remediation is the path.

One important caveat for official documents specifically: where a site or system offers its own official PDF — a signed statement, a certificate, a government form — that authoritative document is the one to use and archive. Convert: Web to PDF is for capturing the web content around and beyond those official artifacts, not for re-manufacturing an official record. Never treat a web-rendered capture as a legally authoritative substitute for a document the issuer provides.

Educators and institutions

Course materials, handouts, and administrative PDFs distributed to students carry accessibility duties too. A lecturer who saves a web article or a set of notes as a screenshot has handed disabled students an unreadable file. Generating real-text PDFs from the start — and, for anything formally distributed, running remediation — is the responsible baseline. Students working the other direction (turning their own web reading into clean study PDFs) benefit from real text for a related reason: it's what search, screen readers, and AI study tools can all actually parse.

A practical, honest workflow

Here's a realistic sequence that respects both the standard and the limits of any single tool:

1. Start from real text, never a screenshot. When capturing web content to PDF, use a real-text generator. In Convert: Web to PDF, the default mode preserves the page's real text through Chrome's print engine. For long, article-style pages, Article Mode (a Readability reader view) produces a clean, text-focused PDF — just note it may drop <pre> code blocks, so use default mode for code-heavy technical pages.
2. Check the output is really text. Open the PDF and try to select a sentence with your cursor. If text highlights, you have real text. If nothing selects, you captured an image — stop and regenerate.
3. Keep source fidelity where it matters. Real links stay clickable, fonts stay embedded, and the text stays searchable — all of which help both assistive tech and later remediation.
4. Remediate for full compliance. For documents that must meet EN 301 549 / WCAG 2.1 AA or PDF/UA, take the real-text PDF into a dedicated remediation tool (or a remediation service) to add tags, reading order, alt text, and metadata. This is the step Convert: Web to PDF does not do — and doesn't claim to.
5. Use the issuer's official PDF when one exists. For authoritative records, download the source's own accessible PDF rather than capturing the web view.

This workflow is deliberately unglamorous. It reflects how PDF accessibility genuinely works: real text first, structure second, and no single browser extension does the whole job.

Why "selectable text" is the load-bearing phrase

It's worth dwelling on why real text is the hinge everything turns on, because it's easy to underrate.

Selectable text is what lets a screen reader announce content. It's what lets a low-vision user reflow and enlarge without pixelation. It's what lets a search find the document. It's what a remediation tool has to work with to build structure. And — stepping outside accessibility for a second — it's also what makes a PDF useful to search engines, to your own archives, and to modern AI tools that ingest PDFs.

Every one of those benefits collapses to zero the moment the "PDF" is really a picture. That's why the difference between a screenshot capture and a real-text render isn't a nice-to-have — under the EAA, it's the difference between a document that can be made compliant and one that can't. If you want the technical detail on how the real-text render is produced, the tool page and FAQ cover it, and the case for local, real-text output over uploads is made in why a PDF converter should never upload your files.

Frequently asked questions

Does Convert: Web to PDF make my PDFs EAA-compliant?

No — and any tool that claims one-click EAA compliance is overselling. It produces the prerequisite: a real-text PDF (not a screenshot) that a screen reader can read and that a remediation tool can work with. Full compliance also needs tagging, reading order, and alt text, which are separate steps it doesn't perform.

What's the difference between "selectable text" and "accessible"?

Selectable text means the content is real text you can highlight, search, and extract — the necessary floor. Accessible means the document also has a tagged logical structure, alt text for images, and proper metadata so assistive technology can navigate it fully. You need the first to have any shot at the second.

Why is a screenshot PDF a problem?

Because it contains no text — only an image of the page. A screen reader finds nothing to read, a user can't select or search, and it can't be remediated without regenerating from a real-text source. It fails accessibility at the most basic level.

Does the extension do OCR to turn images into text?

No. It has no OCR. Real selectable text comes only from the parts of a page that were already text. An image of text (a logo, an embedded scan) stays an image. If you need to convert scanned images to text, that requires a separate OCR tool.

Which standards does the EAA rely on for PDFs?

Chiefly EN 301 549, which incorporates WCAG 2.1 Level AA, with PDF/UA (ISO 14289) as the recognized best practice for accessible PDF structure. The common thread across all of them is that content must be real, extractable text with a logical, tagged structure.

For an official document like a signed statement, should I use the extension?

Use the issuer's own official PDF for anything authoritative — a signed statement, certificate, or form. Convert: Web to PDF is for capturing web content, not for manufacturing an official record. Where an authoritative PDF exists, that's the accessible, compliant source to keep.

Does real-text output help beyond accessibility?

Yes. The same selectable text makes the PDF searchable, archivable, and parseable by AI study tools — the flip side of the same coin. A screenshot fails all of those the same way it fails a screen reader.

Bottom line

The European Accessibility Act draws a hard line at the floor: a customer-facing PDF must expose real, extractable text, or it's inaccessible before any other consideration. Screenshot-based captures and un-OCR'd scans fail there and can't be remediated in place — you have to start over with real text.

Convert: Web to PDF gets you cleanly over that floor: it renders the page with Chrome's print engine into a PDF with genuine selectable text, clickable links, and embedded fonts — not a screenshot. Be clear-eyed about the rest: it does not tag documents, add alt text, or produce PDF/UA output, and that remediation is a separate, necessary step for full compliance. Used honestly — real text first, remediation second, and the issuer's official PDF for authoritative records — it's the right starting point for a workflow that can actually reach the standard, instead of a screenshot that never can.