GratisAIaccessibility · field guide · local-first · no account
keystroke counterfoil

Measure Repeated Keyboard Navigation Burden — Free

A short keyboard detour becomes substantial when repeated. Quantify a measured tab route without pretending a stopwatch can determine whether a site meets an accessibility standard.

The proof surface

Heading audits inspect document structure. This records repeated keyboard traversal effort during specific tasks and supports a concrete before-and-after remediation discussion.

Inputtask | tab presses per visit | visits per session; measured seconds per key press
Rare deviceHeading audits inspect document structure. This records repeated keyboard traversal effort during specific tasks and supports a concrete before-and-after remediation discussion.
Output artifactnavigation seconds per row with transparent workings
Cost$0 · local-first · one free run · samples labelled
Sample, not your facts: Illustrative sample: Open search | 17 | 8; Reach account menu | 12 | 3. With measured seconds per key press set to 0.6, total is 103.20 navigation seconds.

Why the flat version breaks

Counting only one visit

Repeated routes are the source of the cumulative burden.

Using speed as a user ranking

Timing describes one walkthrough, not a person’s ability.

Ignoring focus traps

A low total cannot excuse an unreachable control.

How to work the keystroke counterfoil

Follow the actual focus path

Start from the same focus location each time and count presses to the named control. Record reverse-tab routes separately if they are part of the real workflow.

Count repetitions in a session

Use a representative task walkthrough rather than guessed daily traffic. The sample search route repeats eight times, so seventeen presses become 136 actions.

Use a measured press interval

Multiply presses by visits and the observed seconds per press. The default 0.6 seconds is illustrative, not a claim about a disabled person’s speed.

Retest after changing navigation

Compare the same tasks after adding a sensible skip route or focus strategy. Keep errors, trapped focus and confusing announcements in separate qualitative notes.

What the keystroke counterfoil replaces

QuestionBeforeVisible working
Counting only one visitRepeated routes are the source of the cumulative burden.Count repetitions in a session
Using speed as a user rankingTiming describes one walkthrough, not a person’s ability.Use a measured press interval
Ignoring focus trapsA low total cannot excuse an unreachable control.Retest after changing navigation

A local arithmetic aid replaces hand calculation, not expert review. No paid AI service is needed.

Run it on the samples, right here

FIRST-LOAD

Input is processed locally and a draft is saved automatically in this browser profile when storage is available. Reset to sample clears that draft; Pro history has its own clear button. A state link encodes your inputs in its URL: share only non-sensitive rows. Browser history, clipboard and anyone receiving the link may retain it. Optional AI use below leaves this device; it is not required.

This is a task-effort estimate, not a WCAG pass/fail test. Include keyboard and assistive-technology users in evaluation.

Data note: Everything runs in this browser tab on the keystroke counterfoil: your task | tab presses per visit | visits per session stays on this device, nothing is uploaded, and the reading is rebuilt only when you press run.

Go deeper: the companion app files the same reading as a till receipt with a tear-off foot

The article demo above runs without limits. The companion app keeps a local history, exports the rows as CSV, prints the keystroke counterfoil reading, and holds your drafts on this device — one free run, then $ 4 one-time for the layer that keeps filing.

The keystroke counterfoil reading is complete for free. The optional $4 layer adds print, row CSV and the last five local reading summaries; it does not add hidden answers. Checkout is not configured yet; the article demo remains unlimited.

Open the measure repeated keyboard navigation burden companion

Boundary

This is a task-effort estimate, not a WCAG pass/fail test. Include keyboard and assistive-technology users in evaluation.

What this is built on

Before: Repeated routes are the source of the cumulative burden. After: the keystroke counterfoil shows the working beside each named row so the reader can change the assumption and inspect the consequence.

Optional AI formatting, not calculation

For this keystroke counterfoil, use the free AI Studio interface only if available to you, with no paid API key. Manual entry completes the same workflow for free. Supply only fictional or non-sensitive notes. Review its output against the source; never paste unresolved questions into the numeric rows.

Format my non-sensitive notes for a keystroke counterfoil. Return plain rows only: task | tab presses per visit | visits per session. Preserve supplied quantities exactly. Do not guess missing values; list questions separately. Do not calculate or add advice. I will check every row before pasting into the local tool.

Accepted schema: task | tab presses per visit | visits per session. No AI response is executed as code.