Clarify the task and decision
This guide turns human review for accessible language into a reviewable operating workflow. It connects domain decisions, ownership, evidence, and acceptance so the result continues to work in production.
Every production workflow needs named reviewers, risk-based acceptance criteria, and an auditable approval decision.
Practical workflow
- 1
Define the audience with evidence, including reading experience, context, device, and support available.
- 2
Select one real task and state what a successful reader must understand or do.
- 3
Create the language version while preserving every decision-relevant fact, condition, date, and contact path.
- 4
Run specialist and editorial review with recorded acceptance criteria.
- 5
Test with members of the intended audience, record findings, revise, and approve the release.
Worked example or tool
A two-stage review catches meaning changes before an accessibility and audience review. In the tool, also record the baseline, owner, decision, evidence, open issue, and approval date. Use a real page or transaction so the team sees dependencies, exceptions, and the maintenance work that follows release.
| Decision point | Record | Acceptance criterion |
|---|---|---|
| Baseline | Observed current state | Source and date recorded |
| Decision | Selected option and rationale | Risk and audience considered |
| Evidence | Test, document, or measure | Reviewable and version-specific |
| Approval | Name, role, and date | All mandatory criteria met |
Match review depth to content risk
Classify content before work starts. Level 1 covers low-impact, stable information such as opening hours and general orientation. One trained editor and automated checks may approve it. Level 2 covers service instructions, eligibility summaries, and content with deadlines or required documents. It needs a subject owner and a language reviewer. Level 3 covers legal rights, health, safety, significant financial consequences, and Easy Language intended for a defined audience. It requires independent subject review, specialist language review, and evidence from audience testing.
Risk levels determine who can approve, which defects block release, and how quickly a change can follow the source. They should not become labels that slow every page equally. Define an expedited route for urgent corrections: publish an accurate Plain Language update with two-person review, record the exception, and complete specialist or audience review within a fixed period when the selected mode requires it.
| Risk | Minimum reviewers | Blocking defects | Evidence |
|---|---|---|---|
| Level 1 | Editor | Wrong fact, missing action, broken link | Editorial checklist |
| Level 2 | Subject owner and language reviewer | Changed condition, deadline, amount, or responsibility | Source comparison and task check |
| Level 3 | Independent subject, specialist language, target audience | Any critical misunderstanding or unsupported omission | Versioned reviews and audience-test record |
Separate accuracy review from language review
The first reviewer performs a meaning comparison. They work proposition by proposition, checking actors, actions, conditions, exceptions, dates, amounts, evidence requirements, contact paths, and legal references against the approved source. They mark every intentional omission or added example and confirm its effect. This review occurs before stylistic polishing so an elegant sentence cannot conceal a changed requirement.
The second reviewer assesses language and use. They check information order, headings, terminology, sentence structure, references, examples, visual grouping, links, and the next action. For Easy Language, use a reviewer qualified for the selected rule set and include the agreed target-audience process. Reviewers must resolve comments in the content system, not in detached email threads, so the approved wording and rationale remain connected to the released revision.
- 1
Freeze and identify the exact source revision.
- 2
Complete a proposition-level accuracy comparison.
- 3
Resolve all factual and scope findings before language approval.
- 4
Complete language, accessibility, and task review on the resulting revision.
- 5
Record approval, residual issues, and the source-change trigger.
Use defect severity and clear acceptance criteria
Classify findings as critical, major, or minor. A critical defect can cause a wrong decision or failed task, such as omitting a deadline or reversing an eligibility condition. A major defect creates substantial avoidable effort or misunderstanding, such as an unexplained mandatory term or ambiguous pronoun. A minor defect affects consistency or polish without changing the task. Critical and major defects block release. Minor defects can be accepted only with an owner and due date.
A review is complete when every required role has assessed the same revision, all blocking defects are closed, link and control labels have been checked in context, the source relationship is recorded, and approval is attributable to named roles and a date. A comment count is not a quality measure. Track escaped critical defects, time to resolution, disagreement patterns, and repeated terminology issues to improve the process.
Every finding identifies the affected wording, risk, and proposed resolution.
Reviewers use critical, major, and minor severity consistently.
No reviewer approves a revision that changed after their review without a visible diff.
Accepted minor defects have an owner and completion date.
Approval records the source revision and released language revision.
Build a review service that can scale
Maintain a reviewer roster that lists competence, authorised risk levels, languages, absence cover, and expected response time. Use queues by risk and deadline, not by whoever asks most loudly. Templates should preload the correct checklist and required roles from the content classification. Reviewers need access to the authoritative source, relevant policy, terminology decisions, audience evidence, and a rendered preview of the full journey.
Review a sample of released work each month. Examine defects found after publication, support contacts, failed tasks, and source changes that did not reopen the language version. Use the findings to improve instructions, reviewer calibration, and CMS controls. When two reviewers repeatedly disagree, decide the underlying rule and add it to the terminology or editorial standard instead of resolving each occurrence from scratch.
Roles, evidence, and approval
Language quality is an operating responsibility. Give the source owner responsibility for factual accuracy, an editor responsibility for clarity, a specialist responsibility for accessibility rules, and a product owner responsibility for publication. The release record should identify the source version, language mode, reviewers, test evidence, approval date, and the event that triggers a new review.
Operations and maintenance
The work does not end at publication. Link the language version or configuration to its source, monitor quality and service measures, and define concrete review triggers. Triggers include source changes, legal changes, new audience needs, recurring support questions, technical changes, and incidents. A named owner evaluates the trigger, opens a new revision when needed, and records renewed approval.
Release checklist
The audience and task are explicit.
All legal and operational facts match the source.
Dates, amounts, conditions, and exceptions are complete.
Headings describe reader questions or actions.
Links and controls have meaningful labels.
Specialist terminology is explained consistently.
The intended audience has tested the critical journey.
Ownership and the next review trigger are recorded.