How to Improve Web Readability with Plain Language

Readability is more than short words and sentences

A formula can count sentence length and estimate word difficulty. It cannot tell whether a warning appears before the risky action, a pronoun has a clear referent, an instruction omits a step, or a technical term is necessary for the audience.

Plain language is not childish language. It communicates the right information, in the right order, at the level of detail the intended reader needs. A specialist audience can handle specialist terms; it should not have to decode avoidable bureaucracy or vague instructions.

Place reading level in the wider WCAG picture

WCAG 2.2 Success Criterion 3.1.5, Reading Level, is Level AAA. When text requires reading ability beyond the lower secondary education level after proper names and titles are removed, supplemental content or a version that does not require that advanced ability must be available.

Related criteria address other parts of readability. At Level A, the default language of the page must be programmatically determinable. At Level AA, changes in language within content must be identifiable, with defined exceptions. At Level AAA, mechanisms are available for identifying unusual or restricted word meanings and for expanding abbreviations.

Define the reader and task before editing

“Write for everyone” is too vague to guide decisions. Identify who must use the content, what they already know, what they need to do, and the consequences of misunderstanding it.

Secondary readers still matter, but the page needs a clear primary path. If experts and newcomers need different depths, use a short overview followed by expandable detail, examples, or a separate technical reference.

Put the answer and action before the background

Many web pages begin with organizational history, legal framing, or a long explanation before revealing what the reader must do. Reverse that order. Lead with the decision, outcome, deadline, warning, or next step. Then provide reasons and exceptions.

The revision is not merely shorter. It reveals the deadline, location, action, outcome, and confirmation in the sequence the reader needs. It also replaces abstract nouns such as “initiate a request for termination” with the direct verb “cancel.”

Write direct sentences with visible actors and actions

Readers understand instructions more easily when a sentence names who does what. Active voice often creates that pattern: “We will review your request” is clearer than “Your request will be reviewed.” Passive voice is not forbidden; it can be appropriate when the actor is unknown, obvious, or less important than the result.

A sentence should normally carry one main point, but do not chop related ideas into a staccato sequence merely to lower a score. Combine short sentences when their relationship becomes clearer together.

Prefer familiar words, but preserve necessary precision

Replace formal or inflated wording when a familiar word has the same meaning: “use” instead of “utilize,” “help” instead of “facilitate,” and “about” instead of “with regard to.” Avoid idioms when readers may interpret them literally or translate them across languages.

Technical terms can be essential. Do not replace “alt attribute,” “contrast ratio,” or “semantic HTML” with vague language that loses accuracy. Define each unfamiliar term at first use, give a concrete example, and use the same term consistently afterward.

For a general audience, explain jargon inline or link it to a glossary. If a term has a special meaning on your site, provide that specific definition rather than assuming a general dictionary will return the intended one.

Expand abbreviations before asking readers to remember them

Write the full term at first use followed by the abbreviation in parentheses: “Web Content Accessibility Guidelines (WCAG).” Then use WCAG consistently. If the shortened form appears only once or twice, consider omitting it entirely.

An abbreviation can have several meanings. “AT” might mean assistive technology, attention, or Austria in different contexts. When the same letters mean different things on one page, clarify each occurrence. An abbr element with a title can supplement a definition, but do not rely on hover-only presentation as the sole explanation.

Make the page scannable without turning it into fragments

Web readers often look for one fact or action rather than reading every line. Structure helps them find the relevant passage and preserves context once they arrive.

• Use one descriptive page heading and specific section headings.
• Keep the main answer near the start and move specialist detail later.
• Use short paragraphs that develop one connected idea.
• Use numbered lists for sequences and bullets for unordered choices.
• Put conditions before actions when the condition determines whether the step applies.
• Use tables only for genuine row-and-column relationships.
• Give links names that describe their destinations.
• Use examples immediately after the rule they illustrate.

Do not create a heading for every sentence or convert coherent prose into dozens of isolated bullets. Readers still need relationships, transitions, reasons, and exceptions.

Interpret readability scores as signals, not grades for the writer

