Test your website →

Blog

Inclusive Copy: Writing Without Assuming Ability

Words are part of your interface, and copy quietly assumes things about readers' bodies that your code never gets audited for.

We audit code for accessibility. We almost never audit sentences. But the words on a page are as much a part of the interface as the buttons, and copy makes assumptions about the reader’s body all the time, quietly, in phrasings so ordinary nobody notices them. “As you can see.” “Click the green button.” “Use the menu on the right.” Each of those sentences works only if the reader can see, distinguishes green from its neighbors, and experiences the page in the same spatial layout the writer did. For a lot of readers, at least one of those is false.

Take directional language first, because it’s the most common. “The panel on the left,” “the link below,” “the icon in the top corner.” For a screen reader user, the page has no left. It’s a sequence, a linear stream of elements read in order, and your carefully arranged two-column layout is an implementation detail they never perceive. But here’s what convinced me this isn’t just a blind-user issue: the sighted reader on a phone doesn’t have your left either. Responsive design reflows columns into a single stack, and the sidebar that was on the left is now somewhere below. Directional copy breaks for everyone whose viewport differs from the writer’s. The fix is to point at things by name instead of position. “The Billing panel.” “The link labeled Export.” Names survive reflow. Positions don’t.

Color references are the same mistake in a different sense. “Errors are shown in red” assumes the reader separates red from the surrounding text, and red-green color blindness is common enough, especially among men, that any sizable audience includes such readers. The accessibility guidelines have a principle for interfaces, that color should never be the only carrier of information, and it applies verbatim to prose. If the error state also has an icon and the word “Error,” then your copy can say “marked with an Error label” and everyone can find it. Writing this way has a useful side effect: it forces you to notice when color really is the only signal, which is a design bug your copy was papering over.

Then there’s the verb problem. “Click here” assumes a mouse. “Tap” assumes a touchscreen. “See” assumes eyes. You could tie yourself in knots avoiding every such verb, and I don’t think you should; “see the documentation” is an idiom no reasonable reader stumbles on, and screen reader users themselves say “I watched” and “I saw.” The place where verbs matter is instructions, where the verb encodes the mechanism. “Click the submit button” is worse than “select Submit” or just “submit the form,” not because click is offensive but because it’s inaccurate for the keyboard user, the voice-control user, and the person on a phone. Name the action, not the input device, and the sentence becomes true for every device.

Link text is copywriting too, and it’s the clearest case where writing for one mode of reading fails another. Screen reader users routinely pull up a list of all links on a page and navigate from it, stripped of surrounding context. A page whose links are “here,” “here,” “read more,” and “click here” produces a list that means nothing. “Download the 2026 pricing sheet” means something in any context. It happens that search engines evaluate link text the same way, so the inclusive habit and the SEO habit are the same habit. When GazeSite grades a page for readability and accessibility, vague link text is one of the findings that shows up on otherwise polished sites, I suspect because it’s produced by marketers who were never told that links are read out of context.

There’s a subtler assumption in copy, harder to name: the assumption of cognitive ease. Long winding sentences, idioms, wordplay in navigation labels, cleverness where clarity was needed. Plain language is usually filed under readability rather than accessibility, but for readers with dyslexia, readers processing your language as their second or third, and readers who are simply tired, the distinction is academic. A navigation item called “Kitchen Sink” is a joke; a navigation item called “Everything else” is a door. The rule I use is that copy can be playful anywhere the reader is browsing, and must be plain anywhere the reader is doing something: forms, errors, instructions, buttons, navigation. Delight in the prose, precision in the interface.

If this sounds like a long list of prohibitions, I’d frame it differently. Every one of these fixes makes the copy better for readers with no impairment at all. Naming elements instead of pointing at them makes instructions robust. Describing actions instead of devices makes them accurate. Meaningful links make pages scannable. Plain words make everything faster. That’s the general shape of accessibility work, and copy is where it’s cheapest to observe: the accommodations aren’t a parallel version of the thing for a special audience. They’re the thing, done carefully. Writing without assuming ability turns out to be nothing more exotic than writing that says what it means.

More articles

← All posts