Skip to content

da_build: add PDF/UA checker with severity classification and optional strict mode - #86

Closed
nonprofittechy wants to merge 5 commits into
mainfrom
add-pac-to-build
Closed

da_build: add PDF/UA checker with severity classification and optional strict mode#86
nonprofittechy wants to merge 5 commits into
mainfrom
add-pac-to-build

Conversation

@nonprofittechy

Copy link
Copy Markdown
Member

This PR adds automated PDF accessibility validation to the da_build action using veraPDF (https://verapdf.org/), ensuring that PDFs in Docassemble repositories comply with the PDF/UA-1 (ISO 14289-1) standard.

For now, this defaults to being warnings only. In a future version of this action (probably about 30 days?) we will start failing repos that do not pass the PDF accessibility checks.

Key Features

  • Smart Severity Levels: Categorizes accessibility rules to prioritize critical blockers while still surfacing advisory warnings:
    • Fail: Critical issues (e.g., untagged content, missing alt text, non-embedded fonts).
    • Warning: Advisory issues (e.g., missing metadata title, language tags).
    • Info/Suppressed: Technical details or rules that only matter in specific contexts (like non-flattened forms).
  • Comprehensive Reporting:
    • GitHub Job Summary: Generates a detailed breakdown for every PDF, including rule descriptions and failure counts.
    • Annotations: Emits GitHub warning or error annotations directly in the action logs.

Configuration & Syntax

Add these optional inputs to the da_build step in your workflow:

 - uses: SuffolkLITLab/ALActions/da_build@main
   with:
     # Set to "error" to fail the build on accessibility failures (default is "warning")
     verapdf-validation-mode: "error"

     # Set to "true" to enforce tab-order and form-field annotation rules (default is "false")
     verapdf-strict: "true"

     # Set to "true" to skip the PDF check and veraPDF installation entirely
     skip-pdf-check: "true"

How to Adjust Strictness

  • Default (Non-Strict): By default, rules related to tab-order (§7.18.3) and widget annotation structure (§7.18.4) are suppressed. Since many Docassemble interviews flatten form fields
    before they reach the user, these rules are often irrelevant.
  • Strict Mode: Set verapdf-strict: "true" to treat these suppressed rules as regular failures.

How to Turn It Off

  • Advisory Only: Keep the default verapdf-validation-mode: "warning". The check will run and report issues, but it will never fail your build.
  • Complete Disable: Set skip-pdf-check: "true". This prevents the action from downloading/installing veraPDF and skips the scanning process entirely.

Rules are now classified into four levels based on their real-world impact:

- **fail**: structural failures that break screen readers (missing StructTreeRoot,
  untagged content, figures without alt text, missing font/ToUnicode, etc.)
- **warning**: advisory issues that don't break AT but should be fixed (missing
  dc:title, missing document language, missing DisplayDocTitle, etc.)
- **info**: administrative metadata rules suppressed by default (§5 PDF/UA
  identifier, optional-content config, PrinterMark annotations)
- **form_annotation**: tab-order (§7.18.3) and widget annotation structure
  (§7.18.4) rules — suppressed in non-strict mode because forms are often
  flattened before users see them; treated as failures in strict mode

New input: `verapdf-strict` (default `false`).
  Set to `true` to activate form-annotation structure rules.

Job summary now groups results into failure / advisory-warning / passing
sections, with advisory warnings and suppressed rules in collapsible details.
Console output shows a per-PDF breakdown (N failure(s), N warning(s), N suppressed).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds automated PDF/UA-1 accessibility validation to the da_build composite GitHub Action using veraPDF, with rule severity classification and an optional strict mode to control how form/tab-order related rules are treated.

Changes:

  • Add check_pdf_accessibility.py to run veraPDF, classify rule severities, emit annotations, and write a GitHub Step Summary report.
  • Extend da_build/action.yml with new inputs (verapdf-validation-mode, verapdf-strict), install veraPDF, and run the checker.
  • Document the new PDF accessibility behavior and inputs in README.md.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File Description
da_build/check_pdf_accessibility.py New checker script that runs veraPDF UA1 validation, buckets failures by severity, and outputs annotations + job summary.
da_build/action.yml Adds inputs and new steps to install veraPDF and invoke the checker as part of da_build.
README.md Documents PDF accessibility checking and the new action inputs.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread da_build/action.yml Outdated
Comment thread da_build/action.yml
Comment thread da_build/check_pdf_accessibility.py
Comment thread da_build/check_pdf_accessibility.py
nonprofittechy and others added 4 commits May 1, 2026 19:45
find_pdfs fell back to rglob over the whole repository, so it reported
accessibility failures for PDFs that are not output documents: reference
material in data/static, ALKiln fixtures in data/sources, and -- when a
local .venv is present -- other packages' templates from site-packages.
Those are false positives the author cannot act on.

Measured over the local AL repo checkouts this narrows the scanned set from
272 PDFs to 96.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E4YaH5h8wS9Kb5uveGQhyd
pdf-validation-mode: off|warning|error replaces skip-pdf-check plus
verapdf-validation-mode, and verapdf-strict becomes pdf-strict, so the two
document checks read identically. Naming the format rather than the tool
also keeps the input stable if veraPDF is ever swapped out.
@nonprofittechy

Copy link
Copy Markdown
Member Author

Sorry, I think this one is stale, just checking

@nonprofittechy
nonprofittechy marked this pull request as draft September 1, 2026 15:24
@nonprofittechy

Copy link
Copy Markdown
Member Author

Closing as superseded by #95. The PDF checker implementation is the same, while #95 is rebuilt on the newer da_build/main history and retains the uv migration and safe env-var input handling. It also uses the aligned pdf-validation-mode / pdf-strict inputs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants