Before You Send

The gap it fills

Writing tools and accessibility tools do not overlap. Readability apps check your sentences. Accessibility checkers check your rendered code. Neither one notices that a draft still carries the fingerprints of the model that helped write it.

That gap sits exactly where communications work happens. Most people now draft with AI and publish something nobody has checked for either problem.

It runs entirely in the browser. No account, no upload, no server, which is the only honest way to ask someone to paste unpublished company copy into a tool.

Why rules instead of a language model

The obvious build is to hand a style guide to a model and ask it to review the copy. I chose not to, and that is the decision worth defending.

A model answers differently on every run, cites nothing, invents rules that were not in the guide, and sends the draft to a third party. A rule engine is less clever and more useful: same input, same output, every finding naming the rule behind it, and a user who disagrees has something concrete to argue with.

Knowing which problems need judgment and which need a rule is most of working sensibly with these systems. This one needed rules.

Three calls that shaped the build

Report the level, not just the rule. Five of eighteen rules cite a WCAG 2.2 criterion. Several sit at Level AAA, which most organisations do not target, so each finding carries its level. Calling a AAA best practice a compliance failure would be overclaiming.

Say when I cannot prove something. “Click here” does not automatically fail 2.4.4, because that criterion lets the surrounding sentence supply the purpose. It fails 2.4.9, which does not. Pasted text cannot show what the built page provides, so the tool reports what it can demonstrate and flags the rest for review.

Do not build an AI detector. The tool flags a register in copy the user chose to check. It never claims to know who wrote anything. Detection is unreliable and its false positives land hardest on people writing in a second language. Building it would have been easier and more shareable. It would also have been wrong.

The rules an editor writes, not an engineer

Three of the AI checks came from noticing what makes prose feel machine-made, and they are the ones a developer could not have specified:

An abstract subject doing a vague thing. “This highlights the importance of”, “the data reveals”. Reports do not highlight. The rule only fires when the subject is abstract, so “she highlighted the risk” passes.

Prose narrating its own structure. “That matters because”, “what this means is”. The writing announcing what it is about to do instead of doing it.

Repeated sentence openers. Three sentences in a row starting with “Sometimes”. This reports as a question rather than an error, because anaphora is a real device and flagging deliberate craft is how a tool loses a professional reader.

What I left out

No grammar or spelling. Grammarly does it better, an API call would break the promise that nothing leaves the browser, and every extra rule is another chance at a false positive. One bad flag and people stop trusting the accessibility findings too. The tool tells users to run their usual grammar tool first.

I also held back a heading-quality rule. It maps to a real Level AA criterion, but judging whether a heading describes its section needs an understanding of the section, and I could not make it accurate enough to ship.

It cannot check contrast, keyboard operation or focus order either. Those need the rendered page. This covers the words layer only.

Where it stands

A concept build. The engine and interface work, and it ships with a bad staff announcement and a rewrite of the same message: twenty-six findings against none. The landing page copy has to pass its own checker too.

Two things I would close before any public release: testing with a real screen reader rather than inspecting markup, and softening the passive voice rule, which is accurate but fires often enough to feel like nagging.