Why this question matters in 2026
If your team lives in docs, chats, and tickets, dictation is no longer a novelty—it’s a daily input method. Hybrid work remains the dominant model for U.S. employees in remote‑capable roles (about 52% hybrid, 26% exclusively remote, 22% on‑site as of May 2026), which means audio gear, meeting mics, and voice tools are everywhere. Fairness in voice typing isn’t just a UX nicety; it’s an access and productivity issue. (gallup.com)
What the research says: ASR bias hasn’t vanished
The short version: even very modern ASR still makes more mistakes on some accents than others.
- A cross‑lingual study published in 2024 systematically quantified bias against non‑native speakers and regional accents, reporting absolute WER degradations (for example, around 24% higher WER for non‑native speakers in certain settings) and accent‑region disparities. (doi.org)
- An AAAI 2024 paper found accented English often incurred dramatically higher error rates (roughly 30–50% WER) compared with native speakers (about 2–8%) when using a state‑of‑the‑art transformer ASR model, highlighting persistent gaps. (ojs.aaai.org)
- Studies in 2025 continued to document disparities: audits spanning multiple ASR architectures and datasets found accent/dialect attributes significantly contribute to WER differences, and regional dialect studies (e.g., Newcastle English; Scottish dialects) observed higher WER unless models were adapted or fine‑tuned on those dialects. (experts.illinois.edu)
- Focused linguistic analyses in 2024 also showed how specific phonological and prosodic features in non‑native English (e.g., Arabic L1 speakers) can depress ASR accuracy—evidence that coverage gaps in training data still surface in real‑world usage. (sciencedirect.com)
In other words: even as engines get astonishingly good, accent‑aware accuracy remains uneven.
Meanwhile, keyboards are a reliable floor
Touch typing sets a steady baseline for many users. A large CHI study analyzing 136 million keystrokes from 168,000 typists found an average around 52 WPM (with wide variance). For professionals, 50–80 WPM is common, and elite typists go much higher—but the key point is that keyboard input’s error profile is relatively stable across accents. (userinterfaces.aalto.fi)
So…is voice typing “fair” today?
It depends on your accent and the engine. If your accent matches what the model has learned well, dictation can feel magical. If not, higher WER turns simple notes into repeated corrections, slowing you down and hurting confidence. That’s why we propose a public, opt‑in Accent Audit for 2026.
Announcing a public, opt‑in “Accent Stress Test”
We want to host an open evaluation that anyone can join. The idea:
- Participants read short, everyday passages and a domain‑neutral paragraph into their mic; each audio clip is transcribed by several leading ASR engines.
- The site computes WER per engine and per accent group, and—crucially—also records each participant’s keyboard WPM on a matched text snippet.
- Results are aggregated into an “accent parity” dashboard that anyone can browse.
Why measure WER and WPM together?
- WER tells us how often dictation gets the words wrong; WPM tells us how fast the same person can input via keyboard. The pair answers: is voice typing a productivity upgrade for this speaker, or is the keyboard still faster/cleaner? WER is the industry‑standard metric—computed from insertions, deletions, and substitutions against a human reference—and widely used in vendor docs and toolkits (e.g., NIST’s sclite). (docs.cloud.google.com)
What we’ll publish (transparently)
- Per‑accent WER by engine and overall averages
- A “parity gap” for each accent: absolute gap = WER_accent − WER_overall; ratio = WER_accent / WER_overall
- The share of participants for whom dictation beats their personal keyboard WPM (and by how much)
- Confidence intervals and sample sizes for every estimate
We’ll avoid league‑table “gotchas” and instead focus on practical guidance: when dictation is likely to help, when a keyboard is safer, and which mic/environments reduce errors the most.
How the Accent Stress Test will work (methodology you can reuse)
1) Representative prompts
- Use everyday, domain‑neutral text (emails, meeting notes, task updates) and a short numbers/addresses block. Keep each read passage 20–30 seconds; aim for 3–5 clips per participant to reach ≥2 minutes per accent sample.
2) Self‑identified accent metadata (opt‑in, privacy‑first)
- Let speakers choose one or more labels: regional variety (e.g., General American, Southern U.S., Scottish), and/or L1 for non‑native English. Offer a free‑text note for nuance. Store only what’s needed and keep it unlinkable to identity.
3) Clean audio capture
- Provide an in‑browser level meter and a quick calibration clip. Ask for a quiet room and consistent mic distance. Offer tips to avoid clipping and room echo.
4) Engines and scoring
- Run audio through multiple mainstream engines via API. Normalize text consistently across engines (case, punctuation, numerals) before scoring. Compute WER with a standard toolchain and publish the text‑normalization rules so results are comparable. (docs.cloud.google.com)
5) Reporting parity, not just averages
- Publish per‑accent WER with 95% CIs and sample counts. Flag parity gaps with simple traffic‑light cues: for example, absolute gap ≤2.5 points or ratio ≤1.1 = green; 2.6–5.0 or 1.11–1.25 = yellow; above that = red. These thresholds are policy choices, not standards; we’ll document and iterate them with community feedback.
6) Ethical guardrails
- Explicit consent, no sale of audio, and anonymization by default. Offer a delete‑my‑data button. If we ever expand beyond benchmarking (e.g., to release training subsets), we’ll request fresh consent.
Practical tips you can use today
Whether you’re an individual dictating notes or a team setting policy, these steps help reduce errors and inequities:
- Tune the environment first: a quiet room, a decent USB mic, and a pop filter can drop substitution/deletion errors dramatically. Vendor guidance ties certain error types (e.g., deletions) to weak signal or distance—fix those first. (learn.microsoft.com)
- Normalize expectations with WER: record 2–3 minutes of your own speech, transcribe with your engine, and compute WER once. If you’re consistently above ~15–20% on your everyday content, voice typing may not be a net win without adaptation. (docs.cloud.google.com)
- Try domain/adaptation features: many APIs support phrase hints or adaptation for names, jargon, and acronyms—small tweaks can shave off high‑impact substitutions. (docs.cloud.google.com)
- Mix modalities: for high‑stakes text, dictate a first draft, then switch to keyboard for corrections. Knowing your keyboard WPM gives you a realistic fallback.
- If you deploy ASR at work: sample real users across accents early; publish internal parity stats; and commit to remediation (model choice, fine‑tuning, or alternate channels) when gaps exceed your fairness threshold. Recent research shows dialect‑targeted fine‑tuning can reduce regional WER spikes—use that tool where appropriate. (aclanthology.org)
Touch typing vs voice typing: a fair comparison
- Keyboard input: often 40–60+ WPM for many adults, with predictable accuracy and no accent effects; large‑scale data puts the overall average near 52 WPM. (userinterfaces.aalto.fi)
- Voice input: can exceed practical typing speeds for some speakers and tasks, but WER parity varies by accent, audio, and domain. The fairest path is to measure both for each user and decide by scenario.
Our commitment
We’ll run the Accent Stress Test as an ongoing public benchmark, refresh it as engines evolve, and publish open methodology and aggregate results so the community can scrutinize—and improve—the standard. If your organization wants to contribute audio, review the methods, or help define better parity thresholds, we’d love to collaborate.
Bottom line: voice typing can be incredibly fast and accessible—but only if it works equitably. Measuring WER alongside keyboard WPM, per accent, turns fairness from a feeling into a number we can track and improve. (docs.cloud.google.com)
