---
title: Accessibility
description: Inclusive design for screen readers, keyboard nav, color contrast, and ARIA
tags: [a11y, inclusive-design, wcag]
dependencies: [identity, safety]
---

# Accessibility

Accessibility is not a feature to add later. It is a design constraint that produces better interfaces for everyone.

## Principles

- **Perceivable**: Text alternatives for images. Captions for audio. Sufficient contrast.
- **Operable**: Full keyboard navigation. No time limits. No flashing.
- **Understandable**: Consistent navigation. Clear labels. Error suggestions.
- **Robust**: Semantic HTML. ARIA where needed. Tested with real screen readers.

## Implementation

Use the right element. A `<button>` is a button. A `<nav>` is navigation. Semantic HTML gives you accessibility for free.

```html
<!-- Good -->
<button onclick="submit()">Submit</button>

<!-- Bad — requires extra ARIA, keyboard handling -->
<div class="btn" onclick="submit()">Submit</div>
```

Visible focus indicators:

```css
:focus-visible {
  outline: 2px solid var(--accent);
  outline-offset: 2px;
}
```

Contrast: 4.5:1 minimum for normal text (WCAG AA). Never use color alone to convey meaning.

ARIA supplements semantic HTML, never replaces it:

```html
<nav aria-label="Main navigation">
<button aria-label="Close dialog">×</button>
<div aria-live="polite">Status: loaded</div>
```

## Testing

Automated tools catch ~30% of issues. Also:

1. Navigate with keyboard only
2. Test with a screen reader (VoiceOver, NVDA)
3. Zoom to 200%
4. Disable CSS — content order should still make sense
5. Verify data disclosures and privacy controls are perceivable — inaccessible privacy UI defeats informed data governance