DocAble — Examples

How does it work?

In building DocAble, we walked a tightrope. On the one hand, generative AI is the only known method for generating contextually-appropriate judgments — like crafting the right alt text for a particular figure in a particular paragraph. On the other hand, generative AI hallucinates, deviates from plan, and in general misbehaves. To pull off the balancing act, we put careful safeguards in place, and we give you full transparency over what was changed:

• Accessibility-first design. Every check we run is anchored in a published standard. WCAG 2.2 for the web-flavored rules; PDF/UA-1 for PDF structure; the Matterhorn Protocol's 136 numbered failure conditions for the subtler PDF/UA cases the other two leave under-specified. We also go beyond the standards where they fall short of practical reality — for example, automatically downsampling over-large images so files stay usable on weaker hardware like Chromebooks and phones. No published standard requires this, but bandwidth and rendering cost are real accessibility barriers, and we treat them that way.
• LLM-as-function-call architecture. We treat the language model as one component, not the source of truth. Each fix is a single, discrete proposal that we hand to a validator before it touches your file — using a mix of industry-standard checkers and our own proprietary validation tooling. Proposals that don't pass don't go in.
• Only additive changes. We add structure, alt text, and accessibility tags around what you've written; we don't rewrite, summarize, or remove your content. Content-fidelity checks bracket each pass — when one detects drift, the job stops rather than ships.
• Page-by-page changelog. A page-by-page record of every fix we made, so you can see exactly what changed.