An accessibility bug hiding inside an AI-watermark story
Most of this site talks about hidden Unicode characters as an AI-watermark or copy-paste problem. They're also, independently, a documented web accessibility problem — one the W3C wrote failure techniques for years before "AI watermark" was a phrase anyone used. Assistive technology (screen readers, braille displays, some text-to-speech engines) reads the actual character sequence in your text, not the rendered pixels. A character that is invisible to your eyes is not invisible to that pipeline.
That gap is exactly what WCAG Technique F32 and F33 describe: both are filed as documented ways to fail WCAG Success Criterion 1.3.2, Meaningful Sequence, by using whitespace characters — the same family of characters this tool detects — to fake a visual effect instead of using real markup for it.
What F32 and F33 are actually about
Spacing characters inside a word
Inserting space-like characters between individual letters to fake letter-spacing (a common pattern in text copied from stylized web pages or PDFs). Assistive technology can read the result as separate, unrelated words instead of one word.
Repeated spacing to fake layout
Using strings of whitespace characters to simulate indentation, columns, or tables instead of real formatting. Screen readers can collapse, skip, or misannounce the layout it was meant to create.
Both techniques predate today's AI chat interfaces by over a decade — WCAG 2.0 was published in 2008 — which is worth sitting with. The characters that make ChatGPT or Claude output paste strangely into a CMS are the same category of character the accessibility community had already flagged as a screen-reader hazard, long before anyone was talking about AI watermarking. Fixing it for one audience fixes it for the other.
Which specific characters carry accessibility risk
| Character | Why it matters for assistive tech |
|---|---|
| U+200B Zero Width Space | Can sit mid-word, splitting one word into fragments for a screen reader to parse separately. |
| U+00A0 / U+202F No-Break Spaces | Look like a normal space but are a distinct character, which can change how a text-to-speech engine phrases pauses in a sentence. |
| U+200E / U+200F Directional Marks | Can cause reading order to diverge from visual order — see the BiDi character guide for how this class of character behaves. |
| U+2060 Word Joiner | Zero-width by design, so it carries the same mid-word fragmentation risk as U+200B. |
The full reference table of every character this tool detects — including the ones that are purely cosmetic rather than accessibility-relevant — is in the invisible Unicode characters list.
Checking text before it reaches a screen reader
- Paste the text — a CMS draft, an email, a document — into the cleaner at the top of this page.
- Read the "What changed" report. It names every hidden character by its actual code point, so you can tell whether an accessibility-relevant one (a zero-width space, a BiDi mark) was present, rather than guessing.
- Publish the cleaned version. The visible words are unchanged; only the characters an assistive technology would have parsed differently are gone.
This step is one part of publishing accessible content, not the whole of it — see how to clean AI-generated text before publishing for the rest of that checklist.