Checkpoint 29: Actions

Scripts and actions within PDFs must not require specific timing for individual keystrokes. All interactive functionality must be accessible to users who may need more time to input information or who use alternative input methods.

What This Means

PDFs can contain JavaScript that responds to user input, including keystrokes. PDF/UA requires that these scripts do not depend on the timing between keystrokes. Users must be able to:

• Type at their own pace without time pressure
• Use assistive technology that may input characters differently
• Pause between keystrokes without losing functionality
• Complete input without racing against a timer

Timing-dependent scripts create barriers because:

• Some users type slowly due to motor impairments
• Screen reader users may need time to verify input
• Alternative input methods (voice, switch devices) have different timing
• Cognitive disabilities may require more processing time

The requirement does not prohibit JavaScript or keyboard interaction; it prohibits requiring specific timing patterns for those interactions.

Why It Matters

Timing requirements on keystrokes can exclude many users:

• Motor impairments: Users with limited dexterity may type slowly
• Tremors: Conditions like Parkinson's cause irregular keystroke timing
• One-handed typing: Users may need more time between keys
• Voice input users: Speech recognition has natural pauses
• Switch access users: Single-switch input is inherently slow
• Screen reader users: May pause to hear feedback between keys
• Cognitive disabilities: Processing and responding takes time

Real-world examples of problematic timing requirements:

• Password fields that auto-submit after detecting "complete" input
• Search fields that require typing "fast enough" to be recognized as continuous
• Gaming-style interactions requiring rapid key sequences
• Timeout-based interactions that fail if typing is too slow

These create barriers that prevent users from completing tasks successfully.

Common Violations

The Matterhorn Protocol defines one failure condition for actions.

29-001: Script Requires Specific Timing for Individual Keystrokes (Human Testing)

What's Wrong: JavaScript in the PDF requires users to press keys within a certain time frame, either:

• Minimum time between keystrokes (too fast detection)
• Maximum time between keystrokes (timeout between keys)
• Specific key sequence timing (rhythm-based input)
• Auto-execution based on pause detection

How to Identify:

• Test all interactive JavaScript features in the PDF
• Type very slowly in text fields (5+ seconds between keys)
• Type at varying speeds
• Look for behavior that changes based on typing speed:
  • Fields that auto-submit
  • Input that is rejected or cleared
  • Different results from fast vs. slow typing
  • Timeout messages during input

Testing Scenarios:

1. Form fields: Type one character, wait 10 seconds, type another
2. Search functionality: Enter characters slowly and verify functionality
3. Interactive calculations: Input numbers at varying speeds
4. Any JavaScript-driven field: Test with significant pauses between keystrokes

Problematic Patterns:

// BAD: Auto-submit after detecting pause
let typingTimer;
field.onKeyUp = function() {
    clearTimeout(typingTimer);
    typingTimer = setTimeout(submitForm, 500); // Submits after 0.5s pause
};

// BAD: Ignore input if too slow
let lastKeyTime = Date.now();
field.onKeyPress = function() {
    if (Date.now() - lastKeyTime > 2000) {
        // Clears or ignores input after 2 second gap
        this.value = '';
    }
    lastKeyTime = Date.now();
};

How to Fix in Adobe Acrobat

Reviewing JavaScript for Timing Dependencies

1. Go to Tools > JavaScript

2. Select Document JavaScripts to view document-level scripts

3. Review code for timing-related functions:

   • setTimeout() or setInterval() related to keystrokes
   • Date.now() or new Date() in keystroke handlers
   • onKeyUp/onKeyDown handlers with timing logic

4. Check field-level scripts:

   • Go to Tools > Prepare Form
   • Select each field and view Properties > Actions
   • Review any JavaScript actions for timing logic

Removing Timing Dependencies

Auto-submit removal:

Before:

// Submits form after user stops typing for 1 second
var timer;
event.target.addEventListener('keystroke', function() {
    clearTimeout(timer);
    timer = setTimeout(function() {
        this.getField('submit').buttonImportIcon();
    }, 1000);
});

After:

// Submit only when user explicitly clicks Submit button
// Remove automatic submission entirely

Timeout removal:

Before:

// Clears field if typing pauses too long
var lastKey = Date.now();
if (event.name === 'Keystroke') {
    if (Date.now() - lastKey > 3000) {
        event.value = '';
    }
    lastKey = Date.now();
}

After:

// Simply accept the keystroke without timing check
if (event.name === 'Keystroke') {
    // Process keystroke normally
}

Alternative Interaction Patterns

Instead of timing-based triggers, use explicit user actions:

1. Submit buttons: Require explicit click/activation to submit
2. Search buttons: Add a "Search" button rather than auto-search
3. Confirmation: Ask user to confirm when ready
4. Clear buttons: Let users explicitly clear if needed

Testing Modified Scripts

1. Make JavaScript changes
2. Save the PDF
3. Test all interactive features:
   • Type very slowly (10+ seconds between keys)
   • Type at normal speed
   • Type very quickly
4. Verify consistent behavior regardless of speed

How to Prevent in Source Documents

Avoiding Timing-Dependent Scripts

When creating PDFs with JavaScript:

