Choosing a pronunciation scoring API for children's speech

Most pronunciation scoring APIs were built for adults learning a second language. If you are building for children — a speech therapy product, a phonics or early-reading app, a school platform — the questions that separate one option from another are not the ones on the pricing page. This guide sets out what to check, how to read a vendor's published accuracy figures, what recording a child obliges you to nail down contractually, and how to run the comparison on your own audio in an afternoon. We build one of these, so read the last section knowing that; the rest is what we would tell a friend evaluating the category.

First, work out which problem you have

Two different technologies get shopped for interchangeably and they are not substitutes. Speech recognitionanswers “what did this person say?” — open-ended, no target supplied. Pronunciation scoringanswers “how well did this person produce the thing we asked them to say?” — the target text goes in with the audio, and the engine aligns and scores against it.

Teams building practice products almost always want the second, even when they start out searching for the first. If the child is being asked to say a specific word, and you need to know which sound went wrong, you want scoring. You only need recognition if the child could say anything and you have to find out what.

The capability checklist

These are the response-format and model questions that decide whether an engine can carry the product you have in mind. Every row is answerable from documentation or a single support email, and the answers vary far more between vendors than the accuracy claims do.

One pattern is worth pointing out because it catches people late. An engine can tell you a sound was wrong without being able to tell you what was produced instead, and a great many of them do exactly that. For a language course that is fine — the learner tries again. For a therapy or phonics product it is a real limitation, because the cue a child needs and the note a clinician writes both depend on knowing which sound came out. Ask for that field explicitly, and ask how often it is populated rather than whether it exists.

How to read a vendor's accuracy figures

Published accuracy in this field is easy to misread, and the misreadings all run in the vendor's favour. Six questions turn a headline number back into information.

• chevron_rightAsk for the error base rate. In most real corpora only a small percentage of sounds are actually wrong. At a 2% base rate a system that flags nothing is 98% “accurate”. Accuracy is close to meaningless on this task; precision, recall, F1 and ROC-AUC on the error class are the metrics that carry information.
• chevron_rightAsk how many labelled errors the figure rests on. Not how many recordings, or how many phones — how many productions a human actually marked wrong. That number is the denominator of every error-detection statistic, and it is usually one or two orders of magnitude smaller than the headline sample size.
• chevron_rightAsk whether the threshold was chosen on the same data. A best-F1 threshold swept on the test set inflates precision and F1 relative to unseen audio. Threshold-free metrics — ROC-AUC, average precision — are not affected and are the fairer comparison.
• chevron_rightAsk who the speakers were. “Children” covers a five-year-old with a lateral lisp and a fourteen-year-old learning English as a second language. Error patterns, and therefore results, differ completely. A benchmark on young language learners validates scoring on child voices; it does not validate disorder detection.
• chevron_rightAsk for the false-flag rate specifically. It is the number a child feels — they said it right and the app said otherwise — and it is the one most often missing from vendor materials.
• chevron_rightTreat cross-vendor numbers with suspicion, including ours. Two accuracy figures computed on different corpora, with different labellers and different base rates, are not a comparison. A vendor publishing its own measurement of a competitor's product has every incentive and no obligation to be fair. Compare products on audio you control.

The landscape, in categories

Vendor names change; the categories are stable, and knowing which one you are shopping in saves more time than a feature grid.

• chevron_rightLanguage-learning and test-prep APIs. The largest and most mature group. They score pronunciation, fluency and often proficiency against frameworks like IELTS or CEFR, usually across several languages and dialects, and they typically publish pricing. They are built around an adult or teenage learner reading a passage, and the output is shaped for a language course rather than a therapy goal. If you need multiple languages, fluency metrics or proficiency scoring, this is the category to shop in.
• chevron_rightGeneral-purpose speech recognition. Excellent at transcribing what was said; not built to score how well a specific sound was produced against a known target. If you reach for one of these to solve a scoring problem, you end up comparing transcripts to target words and inferring errors, which loses the sub-word detail that makes the feedback useful. Ask any ASR vendor for word-error rates measured on child speakers specifically — headline figures in that industry are almost always adult numbers.
• chevron_rightChild-voice specialists. A thin category, and it got thinner: the best-known independent child-speech vendor was acquired in 2023 and its technology folded into the acquirer's own products, with no public self-service route to the API remaining. That acquisition is the reason a lot of product teams are searching for options at all.
• chevron_rightClinical and assessment software. Standardised assessments and therapy platforms used inside clinical practice. These are products rather than APIs, they are generally not something you integrate, and the regulated ones exist under obligations a scoring API does not carry. Worth knowing the boundary: an API that scores pronunciation is not an assessment instrument, and building one into a screening flow does not make it one.

