Skip to content

07 β€” Plain Language (`PRINT-LANG`)

Status: Normative reference. Part of the Print Accessibility knowledge base (Issue #2852). Scope: Comprehension-level requirements for print β€” reading level, sentence/paragraph length, terminology, number/date formatting, imperative instructions β€” and why cognitive accessibility is harder on paper than on any screen.

Sourcing honesty for this section. Everything here is guidance / consensus, not statute or regulation. Reading-level β€œtargets” are professional consensus (Plain Writing Act of 2010 covers federal agency communications as a practice mandate, and healthcare/CMS materials commonly target 6th–8th grade), and the readability formulas are known-flawed proxies (PRINT-LANG-001). No MUST appears in this section; the strongest keyword is SHOULD. Do not present grade-level numbers as legal thresholds.


Level: SHOULD Applies to: all documents Source: Plain-language consensus (plainlanguage.gov / Federal Plain Language Guidelines); healthcare-materials practice (commonly 6th–8th grade); readability-formula literature Source strength: consensus standard / agency guidance Machine-checkable: partial Validation: Compute a readability estimate (Flesch-Kincaid Grade Level and/or SMOG) over the body prose. Treat a result > grade 8 for general-public material as a flag for human review, not a pass/fail. The score is a screen, not a verdict.

General-public documents SHOULD target roughly an 8th-grade reading level (aim 6th–8th for health, benefits, and consent material), measured with a named formula reported alongside its method β€” while acknowledging that readability formulas measure only word/sentence length and syllable counts, not actual comprehension.

Rationale: Formulas reward short words and short sentences; they are blind to jargon a reader has never seen, ambiguous pronouns, unexplained acronyms, passive voice, illogical order, and dense tables β€” a text can score grade 6 and still be incomprehensible, or score grade 11 and be perfectly clear. Reporting the score without its caveats manufactures false confidence. Excludes readers with lower literacy, cognitive disabilities, limited English, and anyone under stress (medical, legal, financial) β€” which is most readers of the documents that most need this. Implementation notes: Our audit tooling CAN compute FK/SMOG and surface it as an assistable signal (candidate for human review) β€” never as an automated WCAG-style pass. Do not gate output on a grade number. Pair the score with concrete flags (long sentences, undefined acronyms) from LANG-002/003 so the human reviewer sees why. This is the honest use of the number.


Level: SHOULD Applies to: all documents Source: Plain-language consensus (plainlanguage.gov) Source strength: consensus standard Machine-checkable: yes Validation: Measurable: flag sentences > 25 words (target average ~15–20) and paragraphs that run beyond ~5–6 lines / one main idea. Counts and offending sentences are reportable.

Sentences SHOULD average roughly 15–20 words and generally stay under ~25 words; paragraphs SHOULD cover one main idea and stay short. Break long sentences into lists or separate sentences.

Rationale: Long sentences overload working memory β€” a paper reader cannot re-flow, enlarge, or have the sentence re-read on demand, so a 40-word sentence must be held in the head in one pass. Excludes readers with cognitive, memory, or attention disabilities and lower-literacy readers. Implementation notes: Directly checkable; surface as flags in the audit alongside LANG-001. Note this is comprehension length, distinct from the physical line-length/measure rule in PRINT-TYPO-010 / PRINT-ALT-001 (characters per line) β€” do not conflate the two.


Level: SHOULD Applies to: all documents Source: Plain-language consensus (plainlanguage.gov) Source strength: consensus standard Machine-checkable: partial Validation: Detectable: acronyms/initialisms introduced without a spelled-out first use can be flagged (first occurrence of an all-caps token not previously expanded). Whether a term is β€œjargon” is human judgment.

Technical terms and jargon SHOULD be avoided or defined in plain words; every abbreviation, acronym, or initialism SHOULD be spelled out on first use with the short form in parentheses, then used consistently. Prefer the common word over the term of art.

Rationale: On paper there is no dictionary lookup, no hover-definition, no search β€” an unexplained acronym or term of art is a dead end the reader cannot resolve. Excludes readers outside the specialist audience, lower-literacy readers, and limited-English readers. Implementation notes: Our tooling can do the mechanical half β€” flag unexpanded first-use acronyms β€” and leave jargon judgment to the human reviewer. This is an assistable check. Ties tightly to LANG-006 (no lookup on paper).


Level: SHOULD Applies to: all documents Source: Plain-language consensus; i18n/Intl formatting practice Source strength: consensus standard Machine-checkable: partial Validation: Partly checkable: flag ambiguous all-numeric dates (e.g. 03/04/05), bare numbers where a unit is expected, and inconsistent number styles within a document. Full correctness is human.

Numbers, dates, and units SHOULD be formatted unambiguously and consistently: write dates in a form that cannot be misread (spell or abbreviate the month β€” β€œMarch 4, 2025” β€” rather than all-numeric 3/4/25), keep units explicit and adjacent to their value, and use digits for numbers the reader must act on. Use locale-appropriate formatting (Intl formatters, not string concatenation).

Rationale: 03/04/05 is three different dates in three regions; a bare β€œgive 5” without a unit is a dosing or payment error waiting to happen. Paper offers no tooltip to disambiguate. Excludes readers who misread the ambiguous form β€” with real safety/financial consequences in medical and benefits documents. Implementation notes: Our reflow lane should render dates/numbers via Intl and respect locale, matching the global i18n rule. The audit can flag all-numeric dates as an assistable signal. Keep this consistent with the project’s i18n formatting standard rather than inventing a second convention.


Level: SHOULD Applies to: all documents (forms and instructional content especially) Source: Plain-language consensus (plainlanguage.gov β€” β€œuse the imperative mood for instructions”) Source strength: consensus standard Machine-checkable: partial Validation: Detectable tendency: instruction steps in passive voice or nominalizations (β€œCompletion of Section B is required”) can be flagged; imperative phrasing (β€œComplete Section B”) is the target. Human confirms tone/accuracy.

Instructions SHOULD be written as direct imperatives addressed to the reader (β€œEnter your date of birth,” β€œSign and date below”) rather than passive or third-person constructions (β€œThe applicant’s date of birth should be entered”). One instruction per step; put the instruction before the field it governs (see PRINT-FORM-013).

Rationale: Imperatives are shorter, unambiguous about who does what, and easiest to follow under stress; passive/nominalized instructions hide the actor and increase reading load. Excludes lower-literacy, cognitive-disability, and limited-English readers, and anyone hurrying to complete a form correctly. Implementation notes: For forms, this reinforces PRINT-FORM-013 (instructions before the field). Our tooling can flag passive-voice instruction candidates as assistable; rewriting is human (or an AI-assisted suggestion the reviewer approves). Do not auto-rewrite legal/consent language without review.


Level: SHOULD Applies to: all documents Source: our-implementation rule (analytical; the framing thesis of this KB β€” affordances live in a non-printing layer) Source strength: consensus standard Machine-checkable: no Validation: Not a measurable property of one document β€” it is the rationale that raises the priority of LANG-001..005 for print. Validation is: when a document is destined for paper, the plain-language checks above are treated as more important, not optional, because the digital fallbacks are gone.

Because a printed document offers no zoom, no read-aloud/TTS, no dictionary or search lookup, no translation, and no way to ask the document a question, the plain-language requirements (LANG-001..005) carry more weight on paper than on screen: comprehension supports that a digital reader can summon on demand simply do not exist. Print therefore SHOULD meet plain-language guidance more strictly than the same content would need to on an accessible web page.

Rationale: On a screen, a reader who hits a hard word can enlarge it, have it read aloud, look it up, translate the page, or search related text β€” a cognitive scaffold that partially compensates for dense writing. Paper strips all of it away; the words on the page are the entire interface. So the readers most affected by cognitive load β€” cognitive disabilities, lower literacy, limited English, and situationally impaired (stressed, distracted, ill) readers β€” have no recourse in print. This is why plain language is not a β€œnice to have” for print but a core accessibility affordance, and it is the print-specific counterpart to the KB’s central thesis: the affordances live in a non-printing layer, so the visible words must carry them. Implementation notes: No per-document check β€” this entry is the why that promotes LANG-001..005 from optional polish to required for any print-destined output. Operationally: when our pipeline knows the target is paper (large-print profile, print-safe profile, forms), it should surface the plain-language flags more prominently in the audit/ACR and treat unaddressed ones as higher-severity than it would for a screen-only artifact. The flipbook and screen surfaces retain the digital scaffolds and are not held to this heightened bar.