When "Fixed" Isn't Fixed: A Real Accessibility Bug We Found in a Math Course Document

Accessibility scanners like Ally are very good at telling you what's wrong with a document. What they don't do is fix it. For math-heavy course materials, that gap is where a lot of real accessibility problems quietly survive.

DocWright exists to close that gap. It's a remediation tool that works alongside Ally, generating AI-based alt text for images and equations directly inside Word, PowerPoint, and PDF files. Knowing a document has 40 flagged issues doesn't make fixing all 40 of them any less tedious, and that's the part we set out to take off faculty members' plates.

Recently, while working through a real faculty file, we found and fixed two bugs that are worth writing up. They're the kind of failure that's easy to miss even when you're looking directly at the problem.

The file that surfaced it

The document was a set of course materials for a MAT 101 course. Like a lot of math content, it contained a few equation objects, the kind Word creates when you insert or paste a mathematical expression. Among them were the symbols "|" and "∈", each appearing twice in two similar example lines.

DocWright's accessibility pass reported that the images and equations had been described. Word's own Accessibility Checker disagreed. It flagged one of the two "∈" objects and one of the two "|" objects as missing alt text.

Two tools gave two different answers on the same file. That's always worth digging into.

Bug one: copy-pasting an equation duplicates more than the symbol

Word represents these older-style equation objects with a relationship ID that links the visible symbol to its underlying data. When a symbol is copy-pasted elsewhere in the same document, Word reuses that same relationship ID at the new location instead of generating a new one.

Our AI alt-text step looked up each relationship ID and wrote a description to it, but it stopped at the first place that ID appeared in the document. The second, copy-pasted symbol shared the same ID, so it never received a description. Word's checker correctly caught the gap.

Once we identified the cause, the fix was straightforward. DocWright now scans every location where a given relationship ID appears, not just the first, and makes sure any location still missing a description gets one.

Bug two: alt text that looks real but isn't

The second issue was less exotic but more far-reaching. Images copied from a Google Images search carry a pre-existing alt attribute left over from Google's thumbnail markup, something like "Image result for search terms." That text survives the paste into Office documents.

DocWright's check for whether an image "already has real alt text" wasn't recognizing that pattern as junk. As a result, those images were treated as already described and skipped by the AI remediation step, even though the "description" was a leftover search query that tells a screen reader user nothing useful. A document could process successfully while fewer images got a real description than the tool reported.

We fixed the detection logic across the Word, PowerPoint, and PDF paths.

Both fixes are live and have reached existing installations through DocWright's signed automatic update.

Why this is worth sharing

Neither bug was visible on the surface. A file could look completely remediated, with DocWright reporting success and no obvious errors, and still have real gaps that only a second, independent check would catch. In this case that check was Word's own Accessibility Checker.

That's why we think of DocWright as complementary to detection tools like Ally rather than a replacement for them. Verification and remediation are different jobs, and neither one should be trusted blindly on its own.

It's also a reminder that STEM content has its own, less-traveled edge cases. Equation objects, legacy Equation Editor formats, and copy-pasted mathematical symbols get far less attention in general-purpose accessibility tooling than plain text and standard images do. That's a big part of why we've focused on getting them right.

How DocWright handles your documents

DocWright runs entirely on the faculty member's own computer. Scanning, detection, and file editing all happen locally, and the document itself never leaves the machine.

The one exception is the AI step. To generate a description, DocWright sends an image (a cropped figure or equation, or a scanned page being transcribed) to the AI provider your institution chooses: Anthropic, Google Gemini, or Azure OpenAI. The request uses your institution's own account, so it falls under the vendor agreement you already have in place.

If you work in accessibility or assistive technology and want to see how DocWright handles your own equation objects, images, or scanned pages, we'd welcome the chance to show you. Reach us at contact@docwright.org or visit docwright.org.