Matterhorn 05-003 · PDF/UA-1 UA1:7.1-7

app.beep() as the only warning in a PDF form

Form validation signals an error only with app.beep().

What a screen reader actually does

A deaf reader receives no indication that anything is wrong.

What the condition is about

Acrobat’s JavaScript has a one-line way to make a noise: app.beep(), which plays a system sound. It shows up in form scripts as the cheapest possible error signal:

// Validate script on the "postcode" field
if (!/^[A-Z]{1,2}\d[A-Z\d]? ?\d[A-Z]{2}$/i.test(event.value)) {
  app.beep(0);          // the "error" sound
  event.rc = false;     // reject the value
}

Setting event.rc to false in a validation script rejects the entry, so the field goes back to what it held before. The only thing telling the person why is the beep.

05-003 fails when a script uses the beep and provides no other means of notification. It is filed under the protocol’s Sound checkpoint, alongside media and Sound annotations, because the information exists only as audio.

What the reader gets

A deaf reader types a postcode, moves on, and finds the field empty or reverted. No message, no reason. Typing it again produces the same result.

A screen-reader user may hear a beep, if their sound is on and the viewer plays it, and then hears the field announced with its old value. They learn that something went wrong, not what.

Anyone with the sound off — many people at a desk — gets the deaf reader’s experience.

Where it comes from

• Quick validation scripts, where app.beep() stands in for a proper message — a pattern that copies easily from one form to the next.
• Keystroke scripts that beep on a disallowed character and drop it: type a letter into a digits-only field and it is silently refused.
• Document-level helper functions — a shared fail() that beeps — called from every field, so one script fails the whole form.
• Timed reminders that beep when a session is about to expire — which also brings in WCAG 2.2.1 Timing Adjustable if the form then discards what was typed.

How to check it free

Find the beeps. Poppler’s free pdfinfo prints the scripts attached to the document, its pages, fields and annotations, with the trigger each hangs on:

$ pdfinfo -js form.pdf
Name Dictionary "helpers":
function fail() { app.beep(0); event.rc = false; }

Validate Field:
if (!/^\d{6}$/.test(event.value)) fail();

Search the output for beep. Then follow it: a beep inside a shared function counts wherever that function is called, so search for the function name too. Validate Field and Field Modified (keystroke) are the triggers that matter most.

In Acrobat Pro, Adobe documents All tools → Use JavaScript → All javascript strings for opening the JavaScript Editor, and Document javascript strings for the document-level scripts (Adobe: Add debug JavaScript). A field’s own scripts sit on its Properties dialog: the Format tab’s Custom category holds the Custom Format Script and Custom Keystroke Script, and its Validate options include Run custom validation script (Adobe: Field formatting options).

Then test the form with the sound off. Enter something invalid in every field that has a validation or keystroke script. If the only evidence of the problem is a noise you cannot hear, it fails. Acrobat’s Accessibility Checker has a Scripts rule that asks for this kind of manual review (Adobe: Create and verify PDF accessibility); what each checker rule means covers the others.

How to fix it free

Say what is wrong, in text. app.alert() opens a dialog with a message, which every sighted reader sees and screen readers read as a dialog:

if (!/^[A-Z]{1,2}\d[A-Z\d]? ?\d[A-Z]{2}$/i.test(event.value)) {
  app.alert("Postcode: enter a UK postcode, for example SW1A 1AA.", 0);
  event.rc = false;
}

Keep the beep if you like, alongside the message. Make the message name the field and say what is expected, not just that something is invalid.

Say it before anyone gets it wrong. Put the expected format in the field’s visible label and in its tooltip, which is the field’s accessible name: Properties → General → Tooltip in Acrobat (Adobe: Manage form field properties). An error message is the second line of defence.

Edit the script where it lives. For a field, open its Properties, then the Format or Validate tab, and Edit the custom script; for document-level helpers, Document javascript strings, which Adobe documents for adding, editing and deleting the document’s scripts.

What Taggart does

Taggart does not read JavaScript, so it never sees a beep. It has no check for this condition, and nothing about it reaches the findings or the review queue. Its repairs do remove every script that runs on its own — document-level scripts, and those set to run when the file or a page opens — so a beep in one of those is gone after a repair. A script behind a form field or a button runs only when the reader acts, and Taggart leaves it as it was: a field that beeps on a wrong keystroke still beeps.

On a generated test file whose one document-level script was app.beep(0), with other problems of the same judgement kind beside it and every machine-checkable condition passing, Taggart reported nothing. Its conformance statement stopped at machine checks passed, with 05-003 among the conditions Taggart does not check that no person had confirmed, and the PDF/UA identifier stayed out of the file until someone confirmed them — in the application, by ticking the box on the conformance step after testing the form with the sound off.

What Taggart does check on a form is the part a screen reader announces before any script runs: that each field has an accessible name (28-005), sits in a <Form> element (28-010) and is reached in structure order (28-008). Putting the expected format into that accessible name is where its checks and this condition overlap. The application only derives a tooltip from the field’s internal name, which will not contain the format, so write the format into the tooltip in Acrobat or in the program that made the form.

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

• 05-002 Audio annotation present, but content not available in another formA Sound annotation carries information with no transcript.
• 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.
• 28-005 A form field has neither a TU entry nor an alternative descriptionThe /TU tooltip is the accessible name of a PDF form field. Without it the field has no name at all — the visible label printed next to it is not connected to the control.

Other conditions in checkpoint 05

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

• 05-001 Media annotation present, but audio content not available in another formEmbedded media carries information in audio with no transcript or equivalent text in the document.
• 05-002 Audio annotation present, but content not available in another formA Sound annotation carries information with no transcript.

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.