Challenge 3: Wire Up an Accessible Error — Possible Solution
====================================================================

<label for="password">Password</label>
<input id="password" type="password"
       aria-invalid="true" aria-describedby="password-error">
<span id="password-error">Password must be at least 8 characters</span>

WHY THIS WORKS
--------------
- The <label for="password"> / id="password" pair is kept intact from
  Chapter 5's basic labeling requirement — the error-handling additions
  here layer ON TOP of correct labeling, they don't replace it. A field
  still needs a working accessible name even while it's showing an
  error.
- aria-invalid="true" is added directly on the <input> — this
  announces the field's CURRENT STATE (invalid) to a screen reader,
  exactly as the chapter describes: a sighted user notices a red
  border or similar visual cue, and aria-invalid gives a screen reader
  user the equivalent non-visual signal that something is wrong with
  THIS specific field.
- aria-describedby="password-error" points to the id of the <span>
  containing the actual error text. This is what PROGRAMMATICALLY
  CONNECTS the error message to the field — without it, "Password must
  be at least 8 characters" would just be text sitting somewhere near
  the input with no structural relationship to it, and a screen reader
  user navigating to the password field wouldn't necessarily have any
  way to discover that message exists at all, let alone that it applies
  specifically to this field.
- The error message itself — "Password must be at least 8 characters"
  — is specific and actionable rather than a generic "invalid input," a
  direct application of Chapter 1's Understandable principle:
  the user is told EXACTLY what's wrong and, implicitly, what to do
  about it (add more characters), not left to guess.
- In a real implementation, aria-invalid would typically be toggled to
  "false" (or removed) once the user corrects the password to meet the
  8-character requirement, and the error span's content would update or
  be removed accordingly — this example shows the STATE at the moment
  of a failed validation, which is what the challenge specifically
  asked for.