Skip to content
loam

Help centre The sealed editor

Accessibility and accommodations

Where the editor's integrity guards can collide with assistive technology, how to accommodate individual students, and what we haven't audited yet.

The sealed editor works by constraining how text enters a document. Constraints that stop paste can also collide with legitimate assistive workflows, and pretending otherwise would help nobody. Here’s where the edges are, what to do for individual students, and what we haven’t verified yet.

Where the guards can bite

  • Dictation software. Speech-to-text tools often insert recognised phrases as single large blocks of text, which is exactly the shape of input the editor refuses (large machine-sized insertions are indistinguishable, to the guard, from paste). Short phrase-by-phrase dictation may pass; long fluent dictation will hit the limit. If a student writes by voice, arrange an accommodation rather than fighting the editor.
  • IME input. Composition input for Chinese, Japanese, Korean and other languages is supported. Compositions commit at up to 140 characters, which comfortably covers normal use. Very long single compositions can still be refused.
  • Screen readers. We build with semantic HTML and test with keyboard-only navigation, and the editor doesn’t block screen-reader output. But a contenteditable writing surface with input guards is a hard case for assistive tech, and we have not yet completed the independent WCAG 2.2 AA audit that would let us claim it works for every screen reader and braille display. Until that audit is done, treat screen-reader use in the sealed editor as something to trial with the student before an assessment, not during one.

What works without qualification

  • Full keyboard operability: toolbar, dialogs and replay controls all work without a mouse.
  • Reduced-motion alternatives for animations, including the recording indicator.
  • No time pressure from Loam itself: any deadline is the teacher’s, not the software’s.
  • Ordinary typing aids: autocorrect and undo/redo behave normally.

Accommodating a student

Accommodations are the school’s call, and we support them rather than second-guess them. The practical options, roughly in order of preference:

  • Trial before assessment. Have the student write something low-stakes in the editor with their usual setup. Ten minutes tells you whether their tools and the guards coexist.
  • Adjust the task, keep the evidence. More time, shorter phrase-by-phrase dictation, or a scribe typing in the editor at the student’s direction all preserve a genuine record.
  • Take the assessment outside Loam. Sometimes the right answer. A witnessed assignment is one form of evidence, not the only legitimate way to assess. A student’s access needs outrank our evidence chain, every time.

Tell us what broke

If a student’s assistive setup hits a guard, email hello@loam.inkwith “Accessibility” in the subject: what tool, what happened, what you expected. We respond within 5 business days and treat accessibility gaps as defects, not feature requests. Our full accessibility statement lists known limitations and their status.

The honest summary: the integrity guards and assistive technology both manipulate text input, so they will sometimes collide. A full WCAG 2.2 AA audit of the sealed editor is planned and hasn’t happened yet; until it has, we’d rather you plan accommodations with eyes open than discover a limit mid-assessment.

Still stuck? Email hello@loam.ink. On the Free plan we reply within 2–3 business days, Australian hours. School plans get faster. What to expect from support.

Optional website analytics

With your permission, Loam uses PostHog EU to understand which public pages help visitors and where they leave. Session replay masks every input and is disabled entirely on the document-verifier page. We do not run PostHog analytics inside the signed-in app.

Read the cookie and analytics notice