Scan feedback

Try it — capture flashes ok, your validation flashes error

<!-- Type a code and press Enter (a hardware scanner does exactly
     this, faster). data-scan-flash paints the viewport ok-wash on capture;
     REJECT* codes demo YOUR validation calling flashScanResult('error'). -->
<div class="bo-form-field">
  <label class="bo-form-field__label" for="scan-demo">Scan barcode</label>
  <input class="bo-input bo-input--code" id="scan-demo" data-scan-input data-scan-flash
      placeholder="Try 4006381333931, then REJECT-1" aria-describedby="scan-demo-status" />
  <p id="scan-demo-status" data-scan-status aria-live="polite" class="bo-visually-hidden"></p>
</div>

Capture ≠ validity: data-scan-flash makes the behavior paint ok the moment the terminator arrives (the scanner said "I read it"), and flashScanResult('error', reason) is your validation's verdict — the framework cannot know whether a perfectly-scanned code belongs on this PO. Under reduced motion the wash is static for the stamp's lifetime; under forced colors it becomes a Highlight frame, since a repainted background would vanish exactly when contrast matters most.

Markup

<input class="bo-input bo-input--code" data-scan-input data-scan-flash
    autofocus aria-describedby="scan-status" />
<p id="scan-status" data-scan-status aria-live="polite" class="bo-visually-hidden"></p>
<script type="module">
  import { initScanInput, flashScanResult } from "@busy-office/ui/js";
  initScanInput(); // capture -> ok flash (data-scan-flash) + live-region announce
  document.addEventListener("bo:scan", (e) => {
    // Capture is not validity. YOUR check decides, then paints the verdict:
    if (!isOnThisPo(e.detail.value)) flashScanResult("error", "Not on this PO");
  });
</script>

What the platform gives you, and what the behavior adds

Unlike dialog or combobox, there is no native element underneath this one — a scanner is a keyboard, and the platform has no idea a scan happened. That makes the boundary more important here, not less: the no-JS path is a real form post and a server re-render, which every RF pattern page documents as its No-JS row. Build that path first and treat the flash as the enhancement it is.

Quick reference generated

State attributes: data-scan-flashdata-scan-inputdata-scan-resultdata-scan-statusdata-scan-terminator

API generated from CSS

• Two-channel by contract: the wash is never the only signal — every capture and rejection also reaches the data-scan-status live region. That is the deliberate improvement over device-SDK overlays, which are colour-only.
• The overlay is pointer-inert and sits below toasts: a flash must never eat a tap or cover an error a consumer just raised.
• RF-profile member (its whole audience): counted inside rf-essentials' 41 kB budget gate (40 until roadmap 388.1).
• No audio, ever — beeps and LEDs belong to the device service; pairing with them is configuration, not CSS.

Maturity generated

Introduced

v0.5.0

CSS floor

Chrome/Edge 99 · Firefox 97 · Safari 15.4

Alignment scored

2026-08-28

Assistive-tech evidence

None recorded

Pin this component's first release with npm i @busy-office/ui@0.5.0. The floor is derived from this component's stylesheet alone — set by @layer — so it sits at or below the whole framework's Chrome/Edge 119 · Firefox 129 · Safari 17.5. No assistive-technology runtime result is recorded for any component: it needs a human listening to VoiceOver and NVDA on owner hardware; no gate in this repo can simulate announcement behaviour. What automation covers instead is test:axe across every page at 1440 and 390, and check:forced-colors — see accessibility.

Design-system alignment generated

100% (18/18) — how closely this component follows the design language. Each rule is scored 0-3 against a checkable citation; rules that don't apply leave the denominator. Scored 2026-08-28.