Accessibility requirements

Component development plays a central role in modern front-end engineering, while accessibility (a11y) is key to ensuring equal product usability for all users. From keyboard navigation to screen reader compatibility, standards must be systematically implemented during the component design phase.

Foundational Accessibility Principles

Adhering to WCAG 2.1 AA standards is the industry benchmark, encompassing four core principles:

1. Perceivable: Information must be conveyed through multiple sensory channels
2. Operable: Interaction methods cannot rely on a single mode of operation
3. Understandable: Interface behavior and content must be clear and unambiguous
4. Robust: Compatibility with current and future assistive technologies

// Bad example: Icon-only button lacks text description
<button onClick={handleSearch}>
  <Icon name="search" />
</button>

// Correct implementation: Provide hidden text
<button onClick={handleSearch} aria-label="Search">
  <Icon name="search" />
  <span className="visually-hidden">Search</span>
</button>

Keyboard Navigation Standards

All interactive components must support complete keyboard operation chains:

• Tab key focus order should follow DOM flow sequence
• Custom components must implement tabindex="0" or -1 control
• Composite components (e.g., menus) must implement arrow key navigation

// Custom dropdown menu keyboard event handling
menu.addEventListener('keydown', (e) => {
  const items = Array.from(menu.querySelectorAll('[role="menuitem"]'));
  const currentIndex = items.indexOf(document.activeElement);
  
  switch(e.key) {
    case 'ArrowDown':
      e.preventDefault();
      items[(currentIndex + 1) % items.length].focus();
      break;
    case 'ArrowUp':
      e.preventDefault();
      items[(currentIndex - 1 + items.length) % items.length].focus();
      break;
  }
});

ARIA Attribute Application

WAI-ARIA specifications are vital tools for addressing HTML semantic deficiencies:

Role Definitions

• role="navigation": Primary navigation area
• role="alert": Urgent notification content
• role="dialog": Modal dialog container

State Management

• aria-expanded: Collapsed/expanded state
• aria-disabled: Disabled state
• aria-live: Dynamic content update regions

<!-- Tree control ARIA implementation example -->
<div role="tree">
  <div role="treeitem" aria-expanded="true" tabindex="0">
    Parent Node
    <div role="group">
      <div role="treeitem" tabindex="-1">Child Node 1</div>
      <div role="treeitem" tabindex="-1">Child Node 2</div>
    </div>
  </div>
</div>

Color Contrast Requirements

Text content must meet minimum contrast ratios:

• Normal text: 4.5:1 (AA level)
• Large text (18pt+/24px+): 3:1
• Non-text UI components (e.g., icons): 3:1

Validation tools:

/* Manage accessible colors via CSS variables */
:root {
  --text-primary: #333;
  --bg-primary: #fff;
  /* Contrast ratio 7.3:1 */
}

.error-text {
  color: #d32f2f;
  background-color: #ffebee; /* Contrast ratio 4.6:1 */
}

Focus Management Strategies

Visible focus styles are lifelines for keyboard users:

• Never use outline: none without providing alternatives
• Custom focus styles must meet 3:1 contrast ratio
• Modal dialogs must implement focus trapping

/* Custom focus styles */
button:focus {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  box-shadow: 0 0 0 4px rgba(0, 95, 204, 0.3);
}

/* High contrast mode adaptation */
@media (forced-colors: active) {
  button:focus {
    outline-color: Highlight;
  }
}

Form Component Standards

Forms are critical battlegrounds for web accessibility:

1. All form controls must have associated <label>
2. Error messages must include both text and ARIA notifications
3. Complex forms require grouping instructions

// React form error handling example
<>
  <label htmlFor="email">Email</label>
  <input
    id="email"
    type="email"
    aria-invalid={!!errors.email}
    aria-describedby="email-error"
  />
  {errors.email && (
    <div id="email-error" role="alert" className="error-message">
      {errors.email.message}
    </div>
  )}
</>

Dynamic Content Updates

Asynchronous content loading must consider assistive technology awareness:

• aria-live="polite": Non-urgent updates
• aria-live="assertive": Important immediate updates
• aria-busy: Loading state indication

// Live search results update
<div aria-live="polite">
  {searchResults.length > 0 && (
    <p>Found {searchResults.length} results</p>
  )}
</div>

Mobile-Specific Considerations

Touch devices require accommodating multiple interaction modes:

• Ensure touch targets are at least 48x48px
• Avoid relying solely on hover states for critical information
• Pinch-to-zoom must not be disabled

/* Touch-friendly buttons */
.touch-button {
  min-width: 48px;
  min-height: 48px;
  padding: 12px;
}

Testing and Validation Process

Accessibility must be integrated into development pipelines:

1. Automated scanning (axe-core, Lighthouse)
2. Manual keyboard navigation testing
3. Screen reader testing (NVDA+Firefox combination)
4. High contrast mode verification

// package.json test script configuration
{
  "scripts": {
    "test:a11y": "axe ./build && jest --config a11y-test.config.js"
  }
}

Documentation and Commenting Requirements

Component documentation must include an accessibility section:

### Accessibility Notes

- Keyboard operations:
  - Enter key: Activate button
  - Arrow keys: Toggle options
- ARIA attributes:
  - `role="combobox"`
  - `aria-haspopup="listbox"`
- Screen reader prompts:
  - Announces "Select city, dropdown" when focused

Balancing Performance and Accessibility

Complex interactions must consider low-end devices:

• Avoid excessive ARIA causing screen reader redundancy
• Animations must support prefers-reduced-motion
• Lazy-loaded content must maintain stable DOM order

/* Reduced motion option */
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}