WCAG 3.1.5 Reading Level: Making Website Content Easier to Understand

WCAG 3.1.5 Reading Level focuses on making written website content easier to understand by limiting vocabulary, sentence complexity and structure. This article explains what the reading-level idea means for web content, how to measure it, and a practical workflow you can use right away.

What the reading-level concept expects

The goal is clear. Content should be predictable and easy to follow for people with cognitive disabilities, low literacy or for whom the site language is a second language. That means using plain vocabulary, short sentences, clear structure and helpful cues such as headings and lists.

Which content to include

Prioritise content that affects tasks and decisions. Typical items to check first are:

• Task pages: form flows, checkout, registrations.
• Instructions and error messages.
• Legal notices, consent dialogs and privacy summaries.
• Key landing pages that guide navigation or choice.

How reading level is measured

Combine automated scores with human review. Automated formulas find complexity at scale. Human reviewers judge clarity, context and whether wording matches user needs.

Automated formulas to know

• Flesch reading ease and Flesch–Kincaid grade. Give a broad idea of sentence length and word length.
• SMOG and Gunning Fog. Focus on polysyllabic words and sentence complexity.

Human assessment

Ask a person to:

• Read the content aloud and mark confusing phrases.
• Check that headings and lists match the content that follows.
• Run a quick comprehension test: ask a reader to explain the main action in one sentence.

Step-by-step compliance workflow (practical)

1. Map where readability matters: list the top 10 pages or templates that support core tasks.
2. Gather text for each template in a single document. Include labels, help text and error messages.
3. Run an automated readability check to find the most complex text blocks.
4. Prioritise high-impact text for rewrite: calls to action, form instructions and errors first.
5. Apply the plain-language rewrite pattern explained below.
6. Have at least two reviewers: one subject expert and one user or plain-language editor.
7. Test with 3 to 5 representative users if possible, or run a quick comprehension task with colleagues.
8. Publish changes and add a maintenance rule: review text whenever copy changes or after user feedback.

Plain-language rewrite pattern (practical example)

Follow these micro-steps on each paragraph or form label:

• Identify the single message. If a sentence has more than one instruction split it.
• Use a common verb. Prefer “choose”, “enter” or “click” over abstract verbs.
• Shorten sentences. Aim for 15 words or fewer where possible.
• Prefer active voice and second person where it helps the user.
• Replace jargon with a short explanation in parentheses if you must keep the term.

Example — before:

To complete the registration, users are required to provide proof of residency and a verified telephone number; failure to do so will result in delayed activation.

Example — after:

Finish registration by providing proof of where you live and a phone number. We will verify your phone. If you do not provide these, activation may be delayed.

Common mistakes and how to avoid them

• Relying only on automated scores. Tools miss context and user intent.
• Changing tone so much that legal meaning is lost. Keep legal summaries alongside full wording when required.
• Fixing surface issues but leaving navigation or error flows complex. Check messages in the actual task flow.
• Applying a one-size-fits-all target. Different audiences need different levels of detail.

Testing and QA checklist

• Automated readability: record scores for each page or template.
• Human review: mark unclear sentences and suggested rewrites.
• Comprehension test: can 3 users describe the main action in one sentence?
• Consistency check: labels, error messages and help text should use the same verbs.
• Accessibility review: ensure headings, ARIA labels and focus order still match the rewritten text.
• Version control: track the copy change and who approved it.

Legal and policy note (UK)

UK public sector organisations must follow the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, which reference WCAG 2.1 AA. That law does not prescribe a specific reading-grade target. However, plain-language practice and reading-level checks help meet the law’s requirement to make content accessible. Keep legal texts intact and provide a plain-language summary where the law or policy requires full wording.

How to set practical acceptance criteria

Define a pass/fail rule for each content type rather than a single site-wide numeric target. Examples:

• Form labels and error messages: human-reviewed and comprehension-tested.
• Help pages and How-tos: automated score at or below a chosen grade and human review.
• Legal pages: full legal text with a plain-language summary that passes comprehension testing.

Quick checklist to start now

• Identify top 10 task pages.
• Run one automated readability pass on those pages.
• Rewrite three highest-scoring blocks using the plain-language pattern.
• Do a one-question comprehension test with three people.

Further resources and next steps

Use readability tools such as Flesch–Kincaid, SMOG and human plain-language editors together. Add readability checks to your content review workflow and include users with cognitive or literacy needs in testing. Track results and iterate.

If you need a practical audit plan for a specific site, I can outline a sampling plan and a template for reviewer notes.