Accessibility

Web Accessibility

Accessibility is not a feature you bolt on at the end - it is a quality attribute that must be considered from the first line of markup. Building accessible interfaces means that people with visual, motor, auditory, or cognitive disabilities can perceive, navigate, and interact with your application. It also means better usability for everyone: keyboard power users, people on slow connections, users with temporary injuries, and those in constrained environments.

Why Accessibility Matters

WCAG Principles: POUR

The Web Content Accessibility Guidelines organize all success criteria under four principles. Every accessibility requirement maps to at least one.

Conformance Levels

WCAG defines three levels. Each higher level includes all criteria from the levels below it.

For most projects, target Level AA. It covers the vast majority of real-world accessibility needs without imposing requirements that conflict with certain content types.

Semantic HTML Fundamentals

Native HTML elements carry built-in semantics, keyboard behavior, and screen reader announcements. Using the right element is the single most effective accessibility technique.

Heading Hierarchy

Headings create an outline that screen reader users navigate like a table of contents. Follow these rules:

• One <h1> per page that describes the page purpose
• Never skip levels (do not jump from <h2> to <h4>)
• Use headings for structure, not for visual styling - CSS handles appearance

Common Accessibility Issues

Accessible Forms

Forms are where accessibility failures cause the most real-world harm - users cannot complete purchases, registrations, or critical workflows.

Label Association

Every form control needs a programmatically associated label:

<!-- Explicit association -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" required>

<!-- Implicit association (wrapping) -->
<label>
  Email address
  <input type="email" name="email" required>
</label>

Error Handling

• Display errors inline next to the relevant field, not only at the top of the form
• Use aria-describedby to associate error messages with their input
• Use aria-invalid="true" on fields that fail validation
• Provide clear, specific error text ("Enter an email in the format name@example.com" not "Invalid input")

Required Fields

• Mark required fields with required attribute (for native validation) or aria-required="true" (for custom validation)
• Do not rely solely on color or an asterisk to indicate required status - add text like "(required)"

Color and Contrast

Color must never be the only means of conveying information. Pair it with text, icons, patterns, or other visual cues.

Contrast ratios (WCAG AA):

Quick wins:

• Test with browser developer tools (Chrome DevTools shows contrast ratios on hover)
• Respect prefers-color-scheme for dark mode support
• Test designs with simulated color blindness (protanopia, deuteranopia, tritanopia)

Reference Files

Integration with Other Skills