1. Design for explicit actions: Users click/tap to confirm
2. Avoid auto-behaviors: Do not auto-submit, auto-clear, auto-advance
3. Test with slow input: Verify scripts work at any speed
4. Consider assistive technology: Input may come in unexpected patterns

Alternative Approaches to Common Features

Instead of auto-search:

// Provide search button
var searchBtn = this.getField('searchButton');
searchBtn.setAction('MouseUp', 'performSearch()');

Instead of input timeout:

// Let users work at their own pace
// Only validate when they explicitly request validation
var validateBtn = this.getField('validateButton');
validateBtn.setAction('MouseUp', 'validateInput()');

Instead of detecting "complete" input:

// Use a "Done" or "Next" button
var doneBtn = this.getField('doneButton');
doneBtn.setAction('MouseUp', 'processInput()');

Form Design Best Practices

1. Explicit submission: Always use submit buttons
2. Save capability: Allow saving work in progress
3. No time limits: Never require completion within a time frame
4. Progress indicators: Show completion status without time pressure
5. Error tolerance: Allow correction without starting over

Testing Your Fix

Manual Timing Tests

1. Slow typing test:

   • Open the PDF
   • Navigate to any text input field
   • Type one character
   • Wait 30 seconds
   • Type another character
   • Verify the field still works correctly

2. Variable speed test:

   • Type some characters quickly
   • Pause for 10 seconds
   • Type more characters
   • Verify consistent behavior

3. Very slow completion:

   • Take 5 minutes to complete a form
   • Verify nothing times out or resets

Assistive Technology Testing

1. Screen reader test:

   • Use NVDA, JAWS, or VoiceOver
   • Navigate to form fields
   • Input characters while listening to feedback
   • Verify timing does not affect functionality

2. Voice input test:

   • Use voice recognition software
   • Dictate text to form fields
   • Natural pauses in speech should not cause issues

3. Switch/scanning input:

   • If possible, test with switch access
   • Single-switch input has inherent delays
   • Verify functionality with slow input

JavaScript Review

1. Search JavaScript code for timing indicators:

   • setTimeout
   • setInterval
   • Date.now()
   • new Date()
   • performance.now()

2. For each timing function found:

   • Determine if it relates to keystroke handling
   • Verify it does not create timing requirements for users
   • Consider if it is necessary or can be removed

Validation Checklist

• All form fields accept input at any speed
• No auto-submit based on pause detection
• No input timeout that clears or rejects data
• No keystroke sequence timing requirements
• Explicit buttons for submission and actions
• JavaScript reviewed for timing dependencies
• Tested with very slow input (30+ second gaps)
• Tested with screen reader
• Consistent behavior regardless of input timing

Acceptable vs. Problematic Timing

Acceptable Use of Timing

Some timing-related features are acceptable:

• Debouncing for performance: Waiting briefly before processing to reduce server calls, as long as no input is lost or rejected
• Animation timing: Visual effects that do not affect functionality
• Session timeout warnings: With adequate time and user notification
• Auto-save: Periodically saving work (does not require specific keystroke timing)

Problematic Timing

These patterns violate accessibility requirements:

• Keystroke timeout: Rejecting or clearing input based on typing speed
• Auto-submit on pause: Submitting when typing stops
• Sequence timing: Requiring specific rhythm in key presses
• Typing speed validation: Treating slow typing as suspicious
• Real-time validation timeout: Requiring immediate re-typing

Edge Cases

Consider carefully:

• CAPTCHA alternatives: Timing-based bot detection may need accessible alternatives
• Security features: Multi-factor authentication should allow adequate time
• Gaming elements: Interactive games may need accessibility modes

Related Considerations

WCAG 2.1.1: Keyboard

All functionality must be keyboard accessible. Timing requirements often compound keyboard accessibility issues by adding time pressure to keyboard navigation.

WCAG 2.5.1: Pointer Gestures

While this criterion focuses on pointer input, the underlying principle applies: do not require specific physical capabilities (including speed) for interaction.

Form Timeout Extensions

If your PDF form connects to a backend system with timeouts:

1. Warn users before timeout
2. Provide easy way to extend time
3. Save user data before timeout
4. Allow session restoration after timeout

Additional Resources

Official Standards and Guidelines

• W3C WCAG 2.1 Success Criterion 2.1.1: Keyboard
• W3C WCAG 2.1 Success Criterion 2.5.1: Pointer Gestures
• PDF Association Matterhorn Protocol 1.02

JavaScript and Accessibility

• Adobe Acrobat JavaScript Reference
• WebAIM: Keyboard Accessibility
• Inclusive Components: Timing

Input Methods and Assistive Technology

• WebAIM: Motor Disabilities
• Switch Access Overview
• Voice Control for Computers

Tools

• PAC (PDF Accessibility Checker) - Free PDF/UA validation
• NVDA Screen Reader - Free screen reader for testing
• Acrobat JavaScript Debugger

This documentation is based on the Matterhorn Protocol 1.02, the definitive reference for PDF/UA validation. Actions/timing violations require human testing because automated tools cannot determine if JavaScript creates keystroke timing dependencies. For the most current information, consult the PDF Association and W3C WCAG guidelines.