form-design — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited form-design (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Forms are where users give the product data. Every unnecessary obstacle between the user and a completed form is a failure. The design goal is to make correct input easy and incorrect input obvious — before the user submits.
Each layer serves a distinct purpose. Do not collapse them.
Explains what to enter. Appears below the input, always visible, in small secondary text.
Email address
[ ]
Use the email you signed up with.Shows the format or an example value. Appears inside the input, disappears on typing.
[[email protected] ]+358 40 123 4567 not Enter phone number--color-text-secondary) and lighter than actual input textConfirms whether the input is correct. The most important layer.
Email address
[jane@ ] ← invalid
✗ Enter a valid email address.Validation timing:
Real-time validation must be forgiving at the start — do not show an error the instant the user starts typing. Show it after a short debounce (300–500ms) or after the first character that makes the input definitively wrong.
The submit button enables when the form is valid. This is one of the clearest affordance signals in form design — the user sees the goal and knows when they have reached it.
[Submit] ← disabled, low contrast, cursor: not-allowed
(fields incomplete or invalid)
[Submit] ← enabled, full colour, cursor: pointer
(all required fields valid)Implementation:
<button type="submit" disabled={!isFormValid}>Submit</button>For long or complex forms where real-time validation is not practical, do not disable the submit — validate on submit and scroll to errors instead. Disabled submit on a long form frustrates users who cannot tell what is missing.
Loading state on submit: Replace label with spinner, disable the button. Prevent double-submission.
[Label] [Optional badge if optional]
[Input field ]
[Helper text — what to enter, format, constraints ]
[Error message — appears below helper text on validation fail ]<div class="field">
<label for="vat">VAT number <span class="optional">Optional</span></label>
<input
id="vat"
type="text"
placeholder="FI12345678"
aria-describedby="vat-helper vat-error"
aria-invalid="true"
>
<p id="vat-helper" class="helper-text">Finnish VAT numbers start with FI followed by 8 digits.</p>
<p id="vat-error" class="error-text" role="alert">Enter a valid Finnish VAT number (e.g. FI12345678).</p>
</div>Mark the minority. If most fields are required, mark the optional ones. If most are optional, mark the required ones.
<label>Email <abbr title="Required">*</abbr></label>
<!-- or -->
<label>Phone <span class="badge">Optional</span></label>Related fields belong in a <fieldset> with a <legend>. This is semantic HTML and helps screen readers announce the group context.
<fieldset>
<legend>Billing address</legend>
<label>Street</label><input type="text">
<label>City</label><input type="text">
<label>Postal code</label><input type="text">
</fieldset>Use fieldsets for:
Use the correct type — browsers provide free validation, appropriate keyboards, and autofill.
| Data | Input type |
|---|---|
type="email" | |
| Phone | type="tel" |
| URL | type="url" |
| Number | type="number" |
| Password | type="password" |
| Date | type="date" |
| Search | type="search" |
| Colour | type="color" |
On mobile, type="email" shows the email keyboard, type="tel" shows the numpad. These are free UX improvements.
Allow browsers to autofill. Do not disable it unless there is a security requirement.
<input type="text" autocomplete="name">
<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">
<input type="text" autocomplete="street-address">
<input type="text" autocomplete="postal-code">
<input type="text" autocomplete="cc-number"> <!-- credit card -->
<input type="password" autocomplete="new-password">Correct autocomplete values reduce friction dramatically for returning users and on mobile.
Any string whose wording depends on a number goes through the message catalogue, with the count as a named placeholder. Never branch on count === 1 in the view. That ternary hard-codes three English facts: two plural forms, the split at one, the number before the noun. Finnish inflects the noun, other languages have three or more forms or trail the count. The bug is invisible until translation, then spread across every view.
Translating UI copy makes every text-based test selector locale-dependent. Pin the locale in the test setup in the same change.
aria-describedby<fieldset> with <legend>type attribute on all inputsautocomplete attributes set on address, contact, and payment fields~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.