AI simplification of Easy Read texts: automating content accessibility

Easy Read documents are usually adapted manually, and at large volumes this runs into deadlines and team resources. We automate Easy Read text simplification turnkey: we analyze your corpus, configure rules and the model for your vocabulary, and hand over regulations to your editors. The adaptation cycle is reduced severalfold, and the share of manual editing drops.
Frequently Asked Questions

Why Easy Read text simplification does not scale manually

Simplifying Easy Read texts seems like a task for a couple of evenings, as long as it is about a dozen pages.

One document of twenty to thirty pages takes an editor several days: cutting sentences to one idea, selecting words from a basic vocabulary, making sure each semantic block is supported by an illustration and does not lose legal precision.

With a flow of dozens of documents per month, the queue of documents grows faster than it can be processed.

The second problem is divergence in editorial edits. Two specialists simplify the same instruction differently: each has their own stock of "simple" words, their own sentence length, their own decision about when a term can be replaced and when it is mandatory.

Without a common glossary, plain language ceases to be a standard and turns into the personal style of a particular editor, and the reader gets different versions of the same rule.

The cost of such a scheme is not speed but coverage. While editors process priority documents, regulations, safety instructions, contracts and memos wait in line, and part of the audience remains without an accessible version.

The order here is determined not by the document's importance to the person but by the availability of a free editor.

Machine processing does not replace the editor but removes the mechanical part from them: parsing structure, finding candidates for simplification, replacing by glossary, controlling sentence length and readability level. A human checks and approves the result — let's look at how this works in practice.

What changes after implementation: timelines, volumes, share of manual editing

The cycle for preparing an accessible version stops being measured in weeks.

Previously, an editor manually rewrote a document according to Easy Read rules: split long phrases, removed bureaucratic language, selected simple synonyms — a regulation of several dozen pages took a work week. Now the draft is assembled in minutes, and the editor arrives at already finished text.

Volume of processing is measured not in pieces but as an array. The machine handles regulations, instructions, memos, consent forms and website sections in batches: one run — the entire collection, with a unified terminology dictionary and common markup.

Documents that previously did not reach the editor now receive an accessible version — coverage grows severalfold, not by percentages.

The share of manual editing is the main metric of the project, and it does not tend toward zero. Automation marks up structure, cuts sentences and highlights what requires a human decision: terms outside the dictionary, legal wording, references to norms.

Quality control and approval remain with the editor — they edit about a fifth of the text, and without their acceptance the version is not published. The criteria are set by Inclusion Europe recommendations on Easy-to-Read: simplification rules are configured according to them.

Repeatability is more important than a one-time result. Rules, a correspondence dictionary and a layout template are fixed in the project, so the next version of the same document is assembled by the same logic.

When the source is updated, only the changed fragment is reassembled — the editor sees the delta, not the entire text anew.

Implementation options: manual editor, replacement rules, model

The simplification scheme is chosen by three parameters: volume of flow, homogeneity of texts and cost of an error in a specific document.

A safety instruction and a news feed require different things — in the first case it is more important not to lose legal wording, in the second to maintain speed across thousands of paragraphs. Below are four working schemes that are actually chosen between, and their limits.

Option When suitable Limitations
Manual simplification by an editor Small volumes, legally significant texts, rare genres; a verified result is needed Speed is linear by volume, discrepancies in wording accumulate between editors
Replacement dictionary and rules Recurring wording: regulations, instructions, letter templates, reference notes Does not restructure sentence structure, stumbles on homonymy, dictionary requires constant maintenance
Model on your texts Large volumes, heterogeneous content, flow of new materials Requires a corpus with reference simplifications; without a layer of checks, semantic distortions and unnecessary additions are possible
Hybrid scheme Mixed flow: terminology plus free text, high stakes on meaning More difficult support: rules, model and acceptance live together, a person responsible for dictionary and markup quality is needed

Where each scheme hits its limit

Guidance for selection is the share of paragraphs that pass acceptance without edits and the number of semantic distortions per thousand sentences. If the dictionary does not cover a noticeable part of the text, it does not scale to new content.

