How to build an accessible login screen

An accessible login screen is a form with a visible label for every field, an error tied to the field that caused it and one submit button. Everything else is added later, without touching that base.

Almost every login that fails an accessibility test fails in the same place: the placeholder acts as the label, and the error message appears next to the field without being announced.

Four non-negotiable elements

• A visible label whose htmlFor matches the input id; the placeholder stays an example.
• An error with aria-describedby and aria-invalid, not just red text.
• One type=submit button; “forgot password” stays a link.
• A visible focus ring and natural tab order: no positive tabIndex.
• The error announced in a live region, because a screen reader user cannot see the red.

Password managers read autoComplete: email on one field and current-password on the other, never off. Without those attributes the user copies the password by hand, and on mobile that is where they close the page.

What is in the catalogue

The block login-01 covers email, password and links; login-04 adds a cover image. Browse the login category for variants. Source: github.com/shadcn-ui/ui, MIT licence.

The minimum form that passes

npx shadcn@latest add input label button

import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import { Label } from "@/components/ui/label";

export function LoginForm({ error }: { error?: string }) {
  return (
    
      
        Email
        
      
      Accedi
      {error ? (
        
          {error}
        
      ) : null}
    
  );
}

A concrete example: focus after the error

The form above covers the fields and links the message. What it misses is the step after the server replies: focus stays on the button and a keyboard user gets no signal that anything happened. A ref on the paragraph and a focus() call inside useEffect close the loop: the live region announces, the focus moves.

import { useEffect, useRef } from "react";

export function LoginError({ message }: { message: string }) {
  const ref = useRef(null);

  useEffect(() => {
    ref.current?.focus();
  }, [message]);

  return (
    
      {message}
    
  );
}

The tabIndex={-1} makes the paragraph reachable from code without adding it to the tab order. Without that attribute focus() does nothing on an element that is not interactive: the message stays silent.

The limitation to know

Limitation: login-01 has no live region and does not link the error to the input with aria-describedby. The block covers the look and the structure; you add the error announcement, as in the snippet above. If the server returns the error after submit, move focus to the message or the form instead of leaving it on the button.

How many blocks really exist

Five of the fifteen blocks come from shadcn/ui, and login-01 declares five registryDependencies and two files: add login-01 also writes card, field, input, label and button. Counting the dependencies before the command saves you from finding an extra component in the diff.

The decision rule

Rule: if the error comes from validation before submit, aria-describedby and aria-invalid are enough. If it comes from the server after submit, the focus also has to move to the message. When both apply, one node with role="alert" does the job: two regions on the same text announce it twice.

The mistake to avoid

Disabling the button while the request is in flight looks careful and breaks the flow: focus drops to the body, the page appears frozen, and a screen reader user loses their place. Leave the button enabled, show “sending”, and ignore a second submit with a flag.

To compare the variants, read Best login blocks 2026 and the 12-point checklist for accessible React components. If you are choosing between a ready block and a headless primitive, start from Copy-paste or headless.