Matterhorn 03-001 · PDF/UA-1 UA1:7.1-5

When a PDF's own actions make the page flash

Page or annotation actions produce flashing that can trigger photosensitive seizures.

What a screen reader actually does

Not a screen-reader issue — a seizure-risk issue for sighted readers.

What an action is, and which ones can flash

A PDF action is a small dictionary that tells the viewer to do something: go to a page, open a link, show or hide a field, switch a layer, play a sound. What makes it fire is a trigger, and triggers hang off almost everything — the document (/OpenAction), each page (/AA with /O for open and /C for close), each annotation and each form field.

Most actions do one thing once. The ones worth a reviewer’s attention on this condition are the ones that change what is on screen, especially when something repeats them:

12 0 obj
<< /Type /Page
   /Dur 0.1                                    % in full-screen presentation, advance after 0.1 s
   /Trans << /S /Dissolve /D 0.1 >>            % transition into this page
   /AA << /O << /S /SetOCGState                % on Page Open…
                /State [ /Toggle 31 0 R ] >>   % …flip layer 31 on or off
       >>
   …
>>

/Dur is the page’s display time in presentation mode: when it runs out, the viewer moves to the next page on its own. A run of pages with a fraction-of-a-second /Dur, alternating dark and light, is a flashing slideshow with no script anywhere in it. /SetOCGState with /Toggle flips a layer; attached to a page that is visited repeatedly, or to annotation triggers such as Mouse Enter that fire as the pointer moves, it swaps what is visible every time. Hide actions do the same for fields and annotations.

The protocol files 03-001 against the page, which is the useful way to think about it: the question is whether anything makes the page itself change fast enough to flash. Script that does it is 03-003, and a video that does it is 03-002.

What happens to the reader

This is not a screen-reader problem. It is a seizure risk for people with photosensitive epilepsy, and Adobe adds that flickering elements are also hard to see for someone reading magnified.

WCAG 2.3.1 counts a flash as a pair of opposing changes in brightness, so a layer toggled on and off is one flash, and pages that alternate light and dark every 0.1 seconds are five flashes a second. The limit is three in any one second, unless the flashing area is small: WCAG’s working estimate is a quarter of a 341 × 256 pixel rectangle on a 1024 × 768 screen. A presentation in full-screen mode flips the whole screen, which is about as far from small as it gets.

Where it comes from

• Presentation exports with timings. LaTeX Beamer’s \transduration writes /Dur, and its transition commands write /Trans. InDesign’s interactive PDF export carries page transitions too. A deck built to auto-advance at speed, with high-contrast slides, is the likeliest way to meet this condition without any JavaScript.
• Kiosk and display files that open in full screen and cycle through pages.
• Hand-added page actions in Acrobat, which keeps them under Page Open and Page Close for each page.
• Rollover effects built from show/hide or layer actions on Mouse Enter and Mouse Exit. One rollover is harmless; a grid of them that a pointer sweeps across can be a different matter.

How to check it free

There is no way to decide it from the file alone. The check is two steps: find what can change the page, then watch it.

Find the actions. In Acrobat Pro, Adobe documents page actions under the page’s own properties: open the Page thumbnails panel, select a page, choose Page properties from the Options menu, and open the Actions tab, where the triggers are Page Open and Page Close (Adobe: Add actions to page thumbnails). For links, media clips, form fields and bookmarks the same tab is in each object’s Properties dialog (Adobe: Add actions to PDF elements). That is one dialog per page and per object, which is fine for a short document.

For a long one, read the file directly. This lists what the document does when it opens and every page that carries a display time, a transition or actions — it needs Python and the free pikepdf library:

import sys, pikepdf

pdf = pikepdf.open(sys.argv[1])
print("document opens with:", pdf.Root.get("/OpenAction"))
for n, page in enumerate(pdf.pages, 1):
    p = page.obj
    for key in ("/Dur", "/Trans", "/AA"):
        if key in p:
            print(f"page {n} {key}: {p[key]}")

