Language Barriers: Plain Words as an Accessibility Feature

When people think about web accessibility they think about code: contrast ratios, alt text, ARIA attributes. But there’s a barrier that sits in front of all of those, and it’s made of words. If a visitor can’t understand what your page says, it doesn’t matter how perfectly the page is built. The content itself is the wall.

Consider who reads your site in a language that isn’t fully theirs. Non-native speakers, first: English content is read every day by hundreds of millions of people for whom English is a second or third language, and their comfort ranges from near-native to survival level. Then people with dyslexia, for whom dense text costs real effort per sentence. People with cognitive disabilities or brain injuries. People reading through the fog of medication, chemo, or grief. And the situational cases, which is to say everyone: the parent reading your pricing page at midnight after the kids finally slept, the customer skimming your docs during an outage with their boss standing behind them. Reading ability isn’t a fixed trait. It’s a resource that varies by person and by moment, and your prose sets the price of admission.

Most websites price too high, and I think I know why. The words on a business website are written by insiders, and insiders have a vocabulary problem they cannot feel. To the team, “leverage our platform’s robust capabilities to streamline your workflow” reads as normal, even professional. To a non-native speaker it’s four abstractions in a trench coat. Every word is doing prestige work and no word is doing meaning work. What does the product do? The sentence never says. Jargon feels like precision from the inside and fog from the outside, and the inside can’t smell its own fog.

There’s a myth worth killing here: that simple language is dumbed-down language, that writing plainly means condescending to your reader. The opposite is true, and you can verify it by reading the best writers in any field. Good physicists explain hard things in short words. It’s the mediocre ones who need the fog, because fog hides the absence of a clear thought. Writing simply about something complicated is strictly harder than writing complicatedly about it, which is exactly why plain writing signals competence. When a company says “we back up your files every hour” instead of “we deliver continuous data protection solutions,” I trust the first company more, not less. They evidently know what their product does.

The accessibility world has formalized some of this. WCAG’s guideline on readability suggests that when text demands more than a lower-secondary-school reading level, a simpler version or summary should be available, and it asks for things like explaining unusual words and spelling out abbreviations the first time they appear. There’s also a purely mechanical rule that’s trivially cheap and widely flubbed: declare the page’s language in the HTML, with lang="en" or whatever applies, because screen readers use it to pick the right pronunciation engine. English text read aloud with, say, French pronunciation rules is close to gibberish, and the fix is one attribute on one tag. But the formal rules only gesture at the real practice, which is editorial: shorter sentences, one idea per sentence, common words over rare ones, active voice, front-loaded conclusions, concrete nouns instead of category words. Not because a standard says so, but because each of those choices lowers the effort per sentence, and effort is the whole game.

Because here’s the economic part. A confused visitor doesn’t email you for clarification. Confusion doesn’t announce itself; it just converts to a back button. The visitor half-understands your headline, isn’t sure the product is for them, and leaves, and the analytics record a bounce that looks identical to a thousand other bounces. Companies spend heavily to acquire traffic and then meter it through prose that a third of readers find effortful. If you want a rough audit, take the first sentence a visitor sees on your homepage and ask a smart fifteen-year-old, or a colleague whose first language isn’t English, to say back what it means. If they hesitate, you’ve found lost revenue. When I built GazeSite I made clarity and readability their own scoring areas, separate from technical accessibility, precisely because of this: a site can pass every automated code check and still be incomprehensible, and incomprehensible is a full-strength barrier no ARIA attribute can route around.

The practical method I’d suggest is simple to state. Write the page however you write it, then go back through and translate it into words you’d use across a table. Replace every “utilize” with “use,” every “solution” with what the thing actually is, every abstraction with the concrete fact underneath it. If a sentence resists this treatment, that’s usually a sign you’re not sure what you mean, which is worth knowing. The result reads less impressive to you and more clear to everyone else, and that trade is the entire point. Your inside voice already understands the product. The words on the page exist for everyone who doesn’t yet, and plain ones let the most people in.