If the model distorts meaning more often than the regulation allows, control-question checking is added to it and a ban on introducing new terms.

How we manage implementation: from corpus analysis to handover

Implementation begins with inventory, not configuration: we analyze the corpus of texts — what types of documents exist, who reads them, where wording must remain verbatim.

From this grow the terminology glossary and the list of exceptions — without them, automatic simplification breaks legally significant paragraphs.

  1. Corpus analysis. We manually mark up a sample: where we reduce complexity, where we only restructure, which terms we leave verbatim.
  2. Processing scheme. We fix the steps: parsing document structure, simplifying wording, checking meaning preservation, assembling into the original markup.
  3. Glossary and abbreviation rules. We agree them with the customer's editors so terminology does not diverge between documents.
  4. Pilot set of documents. We run 10–20 typical texts and see where the rules make mistakes and what clarifications are missing.
  5. Acceptance criteria. We set thresholds in advance: share of paragraphs without loss of meaning, preservation of mandatory wording, unified style and structure.
  6. Setup on the flow. We connect the document source, add checks and notifications about disputed fragments.
  7. Handover to operation. Documentation, analysis of complex cases, editor training and amendment regulations.

Before handover, we run a regression set — it shows that new rules have not broken previously agreed texts. After that, editors work independently, and we remain in contact regarding rule changes.

What remains in your hands: rules, dictionary, regulations

We do not tie the process to ourselves: after launch, the customer's team has a working kit by which Easy Read versions are prepared on their own.

Each artifact is not a description of "how we did it" but a working instruction: what to change in the text, who approves, by what criteria to accept the result.

  • Replacement dictionary — a "complex term → simple wording" table with a note where an explanatory comment or illustration is needed; the editor expands it as new topics appear.
  • Processing rules — formalized constraints: sentence length, one idea per line, expansion of an abbreviation at first use, rejection of nested constructions.
  • Editor regulations — who edits the text at which stage, what level of edits is considered final, who approves publication.
  • Verification instruction — a step-by-step acceptance checklist: comparison with the source, control of semantic losses, checking markup and readability of the finished file.
  • Process scheme — the path from source publication to release: automatic processing, manual proofreading, release, version in archive.
  • Quality criteria — metrics that show the process is alive: share of texts accepted on first proofreading, and average number of edits per document.

We hand over the kit together with training and analysis on your materials, and remain in contact for expansion: new document types, additional languages, integration into the editorial workflow.

Case study: how the document adaptation cycle was shortened

The customer brought batches of 40–60 documents — regulations, operating instructions, employee memos — and adapting each batch took about three weeks. The text went through an editor, then proofreading, then returned to the author if meaning was lost after simplification.

We started with measurement: we assembled a reference set of documents and calculated readability scores before and after manual editing — to understand exactly where time was going.

Readability score is not a single point but a set of thresholds: average sentence length, share of words with abstract meaning, number of nested constructions, depth of lists.

These thresholds and simplification rules formed the basis of the automatic pass according to the Easy Read standard: the document is divided into semantic blocks, wording is rewritten, and fragments that fail the threshold are marked. They go to the editor selectively — instead of proofreading the whole document.

Metrics before and after

  • batch adaptation cycle — from 15 working days to 3–4;
  • share of documents passing without human edits — from zero to 70%;
  • returns for revision from the approver — from 35% to 9%;
  • documents passing the readability threshold on the first pass — from 55% to 94%.

The sustainability was provided not by automatic translation into simplified language itself, but by fixed rules: when requirements change, a repeat run over the archive is launched, and publication versions are stored so that the previous one can be restored.

Output grew threefold with the same team of editors — the bottleneck shifted from routine rewriting to analysis of disputed wording.

What to do if some documents have already been adapted manually?

A mixed array is a normal state of an accessibility project: some materials have already undergone manual simplification, some remain in their original form.

Manual versions are more valuable than automatic ones — they contain the editor's decisions, disputed wording and already agreed terminology. Therefore automation is integrated not instead of them but on top: finished files become the reference by which rules are calibrated.

