Canadian EdTech company: consistent performance in live, high-stakes assessments

A leading Canadian educational technology company builds digital assessments and learning tools for numeracy and literacy. Its customers are organizations that test people at scale: education ministries, academic institutions and certification bodies.

In Canada, education is run at the provincial level rather than federally, so each province has its own ministry, and those ministries are the company’s partners. Their students do assessments on the company’s platform.

Part of that platform is the student experience. A candidate logs in, works through the assessment, and writes their response. WProofreader is embedded in the text input component they write in, so spelling and grammar issues are flagged as they go.

What the company needed

Everything on this platform happens under exam conditions, and that shapes what a spell checker has to do.

So the company needed something that could:

• sit inside the editor students have already written in, rather than being a separate tool
• stay up, because an outage in the middle of a live assessment is not acceptable
• be configured differently for different jurisdictions, since some partners allow grammar checking and others allow spelling only

It also had to work inside the lockdown tooling the platform uses. Depending on the device, assessments run in locked-down browsers or kiosk software that blocks external resources, partly to stop students getting AI assistance during a test.

Challenge

The company already had an approach that worked, up to a point. It used the browser’s own built-in spell checking API, and that implementation is still in use in one context today.

The question was whether a dedicated service was worth the change. The team ran an evaluation and documented the pros and cons of both approaches, and their clients evaluated them too, comparing how each one performed in practice.

"If we were to build this ourselves, it would take so much that it’s not worth it. It’s reasonably priced, it’s very good quality, so we adopt it."

The constraint that shaped the whole decision was data residency. Some partners have a hard requirement that student data cannot be sent outside the country, and for those contexts, using any external API for spell checking is not just undesirable, it is a legal problem. In those deployments, the browser-based approach stays.

For partners without that restriction, the decision came down to what the two approaches actually delivered. WProofreader was more responsive and the quality of its suggestions was better, and the company could give clients the assurance they needed: student writing is processed, and nothing is stored.

That is where they switched.

Solution

WProofreader is embedded in the text input component students write in, which is CKEditor.

During the writing assessments, students read the source material on one side of the screen and write their answer on the other, with a planning space in between for rough notes.

The checker is deliberately not active in the planning space. That part is meant to be messy, and nobody wants a student distracted by corrections while they are getting their thoughts down. It switches on in the response itself, where the writing actually counts.

Grammar checking is turned on or off depending on the jurisdiction, so the same platform can serve a partner that allows both and a partner that allows spelling only.

The team also simplified the configuration. WProofreader has a settings panel with a range of options, and setting those repeatedly for every item was not something anyone wanted to do. They customized it so the configuration lives in one place and is inherited across the board. Students no longer see a settings panel at all in this context, and the checker cannot be switched off, because for these assessments it is always meant to be on.

On the authoring side, where teachers build the assessment content, there is no spell checker in the editor.

Benefits

Better suggestions than the browser default

Responsiveness and the quality of recommendations were the two things that made the case for switching, and they are what the company still gets.

It works inside a locked-down exam

Lockdown browsers and kiosk software block external resources by design. Because WProofreader is built into the platform rather than reached from outside it, students get the tool and the lockdown still does its job.

Configured once, inherited everywhere

One central setting instead of the same options set over and over per item.

Flexible enough for different jurisdictions

Grammar checking can be switched off where a partner does not permit it, without a separate build.

Conclusion

WProofreader now runs inside the student writing experience on the company’s assessment platform, embedded in the editor, active where the response is written and quiet where students are still planning, configured once centrally and switched to suit each jurisdiction.

"Our clients really value stability. These are large scale assessments, and the ministries’ reputations depend on performance in the field. If things don’t work, parents complain, schools complain, teachers complain, and their credibility goes down. So if something is working, they prefer not to stir it up. That’s a big part of our continued use of WProofreader."

What the teams are working on next

There are two places this partnership still has room to go, and they are the two the teams are working on together.

The first is reliability. This is software used during live, high-stakes assessments, where a period of downtime is not an inconvenience, it is a serious problem.

"Our concerns have always been about consistent performance, not quality. We’ve never heard that the spelling or grammar recommendations are bad. It’s always been pretty good."

That is the thing the company watches, and it is the thing that matters most to them.

The second is data residency. For partners who cannot allow student writing to leave the country, WProofreader is currently not an option, and those deployments run on the browser’s built-in checking instead. Solving that properly would let the company offer the same experience to every partner it works with, and it is the piece we are taking up next.