Common English formulas estimate difficulty mainly from sentence length and word or syllable length. A reading-ease score usually rises as the text becomes easier according to the formula. A grade-level estimate suggests the school grade associated with the measured language pattern.

The numbers are useful for comparing drafts of similar content and finding outlier passages. They are unreliable as a universal quality target because:

• Syllable estimation can miscount names, abbreviations, numbers, URLs, code, and specialized terms.
• Short sentences can still be vague, illogical, or missing steps.
• A long sentence can be clear when its structure and relationships are controlled.
• Formulas do not measure layout, heading quality, prior knowledge, cultural context, or factual accuracy.
• Scores developed for English should not be applied unchanged to other languages.
• Averages can hide one extremely dense warning or policy paragraph.

Edit in passes instead of chasing every warning at once

1. State the reader’s task.Write one sentence describing what the reader must know or do after using the page.
2. Fix completeness and order.Add missing steps, put the answer first, and separate primary guidance from exceptions.
3. Build the outline.Use descriptive headings, coherent paragraphs, and lists only where their structure helps.
4. Edit sentences.Name actors and actions, split overloaded clauses, and remove empty openings.
5. Edit words.Replace avoidable complexity, define necessary terms, and expand unfamiliar abbreviations.
6. Run the checker.Review sentence length, difficult-word signals, passive constructions, and readability estimates.
7. Evaluate every suggestion.Keep technical accuracy and natural rhythm; reject edits that distort meaning.
8. Test with readers.Ask representative users to find information, explain it, and perform the task without coaching.
9. Verify the published page.Review headings, links, zoom, language metadata, responsive layout, and any text inserted by the WordPress theme.

Test comprehension through realistic questions

“Do you understand?” invites a polite yes. Ask readers to demonstrate understanding instead:

• What is the first action you would take?
• Which deadline applies to you?
• What information must you prepare?
• What happens after you submit?
• Where would you go if the request is rejected?
• Explain this term in your own words.

Observe where people hesitate, reread, choose the wrong link, or interpret a condition differently. Test with users who reflect the intended audience, including people with cognitive, language, learning, or visual disabilities where relevant. Treat their errors as evidence about the content, not as failures by the reader.

Review the complete WordPress reading experience

The article body is only part of the page. Themes, reusable blocks, cookie notices, forms, related posts, navigation, and calls to action add text and may interrupt the intended sequence.

A readable draft can become confusing when a newsletter form splits a procedure or a floating notice covers the next step. Review the final published page at multiple viewport sizes and with browser zoom, not only the WordPress editor.

What the Readability and Plain Language Checker can—and cannot—do

The DOFIW Readability and Plain Language Checker analyzes text locally in the browser; the submitted content is not uploaded to a server. It can calculate common readability estimates, sentence and word statistics, and flag patterns such as long sentences, complex wording, or possible passive constructions.

Automatic passive-voice detection and syllable counting are approximate. Do not rewrite every flagged sentence. Review the passage in context, make the smallest useful edit, and rerun the tool to compare—not to pursue a perfect score.

Common readability mistakes and direct fixes

• Writing before defining the task: identify the reader, decision, action, and consequence first.
• Background before the answer: lead with the outcome, deadline, warning, or next step.
• Long noun chains: restore actors and verbs.
• Every passive sentence flagged as wrong: change only those that hide responsibility or make the action harder to follow.
• Technical terms deleted: keep precise vocabulary and explain it for the intended audience.
• Abbreviations introduced unnecessarily: use the full term when the short form offers no real benefit.
• Paragraphs chopped into bullets: use list structure only when items are parallel or sequential.
• Short sentences without connections: preserve cause, condition, contrast, and sequence.
• One score applied to all content: set goals by audience, risk, purpose, and genre.
• Average score hides critical text: inspect warnings, instructions, errors, and legal consequences separately.
• Automated suggestions accepted blindly: verify meaning, tone, grammar, and factual accuracy after every edit.
• Only the draft tested: include the published theme, forms, notices, links, and responsive presentation.

Plain-language and readability checklist

Continue the DOFIW clear-content workflow

Frequently asked questions