Accessibility and Inclusive Design - Patterns
Learn more about Well-Architected Fairness → 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 |