PDF accessibility tagging that doesn't crash

One complaint stands out in specificity: 'the tagging for making a PDF accessible rarely works, and the application crashes 70% of the time while reordering tags.' This isn't a performance complaint — it's a compliance workflow that's completely broken. Anyone whose job requires producing accessible PDFs under Section 508 or WCAG is stuck in a loop of crashes, lost work, and reinstalls just to meet a legal obligation.

The reason this specific failure mode exists and persists is that accessibility tagging is a secondary workflow inside tools built primarily for PDF creation and editing. The tag tree — the underlying structure that screen readers depend on — is complex to manipulate, and the UI for reordering it is notoriously fragile. Vendors treat it as an edge-case feature; the users who need it most (government contractors, university document teams, compliance officers) aren't the buyers who drive product roadmap decisions.

The gap isn't that accessibility tools don't exist — it's that the ones that do are either buried inside general PDF editors that crash during the one task they're supposed to support, or they're expensive consulting-adjacent products aimed at enterprise procurement, not the individual who gets handed a 300-page report and told to make it 508-compliant by Friday.

A focused tool that ingests a PDF, parses the existing tag structure, lets a user reorder, rename, and correct tags in a stable interface without the document re-rendering on every change, and then exports a remediated file would solve this directly. The critical design constraint is that the tag editor must be completely decoupled from the rendering pipeline — which is exactly what causes the 70% crash rate in the general-purpose tools, because they re-render the visual document every time the tag tree changes.

This is a business because 508 compliance is a legal requirement with deadlines, not a nice-to-have. Government contractors lose bids over it. Universities get sued over it. The need recurs every time a new document is published, and the current best alternative for most users is hiring a remediation service at $1-3 per page.

What to build

Build a standalone desktop app that parses the tag tree of any PDF, lets users reorder and relabel tags in an interface that never re-renders the document visually during edits, runs automated WCAG 2.1 checks on the structure, and exports a remediated PDF with a compliance report.

Where to start

Start with university disability services offices — they have a recurring backlog of documents that must be remediated, a dedicated budget for accessibility tools, and procurement cycles that don't require enterprise sales; a single university can generate enough recurring revenue to validate the model.

The hard part

Tag structure in PDFs varies wildly depending on which tool created the original — files generated by InDesign, Word, or scanned-then-OCR'd documents all produce different tag tree shapes, so the parser has to handle malformed or partially-tagged files without crashing, which is the exact failure mode you're trying to replace.

How it makes money

Annual per-seat license with a one-time remediation batch option (pay per document) for users who have a backlog to clear before committing to a subscription.