Accessibility

Accessible design reaches everyone. This guide covers how to prompt Claude for accessibility and implement inclusive features across platforms.

Why Accessibility Matters

Beyond compliance

• ~15% of the world has some form of disability
• Accessibility benefits everyone (curb cuts, captions)
• Good accessibility often means better UX overall
• Legal requirements in many jurisdictions

Types of accessibility needs

• Visual (blindness, low vision, color blindness)
• Motor (difficulty with mouse, touch, or keyboard)
• Auditory (deafness, hearing impairment)
• Cognitive (attention, memory, learning differences)

Screen Reader Support

Semantic structure

• Use proper heading hierarchy (H1 → H2 → H3)
• Meaningful link text ("View report" not "Click here")
• Labeled form inputs
• Logical reading order

Prompting for VoiceOver/TalkBack

Make sure this component is accessible with VoiceOver.
Add appropriate labels and hints.

ARIA labels

• Labels for icons without visible text
• Descriptions for complex interactions
• Live regions for dynamic content
• "Add an aria-label to the close button"

SwiftUI accessibility

• .accessibilityLabel() for custom labels
• .accessibilityHint() for instructions
• .accessibilityValue() for current state
• .accessibilityElement(children:) for grouping

Color & Contrast

WCAG contrast requirements

• Normal text: 4.5:1 minimum
• Large text (18px+ bold or 24px+): 3:1 minimum
• UI components and graphics: 3:1 minimum

Prompting for contrast

Check the color contrast on this design.
Make sure all text meets WCAG AA standards.

Beyond contrast

• Don't rely on color alone to convey information
• Add icons or patterns to charts/status indicators
• Provide text alternatives for color-coded elements

Color blindness

• Test with color blindness simulators
• "Make sure this works for someone with red-green color blindness"
• Avoid red/green as the only differentiator

Keyboard Navigation

Focus management

• All interactive elements should be focusable
• Visible focus indicators
• Logical tab order
• Skip links for repetitive navigation

Prompting for keyboard access

Make sure this interface is fully keyboard accessible.
Add visible focus states and logical tab order.

Common patterns

• Tab to move between elements
• Enter/Space to activate
• Escape to close modals
• Arrow keys for menus/lists

Focus trapping

• Modals should trap focus inside
• Focus returns to trigger when closed
• "Trap focus inside the modal when it's open"

Forms & Interactive Elements

Form accessibility

• Labels connected to inputs
• Clear error messages
• Required field indicators
• Autocomplete attributes

Touch targets

• Minimum 44x44px for touch
• Adequate spacing between targets
• "Make sure all buttons are at least 44px tall"

Error handling

• Don't rely only on color
• Explain what went wrong
• Suggest how to fix it
• Associate errors with inputs

Motion & Animation

Reduced motion preference

• Check prefers-reduced-motion
• Provide alternatives for motion-sensitive users
• Essential animations only, reduced intensity

Prompting for motion safety

Add support for reduced motion preference.
Users who prefer reduced motion should see
minimal or no animation.

What to reduce

• Decorative animations: remove entirely
• Functional animations: simplify or reduce duration
• Parallax effects: disable
• Auto-playing video: pause

Platform-Specific Guidance

Web

• Semantic HTML elements
• ARIA when HTML isn't enough
• Keyboard event handlers
• Focus management

SwiftUI/iOS

• Rotor actions for complex controls
• Accessibility traits (.isButton, .isHeader)
• Accessibility sorting priority
• Dynamic Type support

macOS

• Full keyboard navigation
• VoiceOver compatibility
• High contrast mode
• Reduce transparency

Testing Accessibility

Automated tools

• Lighthouse accessibility audit
• axe DevTools browser extension
• Xcode Accessibility Inspector

Manual testing

• Tab through entire interface
• Test with VoiceOver/TalkBack
• Test with keyboard only
• Zoom to 200%

Prompting for testing

Walk me through how to test this with VoiceOver.
What should I check?

Example Prompts

Overall accessibility review

Review this component for accessibility.
Check:
- Proper semantic structure
- Screen reader labels
- Keyboard navigation
- Color contrast
- Focus management

Adding labels

Add accessibility labels to all the icon buttons.
They need to describe what the button does.

Focus management

When the modal opens, focus should move to it.
When it closes, focus should return to the button
that opened it.

Dynamic Type (iOS)

Make sure this view supports Dynamic Type.
Text should scale with the user's system setting.

Skip navigation

Add a skip link that lets keyboard users
jump past the navigation to the main content.

Make It Stick with a Skill File

This guide teaches you how to prompt for accessibility. If you want Claude to build accessibly by default — semantic HTML, proper ARIA, focus management, contrast ratios — without you having to ask each time, drop the Accessibility skill file into your project.

What You'll Learn

• Why accessibility benefits everyone
• How to prompt for screen reader support
• Color contrast requirements and testing
• Keyboard navigation patterns
• Motion and animation considerations
• Testing accessibility across platforms

Exercises

1. Run the "Overall accessibility review" prompt on one component, then implement every fix Claude suggests across semantic structure, labels, keyboard nav, contrast, and focus.
2. Tab through one full screen using only your keyboard — note any element you can't reach or that lacks a visible focus state, then prompt Claude to add visible focus and logical tab order.
3. Add prefers-reduced-motion support to an animated view using the motion-safety prompt, then toggle your OS "reduce motion" setting to confirm the animation simplifies or disappears.