Common Accessibility

The form has three accessibility problems, but each has a direct fix:

1. Replace interactive `div` elements with native controls. Put them inside a real `<form>`, use `<input>` elements, and provide explicit programmatic labels:

```html
<form aria-labelledby="login-heading">
  <h1 id="login-heading">Sign in</h1>

  <label for="email">Email address</label>
  <input id="email" name="email" type="email"
         autocomplete="email" required
         aria-describedby="email-error">
  <p id="email-error" role="alert" hidden>Please enter a valid email address.</p>

  <label for="password">Password</label>
  <input id="password" name="password" type="password"
         autocomplete="current-password" required
         aria-describedby="password-error">
  <p id="password-error" role="alert" hidden>Enter your password.</p>

  <button type="submit">Sign in</button>
</form>
```

The actual error elements should be shown only when relevant; when shown, set the corresponding input’s `aria-invalid="true"`. Placeholder text can be an optional example or hint, but it is not a replacement for a persistent `<label>` because it disappears and has poor contrast.

2. Verify the blue submit button’s color combination rather than assuming blue is accessible. Normal button text needs at least a 4.5:1 contrast ratio against its background; the button’s boundary and other state indicators need sufficient non-text contrast. Do not use color alone to convey success or failure—include visible text or an icon with an accessible name.

3. Add a clearly visible keyboard focus style, preferably with `:focus-visible`, and do not remove the browser outline unless a replacement is provided:

```css
button:focus-visible,
input:focus-visible {
  outline: 2px solid #123a70;
  outline-offset: 2px;
}
```

The outline must have at least 3:1 contrast against adjacent colors and remain visible in every state. Keep the natural DOM/tab order, avoid positive `tabindex` values, and ensure all fields and the submit action work without a pointer.

Also check that the page has a logical heading structure and one main landmark, that validation changes are announced without excessive interruption, and that server-side errors are associated with the relevant control. Run axe-core with zero critical violations, then test the complete login flow by keyboard, with NVDA or VoiceOver, and at 200% zoom.