home / skills / eyadsibai / ltk / accessibility

This skill helps you implement accessible design following WCAG guidelines across components and interactions, improving usability for all users.

npx playbooks add skill eyadsibai/ltk --skill accessibility

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.4 KB
---
name: Accessibility
description: This skill should be used when the user asks about "accessibility", "a11y", "WCAG", "screen readers", "keyboard navigation", "ARIA", "accessible design", "inclusive design", or mentions making apps accessible.
version: 1.0.0
---

# Accessibility (a11y)

Guidance for creating accessible web applications following WCAG guidelines.

## Core Principles (POUR)

1. **Perceivable**: Content can be perceived by all senses
2. **Operable**: Interface can be operated by everyone
3. **Understandable**: Content and UI are understandable
4. **Robust**: Works with assistive technologies

## Quick Wins

### Images

```html
<!-- Informative image -->
<img src="chart.png" alt="Sales grew 25% in Q4 2024">

<!-- Decorative image -->
<img src="decoration.png" alt="" role="presentation">
```

### Buttons & Links

```html
<!-- Good: Descriptive -->
<button>Add to cart</button>
<a href="/docs">View documentation</a>

<!-- Bad: Vague -->
<button>Click here</button>
<a href="/docs">Read more</a>
```

### Forms

```html
<label for="email">Email address</label>
<input type="email" id="email" aria-describedby="email-hint">
<span id="email-hint">We'll never share your email</span>
```

### Headings

```html
<!-- Proper hierarchy -->
<h1>Page Title</h1>
  <h2>Section</h2>
    <h3>Subsection</h3>
  <h2>Another Section</h2>
```

## Color & Contrast

### Minimum Contrast Ratios

| Element | WCAG AA | WCAG AAA |
|---------|---------|----------|
| Normal text | 4.5:1 | 7:1 |
| Large text (18px+) | 3:1 | 4.5:1 |
| UI components | 3:1 | 3:1 |

### Don't Rely on Color Alone

```html
<!-- Bad: Color only -->
<span style="color: red">Error</span>

<!-- Good: Color + icon + text -->
<span style="color: red">
  <svg aria-hidden="true">...</svg>
  Error: Email is required
</span>
```

## Keyboard Navigation

### Focus Management

```css
/* Visible focus indicator */
:focus {
  outline: 2px solid #2563EB;
  outline-offset: 2px;
}

/* Don't remove focus styles! */
:focus { outline: none; } /* BAD */
```

### Tab Order

```html
<!-- Natural order follows DOM -->
<nav>
  <a href="/">Home</a>      <!-- Tab 1 -->
  <a href="/about">About</a> <!-- Tab 2 -->
</nav>

<!-- Skip link for keyboard users -->
<a href="#main" class="skip-link">Skip to content</a>
```

### Keyboard Shortcuts

- `Tab`: Move forward
- `Shift+Tab`: Move backward
- `Enter/Space`: Activate
- `Escape`: Close/cancel
- `Arrow keys`: Navigate within components

## ARIA Basics

### When to Use ARIA

1. **First**: Use semantic HTML
2. **Then**: Add ARIA only if needed

```html
<!-- Semantic HTML (preferred) -->
<button>Submit</button>
<nav>...</nav>

<!-- ARIA when needed -->
<div role="button" tabindex="0">Submit</div>
<div role="navigation">...</div>
```

### Common ARIA Attributes

```html
<!-- Labeling -->
<button aria-label="Close dialog">×</button>
<div aria-labelledby="section-title">...</div>

<!-- State -->
<button aria-expanded="false">Menu</button>
<div aria-hidden="true">Decorative content</div>

<!-- Live regions -->
<div aria-live="polite">Status updates here</div>
<div role="alert">Error message</div>
```

## Component Patterns

### Modal Dialog

```html
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Confirm Action</h2>
  <p>Are you sure?</p>
  <button>Cancel</button>
  <button>Confirm</button>
</div>
```

### Tabs

```html
<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel1">Tab 1</button>
  <button role="tab" aria-selected="false" aria-controls="panel2">Tab 2</button>
</div>
<div role="tabpanel" id="panel1">Content 1</div>
<div role="tabpanel" id="panel2" hidden>Content 2</div>
```

## Testing Checklist

### Automated Testing

- [ ] Run axe or Lighthouse accessibility audit
- [ ] Check color contrast with WebAIM checker
- [ ] Validate HTML

### Manual Testing

- [ ] Navigate with keyboard only (no mouse)
- [ ] Test with screen reader (VoiceOver, NVDA)
- [ ] Zoom to 200% - is content usable?
- [ ] Disable CSS - is content logical?

### Screen Reader Testing

```
macOS: VoiceOver (Cmd + F5)
Windows: NVDA (free) or JAWS
Mobile: TalkBack (Android), VoiceOver (iOS)
```

## Quick Reference

| Issue | Solution |
|-------|----------|
| Image without alt | Add descriptive alt text |
| Low contrast | Increase to 4.5:1 minimum |
| Missing labels | Add `<label>` or aria-label |
| No focus visible | Add visible focus styles |
| Mouse-only | Add keyboard support |
| Auto-playing media | Add pause controls |

Overview

This skill provides practical guidance to design and audit accessible web applications following WCAG principles. It focuses on concrete, high-impact patterns for perceivable, operable, understandable, and robust interfaces. Use it to improve keyboard support, ARIA usage, contrast, forms, and component patterns like dialogs and tabs.

How this skill works

The skill inspects UI patterns and recommends fixes: semantic HTML first, ARIA only when necessary, and concrete code examples for images, buttons, forms, headings, focus, and live regions. It includes quick checks (contrast ratios, labels, focus styles) and a testing checklist covering automated tools and manual screen-reader and keyboard testing. It highlights common accessibility problems and prescribes specific, testable remedies.

When to use it

  • During design reviews to catch accessibility issues before implementation.
  • While writing or refactoring UI components (buttons, forms, modals, tabs).
  • Before release to validate WCAG conformance and keyboard/screen-reader support.
  • When fixing user-reported problems about screen readers or keyboard navigation.
  • When building inclusive design as part of product requirements.

Best practices

  • Prefer semantic HTML over ARIA; add ARIA only to fill gaps.
  • Ensure visible focus indicators and a logical DOM/tab order.
  • Provide meaningful alt text for images; use empty alt for decorative images.
  • Maintain minimum contrast ratios: 4.5:1 for normal text, 3:1 for large text/UI.
  • Label all form controls with <label> or aria-label and surface helpful hints.
  • Test with automated tools (axe, Lighthouse) and manual checks (keyboard, VoiceOver/NVDA).

Example use cases

  • Convert a custom clickable div into a semantic button with keyboard and ARIA support.
  • Audit a checkout form to add labels, hints, and error announcements via aria-live.
  • Implement a modal dialog that traps focus, uses role="dialog", and sets aria-modal.
  • Improve site navigation with skip links and correct heading hierarchy for screen readers.
  • Fix color contrast issues across a theme to meet WCAG AA for normal text.

FAQ

When should I use ARIA?

Use ARIA only after using semantic HTML; ARIA supplements behavior or states that native elements cannot express.

How do I test keyboard accessibility?

Navigate the interface using Tab/Shift+Tab, Enter/Space, Escape, and arrow keys; ensure focus is visible and all interactive controls are reachable and operable.