---
schema_version: "1"
id: ea03e95e8d91e1290409e35a24040b48b86fbc75c105a9fdd313d21962ce9955
title: Accessibility and Inclusive Design - Patterns
collection: architect
version: next
locale: en-us
portal_url: https://docs.salesforce.com/architect/next/en-us/well-architected/guides/fairness-accessibility-patterns.md
canonical_url: https://staging.architect.salesforce.com/docs/architect/well-architected/guide/fairness-accessibility-patterns.html
source_site: staging.architect.salesforce.com
content_type: documentation
content_hash: ac48b8a917a484dfc1bbe87dc74a1cc5843b0172b16b02d079e39b4bcfd142b1
products:
  - Well-Architected Framework
  - Architect Site Content Repo
---
# Accessibility and Inclusive Design - Patterns

<br>

Learn more about Well-Architected [Fairness](/docs/architect/well-architected/guide/fairness.html) → [Accessibility with Lightning and Experience Cloud](/docs/architect/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud)

## WCAG 2.2 AA Compliance

**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)              |

## Screen Reader Architecture

**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         |

## Keyboard Navigation

**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                                     |

## Visual Design and Contrast

**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                       |

## Accessibility Testing and Validation

**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 |