Disclosure: This article was generated with AI and was not reviewed by Martin Yovchevski before publication. Martin is a co-founder of Unplag.bg.

A teacher reviewing a text match needs more than a coloured highlight. They need to know what is being compared, where the passages came from, and what the signal does—and does not—mean. The interface also needs to be understandable without relying on colour alone.

Here is a small, fictional HTML example for teams designing educational review tools. It is an illustration, not a claim about Unplag’s interface or a ready-to-deploy component.

Start with visible labels

<article aria-labelledby="example-title">
  <h2 id="example-title">Example passage for review</h2>
  <p><strong>Status:</strong> Needs human review</p>
  <p><strong>Source:</strong> Fictional sample for demonstration</p>

  <section aria-labelledby="student-excerpt">
    <h3 id="student-excerpt">Student text — fictional</h3>
    <blockquote>Rainwater can be collected for a school garden.</blockquote>
  </section>

  <section aria-labelledby="source-excerpt">
    <h3 id="source-excerpt">Source text — fictional</h3>
    <blockquote>Rainwater can be collected for a school garden.</blockquote>
  </section>

  <details>
    <summary>What does this example show?</summary>
    <p>The passages match. A match alone does not establish
       authorship, intent, or a breach of a rule.</p>
  </details>
</article>

The sample uses a visible status label, headings and a native disclosure control. A real product would need actual source information where available, enough surrounding context for a fair comparison, and a way for authorised reviewers to inspect citations. These snippets are invented and are not evidence about a real student.

Colour can help, but should not carry the message alone

A red border might attract attention, but it should not be the only indication of status. W3C’s explanation of WCAG 2.2 criterion 1.4.1 recommends providing another visible cue, such as text or shape. This criterion is only one part of accessibility; it does not certify a complete interface.

Before using any component, test it with a keyboard, screen readers and the browsers used by your teachers. Check contrast, reading order and the clarity of its labels. Protect student data and show excerpts only to people authorised to see them.

Keep the decision human

A matching passage may be a quotation, common wording or something that needs closer attention. An AI-writing indicator can be wrong and does not establish authorship. Unplag’s FAQ describes its AI indicator as a prompt for further review, with the final decision left to an educator.

Teachers, lecturers and education developers who want to discuss practical workflows can reach the Unplag.bg team at office@unplag.info.

Disclosure: This article was generated with AI and was not reviewed by Martin Yovchevski before publication. Martin is a co-founder of Unplag.bg.

A teacher wants to ask students whether they used an AI tool and, if so, what kind of help they sought. A developer building that form faces a small but important question: how can we ask for useful information without turning a missing answer into an accusation?

The following example checks only whether a declaration is complete. It does not detect AI writing, verify a student’s answer, or decide whether a student broke a rule. Teachers and schools should decide the wording and permitted uses before building a form.

A minimal example

This JavaScript function accepts a yes/no answer, a fixed list of purposes, and a yes/no answer about whether the student reviewed the output. It does not require a name, a prompt, or the student's essay.

const allowedPurposes = new Set([
  'brainstorming',
  'feedback',
  'proofreading',
  'other',
]);

function validateDisclosure(input) {
  const errors = [];

  if (input.usedAi !== true && input.usedAi !== false) {
    errors.push('Choose whether AI was used.');
  }

  if (input.usedAi === true) {
    if (!Array.isArray(input.purposes) || input.purposes.length === 0) {
      errors.push('Choose at least one purpose.');
    } else if (!input.purposes.every(purpose => allowedPurposes.has(purpose))) {
      errors.push('Choose only the available purposes.');
    }

    if (typeof input.reviewed !== 'boolean') {
      errors.push('Choose whether you reviewed the output.');
    }
  }

  return errors;
}

For example, { usedAi: true, purposes: ['feedback'], reviewed: false } is a complete declaration: the form accepts “no” as a complete answer, even though the output was not reviewed. The form can prompt a conversation rather than silently treating “false” as misconduct.

A declaration with usedAi: true and no purpose returns an error. A declaration with usedAi: false does not need AI-use details. These cases, the unanswered case, an unknown purpose, and a missing review answer were checked locally using six small examples.

What the code does not do

This is a standalone validation example, not a finished form or a production system. It has no storage, submission endpoint, authentication or accessibility interface. Before real use, the institution must decide how answers are collected, protected, retained and accessed, and offer an accessible alternative when needed. Avoid collecting prompts, personal information or student work unless there is a clear and authorised reason.

A complete declaration is not proof of independent work, and an incomplete declaration is not proof of cheating. Similarly, AI-writing indicators can be wrong. Unplag.bg describes its indicator as a prompt for further review, with the final judgment left to the educator: https://www.unplag.bg/en/faq

UNESCO’s guidance describes a human-centred and age-appropriate approach to generative AI in education: https://www.unesco.org/en/articles/guidance-generative-ai-education-and-research

Teachers, education developers and lecturers who would like to discuss practical workflows can reach the Unplag.bg team at office@unplag.info.

At Unplag.bg, where I work as co-founder and technical lead, this question matters because educational institutions need more than a single number. Here are practical design questions I consider useful when building systems for reviewing documents.

Keep the source close to the match

A highlighted passage should make it clear what was compared and where the corresponding source can be found. The reviewer needs enough surrounding text to understand a quotation, a reference, or a common phrase. A link to the source is a starting point for inspection, not proof that the passage is inappropriate.

Preserve the original and expose extraction problems

Document processing starts before comparison. PDF extraction, formatting, and character encodings can change what a system reads. For Bulgarian, Cyrillic text, mixed scripts, and word forms add practical cases to test. A reviewer should be able to return to the original document when extracted text looks wrong.

Separate different kinds of evidence

Text overlap and a signal about possible AI-generated writing answer different questions. Neither should be presented as a definitive conclusion about intent or authorship. Label what each signal measures, explain its limitations, and keep decisions with the people responsible for review.

Make the review understandable later

A useful workflow lets an authorised reviewer trace the relevant passages, sources and decisions. This supports consistency without pretending that every case has the same rules. Institutions can then apply their own policies and give students a fair opportunity to respond.

Designing for context is a product choice: it makes the limits of automation visible and gives educators a better basis for judgment. I would be interested in hearing which parts of a document-review workflow are hardest to understand or audit.

Unplag.bg · About the author