shadcn.io is not affiliated with official shadcn/ui
Security Badges Login Block for Solid
A full-height sign-in page for a password manager with four hairline cells under the form, each a button whose hover card says what the safeguard is and where it stops.
Installation
Overview
Back a sign-in page with facts instead of badges, with this security badges login block for Solid with Ark UI. It's the sign-in of Lockmere, a password manager: the page's side rails run the full height of the screen and one band crosses it between two rules, holding a centred form: a Field with an Input for the email, another with a Password Input for the master password, and the Shine Button that signs in, the only colored control. Under it, a strip of four hairline cells, two across on a phone: Passwords (hashed with Argon2id), Sessions (end after 30 days idle), New-device alerts (an email each time) and Breach check (new passwords compared offline). Each cell is a button, and hovering it, focusing it or tapping it opens a Hover Card that says what the safeguard is and where it stops. It's built from Hover Card, Field, Input, Password Input, Button, Shine Button and Guides, with a CSS entrance only. For vaults, banks and any product whose visitors ask whether sign-in is safe.
FAQ
What stays in the page, and how do I make the claims mine?
Nothing leaves the page. The four safeguards are typed in SAFEGUARDS for a fictional product, and so are their cards. Sign-in waits under a spinner for less than a second, then shows "You're signed in" and a polite status message says nothing was sent. Replace each entry with a fact your product really keeps, and write where it stops as carefully as what it does; post the form to your auth endpoint where the code says so.
Why facts and not compliance badges?
A badge claims a certification you have to hold and keep, and a bare "256-bit" or "99.9% uptime" can't be checked from a sign-in page. A fact such as "sessions end after 30 days idle" is something your product either does or doesn't, and the card beside it says what it doesn't cover. If you do hold an audit, link its report from a card instead of drawing a seal.
How do the cards open on a keyboard, a phone and a screen reader?
Each cell is a real button. Hover opens its card; so does keyboard focus, and Escape closes it. The card's text is also tied to the button as its description, so a screen reader hears what it says without opening it.
How does the strip look on a phone?
The four cells go two across and two down, each keeping its icon, name and a line of words, and the strip sits below the Sign in button, so the button stays on the first screen. The cards are narrower than the screen and open above the cell when there is room, below it when there isn't.
Why does every card say where the safeguard stops?
It's what makes the claim credible: a password that is hashed doesn't protect one you reuse, an email alert doesn't block a sign-in, and a breach list is only as new as the last release. A visitor who reads the limits trusts the rest more, and your support team gets fewer surprises.
Why is the Sign in button never disabled?
A disabled button can't explain itself, and keyboard users can't reach it. Pressing Sign in with an empty or malformed email, or no master password, marks those fields invalid, writes one sentence under each and moves focus to the first. Typing clears that field's problem, and each field keeps a line for its problem even when there is none.