Plugin example

Registration form with accessible password feedback

A team signup form combines native HTML constraints, A11y Form Validator error handling, and this package's local password-strength meter without sending or storing password values.

Scenario

Create a workspace account draft

A developer wants validation errors, a focusable error summary, and password-strength guidance to work together on a semantic registration form. The example stops at local validation; no account is created.

Try it

Validation and strength checks

Submit the empty form and confirm focus moves to the summary.
Try demo user as the username, then fix it to aaa or demo_user.
Type password, then try a longer mixed password such as QuarterlyShip17!.
Leave the confirmation different from the password and review the inline error text.
Use only the keyboard to reach every field, summary link, and button.

Example

Register form

The form uses real labels, native constraints, A11y Form Validator for errors, and a data-root password meter beside the password input.

Username

Use 3 to 24 characters.

Password

Aim for at least 12 characters with mixed case, a number, and a symbol.

Password strength: Not rated

Confirm password

Re-enter the password so the validator can check both fields.

I understand this demo validates locally and does not create an account.

No registration has been submitted.

Accessibility notes

The form starts as semantic HTML with labels, helper text, native constraints, and a normal submit button.
A11y Form Validator renders inline errors, connects them to fields, and adds a focusable error summary after blocked submits.
The password meter keeps visible strength text, a native <progress>, requirement status text, and polite strength announcements.
Keyboard behavior remains native: Tab moves through fields and summary links, Space toggles the checkbox, and Enter submits.
The demo has no animations beyond browser focus behavior; both package styles include reduced-motion safeguards.
Screen reader behavior should be verified with the target browser and assistive technology before shipping a production form.

Developer notes

Copy path

Selectors and CSS

Password meter root: [data-a11y-password-strength-meter].
Observed input: data-input-id.
Feedback hook: data-feedback-id plus aria-describedby.
Validator root: [data-a11y-form-validator].
Import a11y-password-strength-meter/styles.css and a11y-form-validator/styles.css in app code.

Initialization

import { initPasswordStrengthMeters } from "a11y-password-strength-meter";
import {
  createDefaultPreset,
  createFormValidator
} from "a11y-form-validator";

initPasswordStrengthMeters();

createFormValidator(form, {
  ...createDefaultPreset(),
  validateOn: ["submit", "blur", "input", "change"]
});

Limitations

Local guidance only

This example demonstrates UI guidance and client-side validation. A real registration system still needs backend validation, rate limits, account creation, credential storage controls, and security review. The demo intentionally does not submit, store, log, or transmit password values.