ScrKeyboard

An on-screen keyboard for the touch-screen terminals that business software actually runs on: it appears when an operator taps into a field on an approved site, carries every character a goods-received note needs, and stores nothing that is typed.

The panel docks to the bottom on focus and hides on Enter — the operator never leaves the form. Screenshots are rendered by the extension’s own keyboard code over a sample warehouse form, not captured from a live customer system.

The Problem It Solves

Warehouse terminals, production floors, reception desks, order entry: plenty of business software is used all day on a touch screen with no physical keyboard within reach. The operating system will happily supply a general-purpose on-screen keyboard, but it knows nothing about the form underneath it — it takes whatever space it likes, has no idea which field is next, and certainly has no button that types Awaiting stock.

ScrKeyboard is deliberately not a general-purpose accessibility keyboard. It is built for one job: getting an operator through a business form on a screen they tap. It stays completely inert until someone approves a site, docks to the bottom of that page when an editable field takes focus, scrolls the field clear of itself, and gets out of the way on Enter.

What It Does

• Three modes on one panel: QWERTY letters with Shift and CapsLock, a symbols mode behind the ?# key, and a one-shot Polish diacritics mode behind ĄĘ that composes with Shift
• A numeric keypad whose punctuation column — full stop, comma, hyphen, at sign — is present in every mode, so an e-mail address or a slashed date needs no mode switching
• A ⇥ key that moves focus to the next editable field without closing the panel, skipping disabled, read-only, hidden and password fields
• One-tap quick phrases, global or per site, in operator-chosen colours with black or white label text picked automatically for contrast
• Approved and blocked site rules with * wildcards, an English and Polish interface, Enter or Ctrl+Enter confirmation, and CSV export of the whole configuration

Symbols mode greys out CapsLock and Shift rather than leaving two dead keys that look live.

Diacritics are one-shot: type the letter and the keyboard is back to plain letters. ź sits on the x key, because Polish has no x.

The Finding That Reordered the Roadmap

Planning the route to a store listing started with reading the layout file against the project’s own test form. The keyboard had no punctuation at all. keyboardLayout.ts defined a–z and a 0–9 keypad, and nothing else: no full stop, no comma, no hyphen, no slash, no at sign, no underscore.

The fixture form that shipped with the repository asks for a customer reference. Which means the product could not type ORD-2024/15. Nor 12/03. Nor a.smith@example.com — on a keyboard whose entire purpose is filling in business forms.

That moved three things to the front of the queue and pushed the store work to last:

• A symbols mode, because punctuation had to live somewhere without turning the letters into a thicket of tiny keys
• The punctuation column on the keypad, because the four marks that appear in almost every field should never cost a mode switch
• Tab navigation, because a keyboard that can finally type every field should be able to reach every field too

The store assets came after all of it. Listing copy is mechanical and can be written any evening; the product decisions it describes cannot.

Inert Until You Say Otherwise

An extension that types into fields on business systems is exactly the kind of thing that should not hold standing access to the whole web. ScrKeyboard installs with no host access at all: http://*/* and https://*/* are declared as optional host permissions, the whitelist is empty by default, and nothing is injected anywhere.

Access is requested one origin at a time, on a click, when the operator approves the site they are looking at — and it can be reviewed or revoked from Chrome’s own settings. Blocked rules always beat approved ones. Password fields are ignored unless a site’s rule says otherwise in so many words.

The broad optional patterns exist because the target is whatever internal system a customer already runs, on a domain nobody can name in advance. That is also the single thing in the manifest most likely to earn a reviewer’s question, which is why the justification was written before the submission rather than in reply to one.

There is no backend and no analytics. Keystrokes are relayed to the focused field and not read, logged or transmitted; the only things stored are the operator’s own rules, phrases, colours, language and last CapsLock state.

Set Up by the Person Who Runs the Terminals

The setup page is aimed at a supervisor, not a developer: approved sites, blocked sites, global and per-site phrases with a small colour palette, language, confirmation key, and a CSV export of the lot. Colour presets are a click rather than a hex field, and the label flips between black and white on its own so a dark preset never leaves unreadable text on a button.

Colours are picked from swatches, never typed. Export CSV hands a configured set of rules and phrases to whoever sets up the next terminal.

Three Defects a Whole-Branch Review Caught

v0.9.0 passed its tests and its acceptance criteria. Re-reading the finished branch as one piece, before tagging, turned up three things the tests were never going to ask about:

• Between roughly 861 and 963 pixels of window width, the keypad still sat beside the main keyboard while there was no longer room for both — the punctuation column and the outermost letter keys were pushed off the screen entirely. The stacking breakpoint was in the wrong place, and re-checking meant rendering the panel headlessly at 900 and 1024 pixels to see every key back on screen.
• Tab could land on a password field on a site whose rule forbids password fields, if that field also carried contenteditable="true" — the navigation check and the typing check disagreed about what counts as a password field.
• Polish diacritics mode stayed armed after the panel was closed, so the next letter typed in an unrelated field could quietly come out as ą.

All three shipped as v0.9.1 the same day. None of them is exotic; all three are the kind of thing that only shows up when the branch is read as a whole rather than commit by commit.

Built With

• Chrome extension, Manifest V3, minimum Chrome 116 — Chromium browsers only
• TypeScript under strict, built with Vite; no runtime framework and no third-party code in the shipped extension
• The keyboard panel renders into a Shadow DOM, so a host page’s CSS cannot reach in and the extension’s CSS cannot leak out
• 79 unit tests under Vitest, covering URL-pattern matching, settings migration, colour contrast, diacritics, field navigation and viewport maths — the logic is deliberately kept out of the DOM layer so it can be tested in Node
• Content scripts are registered, not blanket-injected: the service worker keeps the registration in step with the operator’s rules, so an unapproved page never sees any of it
• Settings live in chrome.storage.sync under a versioned key with a migration path; runtime state such as CapsLock sits in chrome.storage.local
• English and Polish through Chrome’s own _locales, English as the default
• npm run check gates a release: typecheck, unit tests, production build, then a validation step that confirms the packaged extension really contains its icons, locales and entry points