Hardware Key Login Block for React

No. The page never calls navigator.credentials.get() and never asks the browser for a key; "Touch the key (demo)" stands in for the touch, and the result says no key was asked for anything. In a product, ask your server for a challenge where the code says so, call get() with it (listing the credential's transports, such as usb and nfc, helps the browser prompt for the right kind of key), send the signed answer back and let the browser draw its own prompt; this page shows what the states around that prompt could look like.

Ready, waiting, signed in and cancelled are one value. The first press moves from ready to waiting and keeps the same button, relabelled, so keyboard focus never leaves it; the second signs in and moves focus to the result's heading; Cancel returns to ready and puts focus back on the button. The rows, the drawing and the line under them all read that one value, and the page keeps its height through every state.

It marks the wait, and it is the only thing on the page that loops. It stops when you press Cancel or the key is accepted, and it doesn't pulse at all under reduced motion; the row also says "Waiting for your key" in words, so the pulse carries nothing by itself.

The instruction on the first two rows, the label of the touch button (touch or tap) and the drawing. It is locked while the page waits for a key, because changing how a key connects mid-wait would mean asking for another one. The switch is a Segment Group with the same API on every base.

It is hidden below the large breakpoint, as the drawn side of a split is on every login page. The rows, the switch and the button stay, so everything the drawing says is also written on the page.

The quiet "Use another method" link is the way out; point it at your own route. A security key should never be the only way in unless you also give people a recovery path they can reach.