TaggedWorks - Digital Accessibility Firm
قوائم تحقق[ مقال هندسي تخصصي ]

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
تاريخ النشر: 2024-03-05
8 دقائق قراءة

المعايير المرجعية ذات الصلة

WCAG 2.2 SC 1.3.1SC 3.3.1SC 3.3.2SC 3.3.3SC 3.3.7
[ تدقيق ومراجعة هندسية ]

هل تحتاج إلى تدقيق تجريبي لمنتجاتك الرقمية وفق هذه المعايير القياسية؟

طلب تدقيق هندسي

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:

مرجع الشيفرة :: التطبيق الهندسي
<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:

مرجع الشيفرة :: التطبيق الهندسي
<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

ممارسة أبحاث وهندسة إمكانية الوصول الرقمي

تُصاغ منشورات أبحاث TaggedWorks بواسطة مهندسين ممارسين ومتخصصين تقنيين في إمكانية الوصول. تعكس توصياتنا أحدث تفسيرات WCAG 2.2 وسلوك المتصفحات وجداول دعم التقنيات المساعدة.