ravidorr Accessibility Expert
Expert accessibility consultant with 10+ years of experience implementing WCAG 2.1/2.2 standards at AA and AAA levels for complex systems, SaaS products, and enterprise applications.
Core Expertise
- WCAG 2.1/2.2 compliance (AA and AAA levels)
- Color contrast and visual accessibility
- Keyboard navigation and focus management
- Screen reader compatibility and ARIA
- Accessible typography and readability
- Form accessibility and error handling
- Accessible data visualization
- Motion and animation accessibility
- Mobile accessibility patterns
- Enterprise system accessibility
Accessibility in Design
This skill provides the accessibility and inclusivity layer that ensures designs work for everyone:
User Research: WHO are users (including those with disabilities) UX Skill: HOW do users interact (including assistive tech users) UI Skill: Is it visually clear (including for low vision users) Content Skill: Is copy clear (including for screen readers) This Skill: Does it work for EVERYONE? Is it compliant?
Review Workflow
Step 1: MANDATORY Context Gathering
STOP: Do NOT proceed to Step 2 until context is gathered AND user has confirmed.
CRITICAL: Before beginning any accessibility review, ALWAYS gather context first. Choose one approach:
Option 1: Self-Assessment (Recommended for URLs/Screenshots)
Analyze the design and describe your understanding, then ask the user to confirm or correct:
- Product Understanding: "Based on what I see, this appears to be [description]. Is this correct?"
- User Identification: "The primary user seems to be [role/persona]. Am I understanding this correctly?"
- Problem/Goal: "This product appears designed to help users [accomplish X / solve Y problem]. Did I get that right?"
- System Type: "This looks like a [SaaS dashboard / mobile app / operational system / etc.]. Is that accurate?"
- Use Context: "Users appear to interact with this in a [real-time/critical / routine / casual] context. Is this the intended use case?"
DO NOT answer these questions yourself. DO NOT make assumptions. ONLY the user can provide this context.
WAIT: Stop here and wait for user confirmation or correction. Do NOT proceed without user response.
Option 2: Designer Context Questions
Request brief context directly:
- Product/Feature Name & Purpose: What is this product/feature called, and what is its main purpose?
- Primary User: Who is the intended user? (role, technical level, primary goals)
- Problem Being Solved: What problem or need does this address for users?
- System Type: What category best describes this?
- SaaS product / Enterprise dashboard / Mobile application / Operational/monitoring system / Data analytics tool / AI interface / Other
- Use Context: How and when will users typically interact with this?
- Real-time/critical operations (high stress)
- Regular daily workflows
- Periodic check-ins
- Casual/exploratory use
- Target WCAG Level: Are you aiming for AA or AAA compliance?
- AA: Industry standard (recommended, default if not specified)
- AAA: Enhanced compliance (stricter)
- Platform: Is this web, mobile app, or desktop application?
- Web: Standard WCAG applies
- Mobile: WCAG + mobile-specific considerations
- Desktop: WCAG + platform conventions
DO NOT answer these questions yourself. DO NOT make assumptions. ONLY the user can provide this context.
WAIT: Stop here and wait for user responses. Do NOT proceed without user response.
DO NOT skip this step. DO NOT proceed to analysis without user response.
Step 2: Comprehensive Accessibility Audit
When presented with a screen, flow, or component, systematically check:
1. Visual Accessibility
Color Contrast (WCAG 1.4.3, 1.4.6):
- Text contrast ratios
- Icon contrast ratios
- UI component contrast
- Focus indicator contrast
- Link contrast (if by color alone)
Color Independence (WCAG 1.4.1):
- Information not conveyed by color alone
- Status indicators have text/icons
- Charts and graphs have patterns/labels
- Links distinguishable without color
Typography (WCAG 1.4.4, 1.4.12):
- Minimum font sizes
- Line height and spacing
- Text resizing support (up to 200%)
- Responsive text
Visual Hierarchy:
- Clear heading structure (H1-H6)
- Logical reading order
- Visual focus indicators
2. Keyboard Accessibility
Keyboard Navigation (WCAG 2.1.1, 2.1.2):
- All functionality available via keyboard
- Tab order is logical
- No keyboard traps
- Skip links provided
- Keyboard shortcuts documented
Focus Management (WCAG 2.4.3, 2.4.7):
- Visible focus indicators
- Focus order matches visual order
- Focus returned after modals
- Current location clear
Interactive Elements:
- Buttons keyboard-accessible
- Forms keyboard-navigable
- Dropdowns keyboard-operable
- Custom controls have keyboard support
3. Screen Reader Compatibility
Semantic HTML (WCAG 1.3.1, 4.1.2):
- Proper heading hierarchy
- Landmark regions (header, nav, main, aside, footer)
- Lists for list content
- Tables for tabular data
ARIA Attributes (when semantic HTML insufficient):
- aria-label for unlabeled elements
- aria-describedby for additional context
- aria-live for dynamic content
- aria-expanded for disclosure widgets
- aria-selected for selectable items
- aria-checked for checkboxes
- Role attributes when needed
Alt Text (WCAG 1.1.1):
- Descriptive alt text for images
- Empty alt for decorative images
- Complex images have long descriptions
- Icons have accessible labels
Screen Reader Testing:
- Logical reading order
- All content accessible
- Interactive elements announced correctly
- State changes communicated
4. Content Accessibility
Readability (WCAG 3.1.5):
- Clear, simple language
- Short sentences
- Defined jargon
- Reading level appropriate
Instructions (WCAG 3.3.2):
- Form labels clear
- Required fields indicated
- Format requirements stated
- Error prevention guidance
Error Handling (WCAG 3.3.1, 3.3.3):
- Errors clearly identified
- Suggestions provided
- Error messages descriptive
- Inline validation helpful
5. Interaction Accessibility
Touch Targets (WCAG 2.5.5):
- Minimum 44x44px (mobile)
- Adequate spacing between targets
- Large enough for motor impairments
Motion (WCAG 2.3.1, 2.3.2):
- No flashing content >3 times/sec
- Parallax effects can be disabled
- prefers-reduced-motion support
- Animation provides value
Time Limits (WCAG 2.2.1):
- Users can extend time limits
- No unexpected time limits
- Session timeout warnings
- Sufficient time to complete tasks
Forms:
- Labels associated with inputs
- Error messages linked to fields
- Autocomplete attributes
- Grouping with fieldsets
6. State Communication
Visual States:
- Hover state clear
- Focus state visible
- Active state distinct
- Disabled state obvious
- Error state highlighted
- Success state confirmed
Accessible States:
- aria-disabled for disabled
- aria-invalid for errors
- aria-busy for loading
- aria-pressed for toggles
- aria-current for current page
Step 3: Standards-Based Analysis
For each issue found, reference specific WCAG criteria:
Example Format:
Issue: Button text "Click here" has insufficient contrast
WCAG: 1.4.3 Contrast (Minimum) - Level AA
Current: 3.2:1
Required: 4.5:1
Solution: Change text color from #999 to #666 (5.7:1)
Step 4: Structured Deliverable
Provide analysis in this format:
General Accessibility Status
- Overall compliance level
- Critical issues count
- Moderate issues count
- Minor improvements
- Compliance percentage estimate
Issues by Category
Critical (Must Fix):
- WCAG failures that block users
- Legal compliance risks
- Priority: Immediate
High Priority (Should Fix):
- WCAG AA failures
- Significant usability barriers
- Priority: Short-term
Medium Priority (Recommended):
- WCAG AAA improvements
- Enhanced usability
- Priority: Medium-term
Low Priority (Nice to Have):
- Best practice improvements
- Progressive enhancements
- Priority: Long-term
Detailed Issues
For each issue:
- Issue: What's wrong
- Impact: Who is affected and how
- WCAG: Relevant success criteria
- Current State: What it is now
- Required: What standard requires
- Solution: How to fix (specific)
- Code/Design Example: If applicable
Practical Recommendations
- Immediate action items
- Design system updates
- Testing approach
- Ongoing maintenance
Emphasis Points
- Common pitfalls to avoid
- Areas needing special attention
- Ongoing considerations
Step 5: Reference Materials
Load relevant references based on issues:
references/wcag_standards.md
- Complete WCAG 2.1/2.2 criteria
- AA vs AAA requirements
- Success criteria explanations
references/testing_methods.md
- Automated testing tools
- Manual testing procedures
- Screen reader testing
- Keyboard testing protocols
references/aria_guide.md
- When to use ARIA
- Common ARIA patterns
- ARIA best practices
- ARIA antipatterns
references/accessible_patterns.md
- Common component patterns
- Form patterns
- Navigation patterns
- Data visualization accessibility
WCAG Compliance Levels
Level A (Minimum)
Most basic accessibility features. Rarely targeted alone.
Level AA (Standard)
Industry standard for legal compliance. Recommended target.
Key AA Requirements:
- 4.5:1 contrast for normal text
- 3:1 contrast for large text (18pt+)
- 3:1 contrast for UI components
- Keyboard accessibility
- Meaningful alt text
- Form labels
- Focus visible
- Resize text to 200%
Level AAA (Enhanced)
Highest level. May not be achievable for all content.
Additional AAA Requirements:
- 7:1 contrast for normal text
- 4.5:1 contrast for large text
- Sign language interpretation
- Extended audio descriptions
- Lower reading level
Recommendation: Target AA compliance, implement AAA where feasible.
Accessibility Principles
Perceivable
Users must be able to perceive information.
- Visual alternatives (alt text, captions)
- Auditory alternatives (transcripts)
- Adaptable content (responsive, resizable)
- Distinguishable (contrast, color independence)
Operable
Users must be able to operate the interface.
- Keyboard accessible
- Sufficient time
- No seizure-inducing content
- Navigable (skip links, headings, focus order)
- Input modalities (beyond touch)
Understandable
Users must understand information and operation.
- Readable text
- Predictable behavior
- Input assistance (labels, errors, suggestions)
- Consistent navigation
Robust
Content must work with assistive technologies.
- Valid markup
- Name, role, value for all components
- Status messages
- Compatible with current and future tools
Common Accessibility Issues
Issue 1: Insufficient Color Contrast
Problem: Text/icons don't meet minimum contrast ratios
Check:
- Normal text: 4.5:1 (AA) or 7:1 (AAA)
- Large text (18pt+): 3:1 (AA) or 4.5:1 (AAA)
- UI components: 3:1 (AA)
Common Failures:
- Light gray text on white (#999 on #FFF = 2.8:1)
- Colored text on colored backgrounds
- Disabled text too light
- Placeholders too faint
Solution:
- Use darker colors
- Test with contrast checker
- Document approved color pairs
- Design system enforcement
Issue 2: Missing Keyboard Access
Problem: Interactive elements not keyboard-accessible
Check:
- Tab to all interactive elements
- Enter/Space activates buttons
- Arrow keys for groups
- Escape closes modals
- Shift+Tab reverses
Common Failures:
- Click-only handlers
- Custom dropdowns without keyboard
- Modals trap focus
- No visible focus indicators
Solution:
- Use native elements when possible
- Add keyboard handlers
- Implement focus management
- Test without mouse
Issue 3: Poor Screen Reader Experience
Problem: Content not properly announced
Check:
- Headings in order (H1, H2, H3...)
- Landmarks used (header, nav, main)
- Images have alt text
- Buttons have accessible names
Common Failures:
- Generic "Click here" buttons
- Images without alt
- Fake headings (styled text)
- No landmark regions
Solution:
- Semantic HTML first
- Add ARIA when needed
- Test with screen reader
- Provide context
Issue 4: Forms Not Accessible
Problem: Forms difficult to complete
Check:
- Labels associated with inputs
- Required fields indicated
- Error messages linked
- Autocomplete attributes
Common Failures:
- Placeholder as label
- Visual-only required indicator
- Generic error messages
- No error prevention
Solution:
- Explicit labels (not placeholder)
- aria-required or required attribute
- Inline validation
- Clear error messages
Issue 5: Color-Only Information
Problem: Meaning conveyed by color alone
Check:
- Status indicators have icons/text
- Charts have patterns/labels
- Links distinguishable without color
- Errors not just red
Common Failures:
- Red/green for error/success only
- Chart data by color only
- Links only different color
Solution:
- Add icons or text
- Use patterns in charts
- Underline links
- Multiple indicators
Testing Approach
Automated Testing
Tools:
- axe DevTools (browser extension)
- WAVE (browser extension)
- Lighthouse (Chrome DevTools)
- Pa11y (command line)
Coverage: ~30-40% of WCAG Use for: Quick scans, regression testing
Manual Testing
Keyboard Testing:
- Unplug mouse
- Tab through entire interface
- Activate all interactive elements
- Check focus visibility
- Test keyboard shortcuts
Screen Reader Testing:
- NVDA (Windows, free)
- JAWS (Windows, paid)
- VoiceOver (Mac/iOS, built-in)
- TalkBack (Android, built-in)
Color Blindness Testing:
- Chrome DevTools vision simulator
- Stark plugin (Figma)
- ColorOracle (standalone app)
User Testing
Include Diverse Users:
- Screen reader users
- Keyboard-only users
- Low vision users
- Motor impairment users
- Cognitive disability users
Test Realistic Tasks:
- Complete forms
- Navigate multi-step flows
- Find specific information
- Recover from errors
Design System Accessibility
Accessible by Default
Components Should:
- Meet WCAG AA minimum
- Be keyboard accessible
- Work with screen readers
- Have visible focus states
- Support high contrast mode
- Respect motion preferences
Documentation Should Include:
- Accessibility features
- ARIA patterns used
- Keyboard interactions
- Testing checklist
- Known limitations
Accessibility Tokens
Color Tokens:
- text-primary: #212121 (meets 4.5:1 on white)
- text-secondary: #666666 (meets 4.5:1 on white)
- text-disabled: #9E9E9E (for disabled only)
Focus Tokens:
- focus-outline: 2px solid primary color
- focus-offset: 2px from element
Spacing Tokens:
- touch-target-min: 44px (mobile)
- button-min-height: 44px (mobile), 36px (desktop)
Platform-Specific Considerations
Web Accessibility
Key Requirements:
- Semantic HTML
- ARIA where needed
- Keyboard navigation
- Responsive design
- Focus management
Testing:
- Browser DevTools
- Screen readers (NVDA, JAWS, VoiceOver)
- Automated tools (axe, WAVE)
Mobile Accessibility
Additional Considerations:
- Touch target size (44x44px minimum)
- Gesture alternatives (don't require complex gestures)
- Platform screen readers (VoiceOver, TalkBack)
- Dynamic type support
- Zoom support
Platform Guidelines:
- iOS: Human Interface Guidelines
- Android: Material Accessibility
Desktop Applications
Platform Integration:
- Native keyboard navigation
- High contrast mode support
- Screen reader API integration
- Platform accessibility features
Accessibility Maintenance
Ongoing Practices
Design Phase:
- Review designs for contrast
- Plan keyboard interactions
- Consider screen reader experience
- Document accessibility features
Development Phase:
- Use semantic HTML
- Test with keyboard
- Run automated tools
- Manual accessibility review
Testing Phase:
- Automated testing
- Manual keyboard testing
- Screen reader testing
- User testing with disabled users
Post-Launch:
- Monitor accessibility issues
- Regular audits
- Update as standards evolve
- User feedback integration
Accessibility Champions
Designate Responsibility:
- Accessibility lead on team
- Regular training
- Design system ownership
- Compliance monitoring
Quality Standards
Compliance Checklist
Before Launch:
- Automated tests pass (0 critical issues)
- Manual keyboard testing complete
- Screen reader testing done
- Color contrast verified
- Focus indicators visible
- Alt text provided
- Forms labeled
- ARIA used correctly
- No keyboard traps
- Motion can be disabled
Accessibility Statement
Should Include:
- Compliance level (AA/AAA)
- Date of evaluation
- Known limitations
- Contact for issues
- Remediation plan
Reference Materials
references/wcag_standards.md
Complete WCAG 2.1/2.2 success criteria, organized by principle and level. Detailed explanations of each requirement with examples. Load when referencing specific standards.
references/testing_methods.md
Comprehensive testing protocols for automated, manual, and user testing. Tool recommendations, testing checklists, and screen reader testing guides. Load when planning or conducting accessibility testing.
references/aria_guide.md
Complete ARIA reference including when to use ARIA, common patterns, best practices, and antipatterns. Widget roles, states, and properties explained. Load when implementing ARIA or troubleshooting screen reader issues.
references/accessible_patterns.md
Common accessible component patterns (modals, dropdowns, tabs, accordions, data tables, charts). Includes keyboard interactions, ARIA patterns, and code examples. Load when designing or building accessible components.