The practical consequence for a paediatric team is that most of the mature options in this market were designed around a different speaker. That does not make them bad — they are frequently excellent at what they were built for — but it does mean the fit questions matter more than the accuracy questions, and that testing on your own users is not optional.

What children's audio obliges you to pin down

This is the section teams skip and then rewrite under time pressure during a school procurement. Recording a child changes your obligations, and your scoring vendor sits inside them.

• chevron_rightA child's voice recording is personal information under COPPA when your service is directed to children under 13, and your vendor becomes part of your compliance story the moment you send audio to them.
• chevron_rightGet retention in writing. How long is audio held, where, and how is deletion actually effected — including from backups and from any subprocessor.
• chevron_rightGet a straight answer on training use. Whether the vendor may train models on your users' recordings is a yes or no question and it should be answered in the contract, not in a blog post.
• chevron_rightAsk for the subprocessor list and check it against your own disclosures. An API that quietly fans out to a third-party ASR provider has extended your data map without telling you.
• chevron_rightDecide who obtains consent. Usually you do, not the vendor — but the mechanism you use has to match what you told parents or the school, and school deployments bring FERPA and district agreements into scope alongside COPPA.

Our longer treatment of this, written for developers rather than lawyers, is on the children's privacy and COPPA page. It is general information rather than legal advice — get your own counsel before you ship to children.

How to run the evaluation yourself

The whole comparison fits in an afternoon and it will outrank every published benchmark you have read, including ours. Fifty recordings is enough to eliminate a bad fit; it is not enough to separate two good ones, and you should not pretend otherwise.

• chevron_rightCollect fifty recordings from your actual users, on the devices and in the rooms they really use. Not studio audio, not adult staff reading word lists. Recording conditions move these numbers more than model choice does.
• chevron_rightHave a qualified person label them — for a paediatric product, a speech-language pathologist. Mark each target sound correct or incorrect, and where it is incorrect, write what was produced instead. That labelled set is worth more than every vendor benchmark combined, including ours.
• chevron_rightSend the same audio through every candidate and store the raw responses. Score them yourself against your labels rather than against each vendor's own scoring.
• chevron_rightMeasure two things separately. How well each engine ranks — if you sorted every recording worst-first, how much of your labeller's error list is in the top quarter? And how well each engine decides — at the threshold you would actually ship, what fraction of its flags are wrong?
• chevron_rightListen to the disagreements. Where two engines disagree, or where an engine disagrees with your labeller, is where you learn what each one is actually doing. Thirty minutes of listening will tell you more than any table.
• chevron_rightCheck the failure modes, not just the averages. How does it behave on a very quiet child, a noisy room, a two-word answer, a child who trails off? Those cases are a large share of production traffic and almost none of any benchmark.

Where ArticScore fits

We built ArticScore because the checklist above kept coming out badly for the products we wanted to build. It is a pronunciation scoring API for children's speech: per-phoneme scores, a named candidate for what was produced instead on every flagged sound, a clinical error type, timing spans, and an acoustic model fine-tuned on children's voices rather than adapted from adult speech.

It is also narrow, and the narrowness is the point. One dialect — American English. No fluency scoring, no proficiency frameworks, no transcription. It cannot detect distortions, because nothing that scores against a closed phoneme set can. And it should not run unsupervised: at every operating point we have measured, most individual flags are false positives, which is why we describe it as a ranking and practice-feedback layer rather than an assessment.

Our own measurements against five human phoneticians on child speech, with the method, the sample sizes, the confidence intervals and the results that went against us, are on the benchmark page. We do not publish measurements of other companies' products, so there is no comparison table to point you at — which is precisely why the fifty-recording protocol above is the section of this guide we most want you to use.