Find and fix accessibility problems in HTML

The clearest blockers are the mouse-only Sign up control and the unnamed password visibility button. Other problems affect field identification, instructions, and placeholder contrast.

Problems, in priority order

1. Sign up is a clickable <div>

Element: <div class="btn" onclick="submitForm()">

A plain <div> is not keyboard focusable or keyboard activatable. Keyboard users cannot reach and activate this control. Screen readers do not identify it as a button, and voice control users cannot reliably target it as a button.

Fails:

• 2.1.1 Keyboard
• 4.1.2 Name, Role, Value — the button role is missing.

Correction:

<button type="submit" class="btn">Sign up</button>

Handle submission on the form’s submit event. This also supports native form submission from the keyboard. Whether another submission route already works depends on the omitted JavaScript; it does not repair this control.

2. The password visibility button has no accessible name

Element: <button class="show-pw"> containing only an SVG.

The SVG has no text alternative, so the button has no accessible name. Screen reader users cannot identify its purpose; voice control users have no meaningful name to target. This can prevent someone who needs to inspect their password from doing so confidently.

Fails: 4.1.2 Name, Role, Value.

Correction: Give the native button visible text that describes its current action, and update that text when the password visibility changes:

<button type="button" class="show-pw">Show password</button>

Change the text to Hide password when the password is visible. A changing action label does not also need aria-pressed. If you retain the decorative SVG alongside the text, give it aria-hidden="true".

The omitted toggle handler is needed to verify that it actually changes the input type and keeps the label accurate.

3. Email and password have only placeholders as labels

Elements: The text and password inputs.

Placeholders disappear when someone types. People with low vision or cognitive difficulties can lose track of a field’s purpose. Browsers may expose placeholders as fallback accessible names, but that does not provide persistent labels or a reliable visible target for voice control.

Fails: 3.3.2 Labels or Instructions.

Correction: Use explicitly associated, visible labels:

<label for="signup-email">Email</label>
<input id="signup-email" name="email" type="text"
       inputmode="email" autocomplete="email">

<label for="signup-password">Password</label>
<input id="signup-password" name="password" type="password"
       autocomplete="new-password">

These changes do not make either field required. The example retains type="text" for email to avoid introducing an additional format-validation constraint.

4. The password instruction and error are not associated with the input

Elements: .hint, .error, and the password input.

Their position communicates a relationship visually, but the input has no programmatic connection to either message. Screen reader users navigating directly between fields may miss the password rule or the explanation of the failed attempt.

Fails: 1.3.1 Info and Relationships.

Correction: Connect the instruction and, when present, the error using aria-describedby:

<label for="signup-password">Password</label>
<input id="signup-password" name="password" type="password"
       autocomplete="new-password"
       aria-describedby="password-hint password-error"
       aria-invalid="true">
<span id="password-hint">8+ characters</span>
<div id="password-error">Password too short</div>

This example represents the failed-validation state. Before an error exists, omit aria-invalid and reference only password-hint.

aria-invalid explicitly exposes the invalid state; its absence alone is not automatically a separate failure. The existing error text already names the password and describes the problem, so there is no demonstrated 3.3.1 Error Identification failure merely because the field does not change colour.

5. Placeholder text has insufficient contrast

Elements: The placeholders, #aaaaaa on white.

The contrast ratio is approximately 2.32:1. This fails both the 4.5:1 requirement for ordinary text and the 3:1 requirement for large text. People with low vision may struggle to read it.

Fails: 1.4.3 Contrast (Minimum).

Correction: Remove the redundant placeholders after adding visible labels. If placeholders are retained, a colour such as #767676 on white provides approximately 4.54:1:

.signup input::placeholder {
  color: #767676;
  opacity: 1;
}

The opacity matters because browser placeholder styling can otherwise change the rendered colour.

Observations that are not confirmed failures

