5 min read
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 managementAdding 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.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