# Accessibility and Inclusive Design - Patterns | Patterns Source: https://architect.salesforce.com/docs/architect/well-architected/guide/fairness-accessibility-patterns.html > Proven patterns for WCAG compliance, screen reader architecture, keyboard navigation, visual design, and accessibility testing aligned to the Well-Architected Fairness pillar. # Accessibility and Inclusive Design - Patterns Learn more about Well-Architected [Fairness](https://architect.salesforce.com/docs/architect/well-architected/guide/fairness.html) → [Accessibility with Lightning and Experience Cloud](https://architect.salesforce.com/docs/architect/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud) **Patterns** Where to look What good looks like Platform | Design Standards ✅ WCAG 2.2 Level AA is the minimum accessibility bar for custom-built work (Experience Cloud, LWCs, custom themes), verified by the building team Platform | Design Standards ✅ Perceivable principle: Text alternatives exist for images and icons; captions accompany videos Platform | Design Standards ✅ Operable principle: All functionality is operable via keyboard alone, without requiring mouse or touch — voice-control and switch-access assistive technologies rely on the same keyboard/focus model Platform | LWC ✅ Standard Lightning Web Components are used as designed, providing baseline accessibility automatically Platform | LWC ✅ Custom components implement explicit accessibility validated through testing with screen readers Platform | Test Plans ✅ Accessibility testing is included in all testing phases (not ad hoc or optional) **Anti-Patterns** Where to look What bad looks like Platform | Design Standards ⚠️ WCAG 2.2 Level AA is treated as optional or “nice to have” rather than minimum requirement Platform | Design Standards ⚠️ Images and icons lack text alternatives; videos lack captions Platform | Design Standards ⚠️ Functionality requires mouse or touch interaction with no keyboard alternative Platform | LWC ⚠️ Custom components are built without accessibility implementation or validation Platform | LWC ⚠️ Custom input components use div elements and CSS styling with no semantic meaning or keyboard accessibility Platform | Test Plans ⚠️ Accessibility testing is ad hoc, optional, or only performed before launch (not throughout development) **Patterns** Where to look What good looks like Platform | LWC ✅ Semantic HTML elements (header, nav, main, aside, footer, article, section) are used in custom Lightning Web Components Platform | LWC ✅ ARIA landmarks, roles, and properties are applied where semantic HTML alone cannot convey interface behavior Platform | LWC ✅ Dynamic content updates use aria-live regions announcing changes to screen reader users Platform | LWC ✅ Custom interactive components have explicit role definitions matching their behavior Platform | LWC ✅ Form labels are explicitly associated with all form inputs using proper label elements or aria-labelledby attributes Platform | LWC ✅ Lightning input components are configured with required label attributes providing built-in label association Platform | Test Plans ✅ Testing is conducted with actual screen readers: JAWS and NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android Platform | Test Plans ✅ Manual testing with real assistive technology is performed by people who understand how screen reader users navigate Platform | Design Standards ✅ Placeholder text is never used as the sole label because placeholders disappear on focus and provide insufficient context for screen readers **Anti-Patterns** Where to look What bad looks like Platform | LWC ⚠️ Div-heavy markup strips meaning from content hierarchy forcing screen reader users to navigate linearly Platform | LWC ⚠️ ARIA is not used where semantic HTML alone cannot convey interface behavior Platform | LWC ⚠️ Dynamic content updates do not use aria-live regions; screen reader users miss important changes Platform | LWC ⚠️ Custom interactive components lack explicit role definitions; screen readers announce them incorrectly Platform | LWC ⚠️ Form inputs lack explicit label association; placeholder text is used as sole label Platform | Test Plans ⚠️ Automated accessibility tools are used exclusively; manual screen reader testing is not performed Platform | Test Plans ⚠️ Testing is conducted by sighted users unfamiliar with how screen reader users actually navigate **Patterns** Where to look What good looks like Platform | Design Standards ✅ Complete functionality is accessible via keyboard without requiring mouse or touch interaction at any point in user journeys Platform | LWC ✅ Logical focus order follows visual layout and interaction flow Platform | LWC ✅ When dynamic content loads or modals open, focus is programmatically managed to guide keyboard users to new content Platform | LWC ✅ Modal and popover components move focus to modal title or first interactive element on open; return focus to trigger button on close Platform | Design Standards ✅ Visible focus indicators clearly show which element has keyboard focus at all times Platform | Design Standards ✅ Focus indicators meet the 3:1 contrast requirement against surrounding content Platform | LWC ✅ Users can navigate into and out of all components using keyboard alone without becoming trapped Platform | LWC ✅ Modal dialogs trap focus within the modal while open (preventing access to obscured content) but release focus on close Platform | Design Standards ✅ Keyboard shortcuts for frequent actions avoid conflicts with screen reader shortcuts and browser shortcuts Platform | Design Standards ✅ Single-letter shortcuts only activate when specific components have focus (not globally) to avoid conflicts with screen reader navigation commands Platform | Documentation ✅ All custom keyboard shortcuts are documented in accessible help content Platform | Test Plans ✅ Test steps include keyboard-only navigation through all user journeys without using mouse or touch **Anti-Patterns** Where to look What bad looks like Platform | Design Standards ⚠️ Functionality requires mouse or touch interaction; keyboard-only users cannot complete key tasks Platform | LWC ⚠️ Focus order does not follow logical visual layout; users tab through elements in unexpected sequence Platform | LWC ⚠️ Modals open without focus management; keyboard users are stranded on now-hidden trigger button Platform | LWC ⚠️ Modal close does not return focus to trigger button; users must hunt for their place in the page Platform | Design Standards ⚠️ Focus indicators are suppressed for aesthetic reasons; users cannot see which element has focus Platform | Design Standards ⚠️ Focus indicators have insufficient contrast (<3:1) Platform | LWC ⚠️ Users become trapped in interface regions with no escape mechanism (keyboard traps) Platform | LWC ⚠️ Embedded content (iframes, third-party widgets) permanently captures keyboard focus Platform | Design Standards ⚠️ Single-letter shortcuts activate globally conflicting with screen reader single-letter navigation commands Platform | Documentation ⚠️ Custom keyboard shortcuts are undocumented; users cannot discover them **Patterns** Where to look What good looks like Platform | Design Standards ✅ Minimum 4.5:1 contrast ratio for normal text under 18pt or 14pt bold Platform | Design Standards ✅ Minimum 3:1 contrast ratio for large text and for meaningful UI components and graphics (form borders, informational icons); purely decorative and disabled elements are exempt Platform | Experience Cloud ✅ Custom themes and branded Experience Cloud sites include explicit contrast validation using browser dev tools or automated checkers Platform | Design Standards ✅ Text resize to 200% is supported without loss of content or functionality (WCAG requirement) **Anti-Patterns** Where to look What bad looks like Platform | Design Standards ⚠️ Text contrast ratios fall below 4.5:1 (normal text) or 3:1 (large text and UI components) Platform | Experience Cloud ⚠️ Custom themes are deployed without contrast validation; low vision users cannot read content Platform | Design Standards ⚠️ Text resize beyond 200% breaks layouts losing content or functionality **Patterns** Where to look What good looks like Platform | CI/CD ✅ Axe-core or Lighthouse accessibility scanning is integrated into CI/CD pipelines catching structural issues on every deployment Platform | CI/CD ✅ Builds fail when critical accessibility issues are detected Platform | Test Plans ✅ Manual testing with screen readers, keyboard-only navigation, and browser zoom to 200% is performed regularly throughout development Platform | Test Plans ✅ Testing reveals interaction problems including confusing announcement order, focus management failures, and keyboard traps Platform | Business ✅ Users with disabilities are included in usability testing throughout design process Platform | Business ✅ Usability testing reveals practical barriers that automated and manual expert testing miss Platform | Test Plans ✅ Automated testing (~57% of issues by volume), manual testing (interaction problems), and user testing (real-world barriers) are all performed **Anti-Patterns** Where to look What bad looks like Platform | CI/CD ⚠️ Accessibility scanning is not integrated into CI/CD pipelines Platform | CI/CD ⚠️ Builds proceed despite critical accessibility issues Platform | Test Plans ⚠️ Manual testing with assistive technology is not performed; only automated scanning is used Platform | Business ⚠️ Users with disabilities are not included in usability testing Platform | Test Plans ⚠️ Automated accessibility scanner is run once before launch and accessibility testing is considered done