Login Providers Account Block for React

Edit RUNGS for the ways to sign in, strongest first: an id, a name, a one-sentence line, a word for the strength and a number from 1 to 5 that draws the bars (a two-letter mark gives a service a neutral tile). Edit START for what the account has when the page opens (passkeys added, codes saved, the ISO day a passkey last signed in) and needsOf for the four conditions; each is a name, a state sentence and a met flag worked out from the setup, so the counts in both headings and the status line are always true. The dates are derived from a fixed AS_OF day, never the clock.

All of it. Add a passkey, Save the codes and Try a passkey change this page's state and say so in the status line ("Added a passkey in this demo."): no passkey is registered, no codes are generated and nothing is stored. Confirming the dialog only flips the password rung to Off. To wire it, call your WebAuthn endpoints from act, load the real counts and dates into START, and have confirm call the server that disables password sign-in, keeping the stored hash so Turn password back on can work.

Hiding the main action until it is allowed would make the page jump and leave people wondering where it went. Instead it is always in the same place, marked unavailable with aria-disabled, and pressing it explains: the status line says how many things are still to do and focus moves to the first button that does one. Once the last condition holds it becomes the trigger of the dialog, and a short line says so.

By what an attacker would need. A passkey is bound to the site and unlocked on your device, so it resists phishing and cannot be reused; a security key with a code is nearly as strong but a lost key needs a recovery code; a linked Google account is as strong as that account; an email link is as strong as the inbox; a password can be guessed, reused or phished. The words and bars are typed data you can change for your own ranking. The ladder shows what is on, so the count follows the Password rung when you turn it off.

Both cells are real lists with names, each method reads as its name, its strength word and its state (the bars are hidden and the word says the same), and each condition says "Ready" or "Still to do" for screen readers as well as showing a mark. The quiet button keeps its place in the focus order, and focus follows the work: to the next thing to do, or to the main button once everything holds. One polite status line reports each result.

The two cells stack, methods first. The one-line descriptions of each method are kept for screen readers but not drawn, so the ladder stays short, and the status line and the main button pin to the bottom of the screen while the conditions scroll under them.