Three layers, reported separately. The file. The viewer software rendering it. And the integration, meaning the handful of configuration choices your own code made about how the two meet. A finding filed against the wrong layer gets sent to the wrong team and comes back unfixed, so keeping them apart is not tidiness. It is the difference between a report somebody can act on and a report that circulates for a month.
And one fact reverses the answer most people expect, so it belongs in the first paragraph. A PDF you link to is its own web page. A PDF embedded in your page is not. Which means the document stops being a separate thing with its own verdict and becomes part of yours.
An Embedded PDF Is Not Its Own Web Page
The standard defines a web page as a non-embedded resource obtained from a single address, and it says so twice, once in the definition and once in a note attached to it, because the word carries weight. A linked PDF is non-embedded, so it is a page and gets judged on its own. An embedded one is not, so it is part of the page holding it.
Follow that through and the consequence is sharp. Conformance is for full pages only and cannot be achieved if part of a page is excluded. There is no such thing as a page that conforms apart from the viewer sitting in the middle of it. So if the document inside the frame cannot be read, the page around it does not pass, however clean the rest of the template is.
Four rules go further still and apply to everything on the page whether you rely on it or not, because failing them interferes with any use of the page at all. Those four are the rule about audio that starts on its own, the rule against trapping the keyboard, the flashing threshold and the rule that anything moving has to be stoppable. A viewer that swallows the keyboard is the one that comes up in practice, and it cannot be scoped out of a claim by calling it third-party code.
The Three Layers, and Who Repairs Each
| Layer | What fails here | Who can fix it |
|---|---|---|
| The document | No tags, wandering reading order, tables built as pictures, images with no alt text, unlabelled form fields | Whoever owns the source file. Nothing in the viewer can invent structure the file never had |
| The viewer | Toolbar buttons with no accessible name, a keyboard trap, low-contrast chrome, controls that cannot be reached, focus behavior you cannot see | The vendor. Reporting the defect and picking a different viewer are the only two moves your team has here |
| The integration | Which display mode, which controls are switched on, whether focus jumps into the viewer on load, whether the frame is named, whether a download route exists | Your team. These are lines in your own code and they are the fastest wins on the page |
The Integration Layer Is Yours, and It Is Bigger Than It Looks
Teams treat an embedded viewer as a black box and it is nothing like one. Take the most widely deployed example, Adobe's embed interface, and read what its own documentation offers. There are four display modes, which are full window, sized container, inline, and a lightbox that opens over the page. That is a layout choice on the surface and an accessibility choice underneath, because the modes do not behave the same way.
Whether the viewer takes focus when the document finishes rendering is set per mode. Full window takes it by default. Sized container and inline do not. Lightbox always takes it, and the documentation says that cannot be changed. So the same file, in the same viewer, on two pages of the same site, can either leave a keyboard user where they were or move them somewhere they did not ask to go, purely because of a string in the configuration.
Two more configuration facts are worth knowing before you test. Form editing works only in full window mode, so a fillable PDF embedded in a sized container is a document somebody can look at and not complete. And commenting is on by default, with its own toolbar of drawing and markup tools, which means a page that never intended to offer annotation is offering it anyway until somebody switches it off.
None of that is the vendor's fault and all of it is testable, which is what makes this layer worth reporting on its own. Write down the mode, the toggles, and what focus does on load, and half the surprises in the report explain themselves.
The Viewer Has Findings of Its Own, and They Move
Viewer chrome is a user interface like any other, and it carries the ordinary obligations. Every control needs a name a screen reader can announce. The keyboard has to get in and back out again. Text has to meet contrast. What makes it awkward is that none of it is yours, and it changes under you without your site changing at all.
The vendor's own release notes make the point better than we could. Adobe's notes for 29 July 2026 record two fixes in that release. The viewer was being cut off from the PDF area, and the "Opening Document 100%" loading text was failing WCAG AA contrast. Those are Adobe's reported fixes on their own product rather than anything we reproduced, and that is exactly why they are useful here. A defect in the loading state of an embedded viewer is a defect on your page, it appeared without a deployment on your side, and it disappeared the same way.
So put the viewer version in the report, alongside the browser and the assistive technology. A finding against a moving target needs a date attached or nobody can tell later whether it was fixed or simply never reproduced.
A Download Link Is Not an Answer
The reflex fix is to add a download link and consider the matter closed. It is a good thing to add and it is not a replacement, and the reason is that a viewer usually delivers more than viewing. Filling a form. Commenting. Searching a long document. Where the viewer does the work, handing somebody the raw file hands them the content and takes away the function.
The test is simple enough to run in a meeting. Write down what a sighted mouse user can do in that viewer. Then ask whether the download route gives all of it to somebody who cannot use it. If the answer is no, the download is a convenience rather than an alternative, and the honest options are to fix the integration or to build a real equivalent, and what a replacement has to satisfy is four conditions rather than one.
How to Test One in an Afternoon
- Tab into the viewer and back out again. Getting in is easy. Getting out is where viewers trap people, and a trap is a failure of a rule that applies whether or not you rely on the technology.
- Load the page and see where focus went. If the viewer took it, note the display mode, because the mode is usually the reason and sometimes the only lever.
- Name every control you can reach. Listen to the toolbar with a screen reader. Buttons announcing as button are a viewer finding, not a document one.
- Read the document itself by ear. Headings, reading order, tables, alt text. This is the file layer, and it fails the same way it would if you had opened the file directly.
- Zoom to 400% and look for what disappeared. Fixed-height viewer containers are where reflow findings hide, and the viewer often gets its own scrollbar inside the page's.
- Turn the technology off. Block the viewer script and see what the page does. What is left should still make sense, which is what non-interference means in practice.
Steps one, three and five belong to the viewer. Step four belongs to the file. Step two and step six belong to you. Sort the findings that way as you go, because sorting them afterwards from a page of notes is much harder than it sounds.
One honest limit
We did not test any viewer, browser or file to write this page, and the vendor behavior described here comes from published documentation rather than from our own runs. On an actual site we test what is in front of us and name the versions. A combined document and viewer engagement is scoped rather than counted, so start at contact, or take the two halves separately through the PDF accessibility audit and the iframes and embeds audit.