How We Support Every Disability — and Where We're Still Improving

Most accessibility tools treat compliance like a single problem. Run a checker, fix the errors, ship the PDF. But accessibility isn't one problem. It's the experience of five fundamentally different groups of people — each with different needs, different assistive technologies, and different ways a document can fail them.

When I started building the Foresera engine, I assumed getting the structure tree right would cover most of it. And for screen reader users, that's largely true. But the further I went, the more I realized how many disability categories get overlooked by tools that only think in terms of tags and alt text.

Here's an honest look at where we are today — what we handle well, what we've recently improved, and where we're still working.

Vision — screen reader users

This is where the engine is strongest, and where the most established standards exist. WCAG and PDF/UA are largely written around the screen reader experience, and so is most remediation tooling.

Foresera automates the full structure tree — headings, paragraphs, lists, tables, figures, artifacts — along with alt text generation for images and complex vector graphics, reading order correction, heading hierarchy repair, bookmarks, named destinations, page labels, table of contents, and language metadata.

For a screen reader user navigating a government form or an annual report, the experience after remediation should be equivalent to what a sighted user gets from reading the page visually. That's the bar, and we're consistently reaching it.

Vision — low vision users

Low vision users don't necessarily use screen readers. Many rely on magnification, high-contrast display modes, or simply need text and backgrounds to have enough contrast to be legible. This is a different set of requirements from the screen reader experience, and it's one that many tools address superficially.

Our contrast system handles text, vector graphics, and form fields. It works bidirectionally — if text is light on a dark background, it lightens the text; if text is dark on a light background, it darkens it. It preserves CMYK color spaces for print-ready documents instead of flattening everything to RGB. And it handles the nuances: form field contrast depends on the actual background behind the field, not just the field border.

This area is strong and recently improved. The remaining work is mostly around specialized element styling — things like table of contents dot leaders, decorative separator lines, and table border treatments. These are real gaps, but they affect a smaller set of documents than the core contrast issues.

Color vision deficiency

This is the category where we've made the most progress recently and where we have the most work left to do. About 1 in 12 men and 1 in 200 women have some form of color vision deficiency, and documents that rely on color alone to convey meaning are a persistent problem.

The biggest recent improvement: when the engine generates alt text for charts and data visualizations, it now describes the data by value and name rather than by color. Instead of "the red bar is highest," a chart description will convey which category leads and by how much. For a colorblind user relying on a screen reader, this is the difference between understanding a chart and being told about colors they can't distinguish.

Where we're still improving: the engine doesn't yet automatically rewrite chart colors to use colorblind-safe palettes. The infrastructure for rewriting colors in the content stream exists — it's the same system that handles contrast — but applying it to chart palettes requires extracting the existing color scheme from vector graphics and mapping it to an accessible alternative. That's on our roadmap.

Motor disabilities

Users with limited hand control, tremors, or paralysis navigate entirely by keyboard, switch access, or voice control. They never use a mouse. For them, a document fails when interactive elements aren't reachable by keyboard or when the tab order doesn't follow a logical sequence.

This is an area where we're consistently strong. The engine handles logical tab order for form fields and interactive elements, heading-based navigation so users can jump between sections, proper form labels, link text that makes sense out of context, and bookmark generation for long documents.

Some motor accessibility requirements — like visible focus indicators — depend on the PDF viewer rather than the document itself. Those are outside the scope of what remediation can address, but they're also outside WCAG's expectations for document producers.

Cognitive and learning disabilities

This is the category that gets the least attention in remediation tooling, and it shouldn't. Dyslexia, ADHD, autism, and traumatic brain injuries all affect how people process complex information. Dense documents without clear structure are genuinely inaccessible to people in this group — not just inconvenient, but functionally unusable.

The structural work — heading hierarchy, list formatting, table markup, consistent reading order — supports cognitive accessibility by default. But recently we've gone further. The engine now generates plain-language summaries for complex documents and inserts them at the beginning of the structure tree, so screen readers and text-to-speech tools announce them first. For sections with dense or technical content, it adds brief cognitive accessibility notes that provide context in simpler language.

This work is still early. There's more to do around simplifying complex language patterns, improving how tables are described, and supporting users who rely on text-to-speech rather than full screen readers. But the foundation is in place.

Where this leaves us

No tool covers every disability category perfectly. I don't think that's a controversial statement — the range of human needs is wide, and the PDF format was never designed with accessibility in mind.

What I can say is that we're covering more ground automatically than any tool I've evaluated. And the gaps we have aren't theoretical — we know exactly where they are, and we're actively closing them. The improvements to contrast handling, colorblind-accessible descriptions, and cognitive accessibility notes all shipped in the last few weeks, not the last few years.

This is the pace. If you're evaluating remediation tools and the vendor can't tell you specifically where their coverage is strong and where it isn't, that's worth asking about.