Work begins with inventory: for each document, it is recorded which blocks are already simplified, which source they are tied to, and who was responsible for edits.

Markup is preserved — headings, lists, tables and image captions are parsed by structure, not as continuous text, otherwise layout falls apart during reprocessing. Then automation processes only the delta: new materials and those sections that have not yet undergone adaptation.

A unified glossary is assembled from approved versions: terms, stable replacements of complex phrases and prohibited wording are exported to a registry and connected as a rule for all subsequent runs.

In this way, the legacy of manual work is not lost but begins to work for the entire array. Version comparison is done pairwise — the source and simplified text are matched by paragraphs, discrepancies in meaning, numbers and proper names go to the editor, not to publication.

A lossless transition is checked on a control set: the same documents are run through new rules, and the result is compared with reference manual versions by preservation of facts and readability level.

If discrepancies exceed the acceptable level, the rule is refined before the entire catalog enters processing. Easy Read sets the frame here: simplicity must not be paid for with loss of accuracy.

Questions before start: quality, privacy, processing volumes

Semantic accuracy is the main risk in automatic simplification: the algorithm may replace a term with a similarly sounding synonym, lose a negation or merge two points of an instruction into one.

Therefore the process has two verification loops: automatic comparison of numbers, names and logical connectors with the source, and manual proofreading by an editor using a control list. The result is simplified text that can be checked line by line against the original.

Work with terms begins before the first processing: we assemble a glossary — what we simplify, what we leave as is and explain with a footnote, what we put into the dictionary at the end of the document.

The glossary becomes part of the configuration, so repeated processing of similar documents yields stable vocabulary, not a new variant on each run.

The processing mode is chosen at the assessment stage: analysis within your environment, when documents do not leave the perimeter, or an external service with preliminary anonymization.

Marking examples — a corpus of pairs "complex fragment → simplified" — calibrates rules for your genre: instructions, contracts, memos. Version updates go through a regression set: a rule change is accepted only after a run on agreed examples.

The model makes mistakes with negations — how do you catch this?

Negations, numbers, dates and names are placed in a separate layer of checks: they are compared with the source automatically, and discrepancies go to the editor. Fragments with conditions and double negation are marked as requiring manual confirmation.

Do documents go to third-party servers?

It depends on the selected mode. With analysis within your environment, sources do not leave the perimeter; with external processing, personal data and service notes are removed from the text in advance.

What to do with new document types?

We add them to the corpus of examples and run them through the regression set — rules are updated only after the agreed output remains unchanged.

Let's discuss the task and come back with an estimate and plan

Send several typical documents in source formats: layout, text files, scans and photos of pages if the flow comes from paper.

The more heterogeneous the examples, the more accurate the volume estimate — scans add recognition and cleanup, complex layout adds parsing of tables and footnotes.

It is useful to attach a glossary of terms that cannot be rewritten in your own words, and a sample finished Easy Read text that suits you.

Using these examples, we run a draft pipeline: text extraction, division into semantic blocks, simplification of wording, readability control by sentence length and dictionary.

It is visible on your own documents where automation copes and where editor proofreading is needed, and what share each stage occupies.

With this picture, we return with a plan:

  • volume estimate: how many documents and pages, mode — continuous or piecemeal;
  • processing scheme: where recognition, where simplification, where manual checking;
  • simplification rules and glossary for your subject: what we rewrite and what we fix verbatim;
  • output template: card structure, illustrations, captions, transfer format;
  • quality metrics: share of sentences within the specified length, dictionary coverage, time per document;
  • pilot boundaries: what volume we take first and by what criterion we consider the iteration successful.

We start the pilot with one thematic collection — on it we check the rules and agree on the level of editor intervention, after which we scale to the entire flow. Describe the task: what materials you have, who reads the result and in what form it should reach the recipient. We will come back with a volume estimate and implementation plan.

AI Development Areas

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1393
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1368
  • B2B Advance company logo design
    B2B Advance company logo design
    815
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1139
  • AIDER company logo development
    AIDER company logo development
    1057
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1152