Plain Language Writing

Plain language is writing that is clear enough for your intended audience to understand on the first reading. It is not “dumbed down” writing — it is respectful, precise writing that removes unnecessary complexity and respects the reader’s time.

Plain language is required for full cognitive accessibility, and it improves comprehension for every reader: people with cognitive and learning disabilities, Deaf Canadians who read English or French as a second language, newcomers to Canada, older adults, stressed or tired readers, and first-time visitors to your service.

Reading level guidance

Author

What reading level to target

Audience	Target reading level	Approximate Canadian grade
General public	Lower secondary	Grade 7–8
Technical/professional	Upper secondary	Grade 10–11
Academic	No specific target	As required
Government services	Grade 6–8	Required under GC writing guidance
Health information	Grade 6	Health Canada guidance

How to check reading level

Most word processors provide readability statistics. In Microsoft Word: Review → Check Accessibility (or Editor) → Document Stats. Look for:

• Flesch Reading Ease: aim for 60–70+ (higher = easier)
• Flesch-Kincaid Grade Level: aim for Grade 8 or below for general audiences
• Passive sentences %: aim for under 5%

Online tools: Hemingway Editor (hemingwayapp.com) highlights dense sentences, passive voice, and complex words in real time. Readable.com provides detailed readability scores with actionable suggestions.

Sentence and paragraph structure

Sentence length

• Target 15–20 words per sentence for general audiences
• One idea per sentence
• If a sentence runs past 25 words, split it
• Never nest clauses inside clauses: “The form, which must be submitted within 30 days of the event that triggered the obligation, requires three supporting documents.” → “You have 30 days to submit the form. It requires three supporting documents.”

Paragraph length

• 3–5 sentences per paragraph for body text
• One topic per paragraph
• Short paragraphs are not a sign of poor writing — they aid comprehension and skim-reading
• Web paragraphs should be shorter than print paragraphs; screen reading is 25–30% slower than print

Active vs passive voice

Prefer active voice. It is shorter, clearer, and directly addresses the reader.

Passive (avoid)	Active (prefer)
The form must be submitted by the applicant	You must submit the form
Errors were found in the application	We found errors in your application
This field is required	This field is required (acceptable — agent is obvious)
The decision will be communicated to you	We will contact you with the decision

Passive voice is acceptable when the agent is genuinely unknown or irrelevant: “The bridge was built in 1923.”

Word choice

Use common words

Replace formal or technical language with everyday equivalents:

Avoid	Prefer
Utilize	Use
Commence	Start or begin
Facilitate	Help
Endeavour	Try
Prior to	Before
Subsequent to	After
In the event that	If
With respect to	About
Notwithstanding	Despite
Ascertain	Find out
Remuneration	Pay
Procurement	Buying / purchasing

Define jargon and acronyms

• Write the full term before using the abbreviation: “The Accessibility for Ontarians with Disabilities Act (AODA) requires…”
• Provide a glossary for pages that rely heavily on technical terms
• Do not assume readers know sector-specific acronyms — even common ones like WCAG, AODA, or CRA

Avoid double negatives

Double negatives require two mental operations. Rewrite them:

Double negative	Positive equivalent
Not uncommon	Common
Not without risk	Risky
You must not fail to submit	You must submit
There are no exceptions that do not apply	All exceptions apply

Headings and structure

Author

Heading hierarchy

Headings allow users to scan the page and navigate with screen readers. They are not just visual — they communicate document structure.

• H1: Page title — one per page, matches the page topic
• H2: Major sections
• H3: Subsections of H2 content
• Never skip heading levels (do not jump from H2 to H4)
• Never use heading markup for visual styling — use CSS classes instead

Heading wording

• Use parallel structure within a section: if your H2s start with verbs, keep them all starting with verbs
• Be specific: “Filing a complaint” not “Process”
• Avoid clever headings that require context to understand — navigation by headings happens out of context
• Front-load the key word: “Documents required” not “What documents you need to provide”

Use lists

Use bullet or numbered lists when:

• You have 3 or more parallel items
• Items are genuinely list-like, not prose
• A numbered list is appropriate for sequential steps

Avoid:

• Wrapping a single-item list in a <ul> (use a sentence instead)
• Lists with more than 7–8 items at one level (consider grouping with subheadings)
• Incomplete sentences as list items with no clear context from the introduction

Tables

Use tables for comparative or relational data. Avoid using tables for layout.

Good use of a table: comparing compliance deadlines across organization sizes. Poor use of a table: two-column “key / value” pairs that read naturally as a list.

Every data table needs:

• A descriptive <caption> or heading immediately above
• <th> elements for header cells, with scope="col" or scope="row"
• No merged cells unless essential (they are difficult to interpret by screen reader)

Link text

Author Developer

Link text is read out of context — screen reader users can navigate by links alone, jumping from link to link across a page. Every link must make sense on its own.

Rules for link text

