Accessibility in document tools (WCAG 2.2)

Document tools have a poor reputation for accessibility. Drag-and-drop drop zones without keyboard alternatives, unlabelled progress bars, invisible focus states, PDFs generated without a text layer. We started nctools with an explicit goal: every conversion flow works keyboard-only, is announced correctly by screen readers, and produces output that is itself accessible.

Drop zones with a keyboard fallback

Our drop zones are also file-input labels. The visible drop zone is a decorative surface; the actual accessible control is a full-width, hidden <input type='file'> layered on top. This gives us drag-and-drop for pointer users and native file-picker semantics for keyboard and screen-reader users. No custom key handling, no ARIA gymnastics.

<label className="drop-zone" tabIndex={0}>
  <input
    type="file"
    className="sr-only"
    onChange={(e) => handle(e.target.files?.[0])}
    aria-label="Choose a PDF to convert"
  />
  <span aria-hidden>Drop a PDF here, or click to browse</span>
</label>

Progress that speaks

A conversion can take 20 seconds. Sighted users see a progress bar; screen-reader users need aria-live announcements. We use aria-live='polite' with a role='status' region that updates every 10 percent — often enough to feel responsive, rare enough not to spam.

Focus management on completion

When the download link becomes available, we move focus to it programmatically. Users on tab-only navigation do not have to hunt for the next actionable element.

Accessible outputs

A converted Word document should itself be accessible. We preserve heading levels, add alt text placeholders for images (users can fill them in), and set the document language from the OCR result. The output opens with a valid Accessibility Checker score in Word.

For OCR outputs, the searchable-PDF format we emit follows PDF/UA-1 tagging conventions where practical. Not fully compliant — full PDF/UA is a spec-writing project of its own — but a meaningful step up from a bare image-only PDF.

Colour and contrast

Our green primary is intentional — brand-recognisable and passing 4.5:1 against every neutral in the palette. We test contrast at every design-token change. Dark mode (available in menu) is not simply an inversion; each token is recalculated to preserve contrast ratios.

Motion

prefers-reduced-motion suppresses our page transitions and the confetti that celebrates a first conversion. Nobody has ever complained about that particular animation being missing.

Testing

Every commit runs axe-core against the built site. Any new WCAG 2.2 violation blocks merge. Manual testing by keyboard-only and NVDA happens weekly. It is a slower engineering culture and the results speak for themselves.