• Error colour: #e00 (#ee0000) on white has approximately 4.53:1 contrast. It passes 1.4.3 Contrast (Minimum) for ordinary text, narrowly. This assumes the error’s actual background is white. The written error also means colour is not the only way the problem is communicated; no 1.4.1 Use of Color failure is demonstrated.
• Error announcement: Showing an error visually does not establish whether assistive technology announces it. If focus stays in place and the new error is not exposed as a status message, this can fail 4.1.3 Status Messages. Inspect the submit handler and test it. A pre-existing empty role="alert" container, populated when validation fails, is one suitable approach.
• Heading: An h3 immediately after an h1 skips a level. That alone is not an automatic WCAG failure. If this form is a direct subsection of the page, use h2; an actual mismatch between the conveyed structure and heading levels can fail 1.3.1 Info and Relationships.
• Checkbox: It already has a native, wrapping label. The link inside it is not, by itself, a demonstrated WCAG failure.
• Autocomplete: The corrected fields include autocomplete="email" and autocomplete="new-password". Whether their omission fails 1.3.5 Identify Input Purpose depends on that criterion’s applicability, including the purpose of the password field; creating a new password is not the same as entering a current password.

Checks requiring a browser or a person

1. Keyboard and page focus order: Use Tab and Shift+Tab through the entire landing page. Confirm the order preserves meaning and operation (2.4.3 Focus Order), every interactive control works without a mouse (2.1.1), and focus is visible and not entirely obscured (2.4.7 Focus Visible, 2.4.11 Focus Not Obscured (Minimum)). The snippet does not show the surrounding page or focus CSS.
2. Screen reader output: Test with a browser/screen reader combination such as Safari with VoiceOver or Firefox with NVDA. Navigate by form controls and headings. Confirm labels, password instructions, invalid state, checkbox label, button names, and heading structure. Trigger a failed submission and confirm the error is announced without having to search for it.
3. Password toggle: Activate it with Enter and Space. Confirm focus remains on the button, the password visibility changes, and the button’s accessible name changes to match its next action.
4. Rendered styling: Inspect computed colours and backgrounds, including placeholder opacity. Check focus indicators, target sizes, zoom, and surrounding layout in the actual page; the supplied code cannot establish their compliance.

Full corrected snippet

This shows the initial state. The existing submission handler should call setPasswordError('Password too short') when its validation rejects the password, and setPasswordError('') when that error clears. Its validation and submission logic were not supplied, so they are not invented here. No field is made required.

<form class="signup">
  <h2>Create your account</h2>

  <label for="signup-email">Email</label>
  <input
    id="signup-email"
    name="email"
    type="text"
    inputmode="email"
    autocomplete="email"
  >

  <label for="signup-password">Password</label>
  <input
    id="signup-password"
    name="password"
    type="password"
    autocomplete="new-password"
    aria-describedby="password-hint"
  >
  <span id="password-hint">8+ characters</span>

  <!-- Keep this empty container present before an error occurs. -->
  <div id="password-error" class="error" role="alert"></div>

  <button type="button" class="show-pw">Show password</button>

  <label>
    <input type="checkbox" name="terms">
    I agree to the <a href="/terms">terms</a>
  </label>

  <button type="submit" class="btn">Sign up</button>
</form>

<style>
  .signup {
    color: #222;
    background: #fff;
  }

  .signup .error {
    color: #e00;
  }
</style>

<script>
  const form = document.querySelector('.signup');
  const password = form.querySelector('#signup-password');
  const error = form.querySelector('#password-error');
  const toggle = form.querySelector('.show-pw');

  toggle.addEventListener('click', () => {
    const show = password.type === 'password';
    password.type = show ? 'text' : 'password';
    toggle.textContent = show ? 'Hide password' : 'Show password';
  });

  function setPasswordError(message) {
    if (message) {
      password.setAttribute('aria-invalid', 'true');
      password.setAttribute(
        'aria-describedby',
        'password-hint password-error'
      );
    } else {
      password.removeAttribute('aria-invalid');
      password.setAttribute('aria-describedby', 'password-hint');
    }

    error.textContent = message;
  }

  form.addEventListener('submit', (event) => {
    event.preventDefault();
    // Existing application function: keep validation and submission here.
    // On validation failure, it should call setPasswordError(message).
    submitForm();
  });
</script>