Form Validation & Accessibility — HTML & CSS Course

What you'll learn

A form that accepts anything — or excludes some users — is a broken form. HTML gives you built-in validation to catch bad input before it's submitted, and a set of practices that make forms usable by everyone, including keyboard and screen-reader users.

By the end you'll be able to:

Validate input with attributes like required and pattern
Guide users with sensible constraints (and know placeholders aren't labels)
Build forms that work with a keyboard and screen readers
Understand what ARIA is and when to reach for it

Built-in validation

The browser can validate common rules for you — no JavaScript needed. Add attributes to your inputs and the browser blocks submission and shows a message when they're not met:

validation.html

<form>
  <label for="user">Username</label>
  <input type="text" id="user" name="user"
         required minlength="3" maxlength="20" />

  <label for="age">Age</label>
  <input type="number" id="age" name="age" min="13" max="120" />

  <label for="pw">Password</label>
  <input type="password" id="pw" name="pw"
         required pattern=".{8,}" title="At least 8 characters" />

  <button type="submit">Create account</button>
</form>

Attribute	Enforces
`required`	The field must be filled in
`minlength / maxlength`	Text length limits
`min / max`	Numeric or date range
`pattern`	A regular-expression format (e.g. a postcode)
`type`	Format checks for email, url, number, etc.

Watch out

Client-side validation is for user experience, not security — it can be bypassed. Always validate again on the server. Think of HTML validation as a helpful first line of defence, never the only one.

Constraints & placeholders

Good constraints guide users toward success. Use min/max for ranges and title to explain a pattern. A placeholder shows example text inside an empty field — but it is not a label: it disappears as soon as the user types, and it's poor for accessibility.

Tip

Never replace a <label> with a placeholder. Keep the visible label and use the placeholder only for a supporting example (like name@example.com).

Accessible forms

Accessible forms come down to a few reliable habits:

Label every control (Module 8) — the single most important rule.
Keep a logical order so tabbing through fields follows the visual flow.
Don't rely on colour alone to show errors — add text and an icon too.
Write clear error messages that say how to fix the problem.
Make everything keyboard-operable — users must reach and submit without a mouse.

Intro to ARIA

ARIA (Accessible Rich Internet Applications) is a set of attributes — role, aria-label, aria-describedby, aria-invalid— that add accessibility information when native HTML can't express it. For example, aria-describedby can tie an error message to its input so a screen reader reads them together.

Key idea

The first rule of ARIA: don't use ARIA if a native element already does the job. A real <button> beats a <div role="button"> every time. As the saying goes, "no ARIA is better than bad ARIA." Reach for semantic HTML first, and add ARIA only to fill genuine gaps.

Recap & quick check

Key takeaways

Built-in validation (required, min/max, pattern, type) blocks bad input with no JavaScript.
Client-side validation is for UX only — always validate on the server too, for security.
A placeholder is not a label; keep visible labels and use placeholders only for examples.
Accessible forms: label everything, logical tab order, don't rely on colour, clear errors, keyboard-operable.
Use ARIA only to fill gaps native HTML can't — prefer real semantic elements first.

Quick check

1. Which attribute makes a field mandatory?

2. Is HTML validation enough to keep your app secure?

3. Can a placeholder replace a label?

4. What's the first rule of ARIA?

5. Which is an accessibility best practice for errors?

That completes Phase 2 — you can build complete, accessible HTML documents! Now the fun really begins: Phase 3 — CSS Fundamentals, where we make it all beautiful.