Typing for Schools: classroom typing practice without accounts

How a lesson typically runs

1. Baseline. Each student takes the 60-second placement so the curriculum opens at their real level rather than at lesson one for everybody.
2. Assign. Point the class at a region (home row, top row, capitals) and let the adaptive engine vary the practice text per student from there.
3. Race. Finish with a private race room; the join code keeps it to your class, and the ghost-run option lets slower typists compete against themselves.
4. Review. The progress view shows per-key mastery and accuracy trends, which is far more useful for intervention than a WPM league table.

Accessibility in the classroom

Accommodations are per-profile, so they travel with the student across shared devices: full keyboard navigation, four text sizes, atkinson hyperlegible font option, high-contrast theme, reduced-motion mode, untimed learning, never colour-only feedback, hideable leaderboards. Nothing is behind a paid tier.

Running it in a lesson

Pupils do not need accounts. A class can be opened with a join code, which is the whole of the setup for a lesson: no email addresses collected, no password resets, and no time lost at the start of a period to sign-in problems. Where a school does want progress to follow a pupil between devices, accounts exist, but the lesson works without them.

A typical period runs as a short assigned lesson, then a private race room for the last few minutes. Race rooms are code-joined and closed: there is no public matchmaking, no chat, and no way for anyone outside the room to appear in it. A teacher can also assign a specific region rather than letting each pupil choose, which keeps a mixed class on the same material even when they are at different speeds within it.

What the dashboard shows, and what it deliberately does not

The teacher view reports per-pupil accuracy, the keys and transitions each pupil is losing time on, and whether they cleared the region gate. It does not report minutes logged, because a pupil sitting in front of an open app is not evidence of anything and reporting it invites exactly the wrong behaviour from a class being measured on it.

The two things software genuinely cannot see are the two things worth a teacher walking the room: whether hands are covered, and which fingers are actually moving. A pupil can reach a respectable speed with two or three improvised finger assignments and the software will not flag it, because from the outside the keystrokes look correct. That is the part of the lesson that stays human.

Accessibility in a mixed class

Accessibility settings are per profile rather than per device, so a shared classroom machine presents each pupil their own configuration. That covers the things that decide whether a pupil can use the software at all: text size, contrast, reduced motion for pupils who find animation uncomfortable, and turning off sound entirely.

Practice material stays age-appropriate as well as level-appropriate. Adaptive sets are generated from the weak transitions of one pupil, and a set optimised purely for weak transitions can drift into strings that are dense and discouraging, so the generator is constrained to real words at the reading level of the region.

Data, and what leaves the school

The text a pupil types is not transmitted. Typing is processed in the browser and only the result of an exercise is stored, so the words themselves stay on the machine. There is no advertising in the product, nothing about a pupil is sold, and there is no third-party analytics built on what a class practises.

The privacy policy sets out exactly what is held and who ever touches it, and a real person answers questions about it. Schools that need to review the data model before deploying anything are the reason that page is written to be read rather than survived.