Anything it prints is a page to look at. Annotation and field actions are not in this list, and still need the Properties route above.

Watch it. View those pages the way they were built to be viewed — in presentation mode if they carry /Dur — and count. More than three changes back and forth in any second is the line. If it is close, record the screen and run the recording through PEAT, the Trace Center’s free photosensitive epilepsy analysis tool for Windows, which measures footage against the WCAG thresholds.

Acrobat’s Accessibility Checker has a Screen flicker rule (All tools → Prepare for accessibility → Check for accessibility). Adobe’s help for it describes the remedy — remove or modify the script or content that causes the flicker — rather than a test, so treat the rule as the prompt to do the two steps above (Adobe: Create and verify PDF accessibility).

How to fix it free

Remove the action or slow it down. In Acrobat Pro, Adobe’s instructions for links, media clips, form fields and bookmarks are to open the object’s Properties, go to the Actions tab, select the action and use Edit or Delete. Page actions are configured on the Actions tab of Page properties, as above.

Remove an auto-advance timing. Fix it in the source — in Beamer, take out the \transduration — and export again. If the source is gone, the same library will remove it from every page, continuing from the snippet above:

for page in pdf.pages:
    if "/Dur" in page.obj:
        del page.obj["/Dur"]
pdf.save("no-autoadvance.pdf")

Without /Dur the reader turns the pages, which removes the timing from the equation entirely. Transitions on their own are a single change per page turn and can usually stay.

Lower the contrast or the area if the effect has to remain: a flash that covers a small part of the screen, or changes between two similar colours, can sit under the thresholds. Check it again with PEAT afterwards rather than by eye.

What Taggart does

Taggart does not read actions, page display times or transitions, and it has no check for this condition, so nothing about it appears in the findings or the review queue. Its repairs remove only actions that run code or start another program on their own — scripts run when the file or a page opens, document-level scripts, launch actions. Every other action is left as it was, a Page Open layer switch included.

What it does is refuse to treat that silence as a pass. 03-001 is on the list of conditions Taggart does not check, and the conformance claim waits on that list. On a test file whose problems were all of this judgement kind — among them a Page Open action toggling a field ten times a second — Taggart reported no findings, its statement stopped at machine checks passed with 03-001 among the conditions not yet confirmed by a person, and asked to declare conformance it left the PDF/UA identifier out. In the application the conformance step lists these conditions, each linked to its page, and the button that writes the identifier stays disabled until you tick I have checked these conditions by hand, or with another validator.

That tick covers the whole list at once, and Taggart takes your word for it: given the confirmation, the same test file was stamped. The PDF report then says a person confirmed the conditions, not what they found. So do the two steps above before you tick it, and keep what you found — the pages you watched, the PEAT result — with the file.

How Taggart handles it

No software can decide this one, and Taggart has no check for it, so it never appears among the findings or in the review queue. It is on the list of conditions Taggart asks you to confirm by hand before it writes the PDF/UA claim into the file — the claim waits until you have.

Where this sits in the standards

Related conditions

• 03-002 Multimedia objects contain flickering contentEmbedded video or animation flashes more than three times per second.
• 03-003 JavaScript actions lead to flickeringDocument-level or field-level JavaScript animates content at a rate that can trigger seizures.
• 29-001 A script requires specific timing for individual keystrokesField JavaScript that depends on how fast the user types — auto-advancing a date field, for instance — locks out anyone using switch access or an on-screen keyboard.

Other conditions in checkpoint 03

Checkpoint 03 covers flickering. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

• 03-002 Multimedia objects contain flickering contentEmbedded video or animation flashes more than three times per second.
• 03-003 JavaScript actions lead to flickeringDocument-level or field-level JavaScript animates content at a rate that can trigger seizures.

This condition needs a person’s judgement, so there was nothing for a tool to check. Written from ISO 14289-1 and the Matterhorn Protocol on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-10.