TaggedWorks - Digital Accessibility Firm
Kontrol Listeleri[ MÜHENDİSLİK MAKALESİ ]

The Comprehensive Accessible Forms Checklist

A production-grade checklist for designing and developing accessible web forms with labels, instructions, error summaries, and autocomplete support.

TaggedWorks Design & Engineering
Yayınlanma: 2024-03-05
8 dk okuma

Referans Verilen Standartlar

WCAG 2.2 SC 1.3.1SC 3.3.1SC 3.3.2SC 3.3.3SC 3.3.7
[ MÜHENDİSLİK DENETİMİ ]

Dijital ürünlerinizin bu standartlara göre ampirik bir denetimine mi ihtiyacınız var?

Denetim Talep Edin

1. Structure & Visible Labels

Every interactive form input must have a programmatically associated, visible label. Placeholder text is never an acceptable substitute for a label because it disappears upon typing and typically lacks sufficient contrast.

  • Explicitly associate labels using label htmlFor matching the input id.
  • Never hide visible labels unless the visual context is unmistakable (and even then, provide sr-only text).
  • Clearly indicate required fields in text (e.g., '(required)'), not solely via a red asterisk or color alone.

2. Logical Grouping & Fieldsets

When multiple checkboxes or radio buttons represent a single concept, wrap them in a fieldset element with a clear legend:

KOD_REFERANSI :: UYGULAMA
<fieldset>
  <legend className="font-semibold">Select your notification preferences</legend>
  <label><input type="checkbox" name="pref" value="email" /> Email notifications</label>
  <label><input type="checkbox" name="pref" value="sms" /> SMS alerts</label>
</fieldset>

3. Error Summaries & Inline Errors

When validation errors occur upon form submission, follow this two-tiered pattern:

  • Display a top-level Error Summary box at the top of the form, move keyboard focus to it, and list links to each failing field.
  • Display an inline error message next to the field, and link it via aria-describedby on the input.
  • Mark invalid inputs with aria-invalid='true'.

4. Autocomplete & Input Purpose

Comply with WCAG 2.1 SC 1.3.5 (Identify Input Purpose) by providing standard HTML autocomplete attributes (e.g., name, email, street-address, postal-code, tel). This enables assistive browser technologies to auto-populate fields and display recognizable icons.

5. Production-Ready Form Pattern

Here is a complete accessible input field pattern:

KOD_REFERANSI :: UYGULAMA
<div>
  <label htmlFor="user-email" className="block font-medium">
    Work Email <span aria-hidden="true">*</span>
    <span className="sr-only">(required)</span>
  </label>
  <input
    id="user-email"
    name="email"
    type="email"
    autoComplete="email"
    required
    aria-invalid={hasError ? "true" : "false"}
    aria-describedby={hasError ? "user-email-error user-email-hint" : "user-email-hint"}
    className="border rounded p-2"
  />
  <p id="user-email-hint" className="text-sm text-slate-500">We will never share your email.</p>
  {hasError && (
    <p id="user-email-error" className="text-sm text-red-600 font-medium" role="alert">
      Please enter a valid work email address (e.g. name@company.com).
    </p>
  )}
</div>
TW

TaggedWorks Design & Engineering

Dijital Erişilebilirlik Mühendisliği ve Araştırma Grubu

TaggedWorks araştırma yayınları, sahada çalışan erişilebilirlik mühendisleri ve teknik uzmanlar tarafından hazırlanır. Önerilerimiz güncel WCAG 2.2 yorumlarını, tarayıcı davranışlarını ve yardımcı teknoloji destek tablolarını yansıtır.