• Describe the destination: “Read the AODA compliance checklist” not “Click here”
• Include the format for non-HTML files: “Download the AODA audit template (PDF, 430 KB)”
• Avoid generic phrases: “Click here”, “Read more”, “Learn more”, “More”, “Here” are not acceptable as complete link text
• Avoid repeating the URL as visible text: unless the URL itself is meaningful content (e.g., a reference)
• Do not use the same text for different destinations: if two links go to different places, they must have different link text

Link text patterns

<!-- Bad: generic -->
<a href="/aoda">Click here</a> to read about the AODA.

<!-- Good: descriptive -->
Read about the <a href="/aoda">Accessibility for Ontarians with Disabilities Act (AODA)</a>.

<!-- Bad: format not indicated -->
<a href="/resources/audit-template.pdf">Download the audit template</a>

<!-- Good: format and size indicated -->
<a href="/resources/audit-template.pdf">Download the AODA audit template (PDF, 430 KB)</a>

<!-- Bad: ambiguous "read more" links -->
<h3>WCAG 2.2 Updates</h3>
<p>Nine new success criteria were added...</p>
<a href="/wcag-levels">Read more</a>

<!-- Good: descriptive link embedded in context, or labelled -->
<h3>WCAG 2.2 Updates</h3>
<p>Nine new success criteria were added... <a href="/wcag-levels">Read about all WCAG 2.2 changes</a>.</p>

Opening links in new tabs

Avoid opening links in a new tab or window without warning the user. This is disorienting for screen reader users and keyboard users who lose context.

If you must open in a new tab:

• Add “(opens in a new tab)” to the visible link text, or
• Use an icon with an accessible name: <span class="sr-only">(opens in a new tab)</span>

<a href="https://www.canada.ca/aoda" target="_blank" rel="noopener noreferrer">
  View the AODA on Canada.ca
  <span class="sr-only">(opens in a new tab)</span>
</a>

Accessible PDFs

Author

PDFs are one of the most common accessibility barriers on the web. An untagged PDF is inaccessible to screen readers. A scanned-image PDF contains no readable text at all.

When to avoid PDF

Where possible, publish content as HTML. HTML is:

• Accessible by default with proper markup
• Responsive (works on all screen sizes)
• Searchable, translatable, and maintainable
• Readable without a plugin

Use PDF when:

• A printable form is genuinely needed
• A document has complex layout that must be preserved exactly (e.g., a legal instrument)
• An official signed version must be distributed

Always provide an HTML alternative when publishing essential information as PDF.

Creating accessible PDFs

From Microsoft Word or Google Docs

1. Structure the source document with proper heading styles (Heading 1, Heading 2, etc.), not manually sized text
2. Add alt text to all images in the source file
3. Use proper list styles — not manually typed ”•” characters
4. Define table headers in the table properties
5. Export to PDF with accessibility options: File → Save As → PDF → Options → check “Document structure tags for accessibility” (Word) or use the Accessibility Checker first
6. Add document properties: Title, Author, Language in File → Properties

Checking PDF accessibility

• Adobe Acrobat Pro: Tools → Accessibility → Full Check
• PAC (PDF Accessibility Checker) — free download, provides detailed accessibility report
• Common failures: missing document title, reading order incorrect, images untagged, form fields unlabelled

Minimum requirements for an accessible PDF

• Document title is set in document properties
• Language is set (affects screen reader pronunciation)
• All images have alt text (or are marked as decorative artifacts)
• Heading structure is present and logical
• Tables have header rows tagged
• Reading order matches visual order
• Links have descriptive text
• Forms: all fields have labels, tab order is correct
• Colour is not the only means of conveying information

Scanned PDFs

A PDF created by scanning a paper document is an image. Without OCR (Optical Character Recognition), it has no text content — only a picture of text. Screen readers cannot read it.

To fix a scanned PDF:

1. Use Adobe Acrobat Pro’s OCR feature (Tools → Scan & OCR → Recognize Text)
2. Verify OCR accuracy by reading the result
3. Add tags, heading structure, and alt text as needed

Never publish a scanned PDF as the only format for essential information.

Plain language checklist

Author

Use this checklist before publishing any web content:

Structure

• The page has one clear H1 that matches the page topic
• Heading levels are not skipped
• Paragraphs are 3–5 sentences maximum
• Lists are used for 3+ parallel items

Language

• Sentences average 15–20 words
• Active voice is used throughout
• Common words are preferred over formal equivalents
• All acronyms and jargon are defined on first use
• No double negatives

Links

• All link text describes the destination
• Non-HTML file links identify the format and size
• No “click here”, “read more”, or “here” link text
• Links opening in new tabs are labelled

Tables

• Tables are used for data, not layout
• All tables have captions or headings
• Header cells use <th> with scope attributes

PDFs (if applicable)

• An HTML alternative is provided for essential information
• The PDF has document title and language set
• All images in the PDF have alt text
• PDF heading structure matches the source document

Related pages

• Cognitive and Learning Disabilities — how plain language reduces barriers for cognitive disabilities
• Hearing Disabilities — plain language for Deaf readers who use sign language as their first language
• Images and Media — writing effective alt text
• Design Principles — typography and layout that supports readability