Matterhorn 29-001 · PDF/UA-1 UA1:7.19-1

PDF form scripts that depend on how fast you type

Field 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.

What a screen reader actually does

Input is truncated or rejected for users who type slowly.

Where the phrase comes from

WCAG 2.1.1 requires that everything be operable from a keyboard “without requiring specific timings for individual keystrokes”. Condition 29-001 is that clause applied to PDF: a script must not require specific timing for individual keystrokes. PDF/UA-1 files it under actions, clause 7.19.

In a PDF form the script in question is usually a keystroke script, which Acrobat runs every time the content of a text field is about to change:

/T (verification_code)
/FT /Tx
/AA << /K << /S /JavaScript /JS (…) >> >>    % runs on every key press

Inside it, event.change is what was just typed, event.willCommit says whether this is a keystroke or the final value being committed, and setting event.rc to false rejects the change. None of that involves time. The failure is a script that brings time into it.

The three shapes it takes

Measuring the gap. The script remembers when the last key arrived and rejects, clears or restarts the entry if the next one is too slow:

// Custom keystroke script — fails 29-001
if (!event.willCommit) {
  var now = Date.now();
  if (global.last && now - global.last > 800) event.rc = false;   // too slow: key dropped
  global.last = now;
}

Acting on a pause. app.setTimeOut() schedules code to run after a delay, and some scripts use it to commit the field, move focus to the next one, or reformat the value when the typist stops for a moment. A person who pauses to find the next character finds themselves in a different field.

Counting fast presses. A script that treats two presses within a short window as a different command — a double-tap to clear, a quick repeat to confirm.

The summary at the top of this page gives auto-advancing a date field as an example. That is the pause-triggered kind: a date field that moves on after the second digit of the day is counting, not timing, and is a separate usability problem rather than this one.

What the reader gets

A switch user selecting characters from a scanning keyboard may take two or three seconds per character. With the first script above, every character after the first is rejected, and nothing on screen says why — the field just will not take input. With a pause-triggered advance, focus leaves the field halfway through the entry, and a screen-reader user hears a different field announced without having asked to move. The form can only be completed by someone typing at a speed the author assumed.

How to check it free

Read the keystroke scripts. Poppler’s free pdfinfo prints the scripts attached to the document, its pages, fields and annotations, with their triggers; keystroke scripts appear as Field Modified:

$ pdfinfo -js form.pdf
Field Modified:
if (!event.willCommit) { var now = Date.now(); … }

Search the output for Date, getTime, setTimeOut, setInterval and clearTimeOut. A keystroke or format script that uses any of them deserves a careful read; one that compares two times is very likely the first shape above.

In Acrobat Pro, a field’s keystroke script is under its Properties → Format tab → Custom → Custom Keystroke Script (Adobe: Field formatting options), and its other triggers — Mouse Up, On Focus, Blur and the rest — on the Actions tab (Adobe: Form fields general settings). All tools → Use JavaScript → All javascript strings opens the JavaScript Editor for a wider search (Adobe: Add debug JavaScript).

Then type slowly. In Acrobat or Reader, fill each scripted field one character at a time, with a few seconds between characters. If input is rejected, cleared or moved, it fails. Acrobat’s Accessibility Checker has a Timed responses rule for forms with JavaScript, which Adobe maps to WCAG 2.2.1 and which asks for exactly this kind of manual review (Adobe: Create and verify PDF accessibility).

How to fix it free

Check the characters, not the clock. Whatever the timing was meant to protect, a keystroke script can filter what is typed at any speed and check the whole value once, when it is committed:

// Custom keystroke script — digits only, checked in full on commit
if (event.willCommit) {
  if (!/^\d{6}$/.test(event.value)) {
    app.alert("Verification code: enter the six digits from your letter.");
    event.rc = false;
  }
} else {
  event.rc = /^\d*$/.test(event.change);
}

Move focus only when asked. Drop pause-triggered auto-advance. If the form must advance automatically, do it on a character count and say so in the field’s label.

Edit it in Acrobat: the field’s Properties → Format → Custom → Edit next to the keystroke script; for scripts on other triggers, the Actions tab’s Edit and Delete. If a form tool generated the script, fix it in the tool’s template as well, or the next export brings it back.

What Taggart does

Taggart does not read JavaScript and has no check for this condition. A keystroke script that drops slow input passes every check it runs; the condition does not appear in the findings or the review queue, and its repairs leave the script exactly as it was.

This was tested on a generated form: a field correctly tagged in a <Form> element, with a tooltip, on a page with structure tab order, carrying a gap-measuring script like the one above. Taggart reported nothing. The conformance statement stopped at machine checks passed, with 29-001 among the conditions Taggart does not check that nobody had confirmed, and the PDF/UA identifier was left out until a person confirmed them — the checkbox on the application’s conformance step. Typing slowly through the form is what that confirmation should rest on.

What Taggart checks on the same field is everything a screen reader needs before the first keystroke: an accessible name (28-005), a <Form> element (28-010) and tab order that follows the structure (28-008, 28-009). A form that passes all of those can still be impossible to fill in, and this condition is one of the ways; accessible PDF forms covers the rest.

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-003 JavaScript uses beep but provides no other notificationForm validation signals an error only with app.beep().
• 03-003 JavaScript actions lead to flickeringDocument-level or field-level JavaScript animates content at a rate that can trigger seizures.
• 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.
• 28-009 A page containing an annotation has a Tabs entry with a value other than S/Tabs is present but set to /R (row order) or /C (column order) rather than /S (structure order).

Other conditions in checkpoint 29

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

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.