Accessibility

Accessibility ensures users of all abilities can understand, navigate, interact with, and contribute to our interfaces meaningfully. It’s not just the right thing to do — accessible design is better design for everyone. Both Aura and product teams should strive to meet WCAG 2.1 AA as a minimum standard. Accessibility is a shared responsibility across design, content, and engineering.

​

Contrast

• Informative content (text, images, graphs, buttons) must meet a minimum contrast ratio of 4.5:1 — the WCAG AA standard for readability.
• Large text (24px and above, or 18px bold) can use a reduced ratio of 3.0:1.
• When Aura color tokens are used correctly, the contrast ratio is automatically met.

​

Disabled states

• Disabled components must be visually distinct from active states — not just through color alone.
• They should remain focusable for assistive technology users, with aria-disabled="true" to communicate non-interactivity.
• Where possible, avoid disabled states. Otherwise, help users understand why something is disabled and how to enable it.

​

Documents

• Downloadable files (PDF, Word, PowerPoint) must be structured, labeled, and formatted to support screen readers and other assistive technologies.

​

Focus states

• Always provide visible focus states for interactive elements using Aura’s focus styling.
• See the Interaction states page for visual references.

​

Graphs and data visualizations

• Charts and graphs must be understandable in black and white — this supports users with color blindness or low vision.
• Where color is essential, vary both hue and lightness to create contrast, and supplement with patterns, textures, or labels to differentiate data points.

​

Labels

• Never rely on color alone to convey information. Use descriptive text to clarify actions and purpose.
• Use inclusive field labels. For example, we prefer “Full name” over splitting into “First name” and “Last name” to accommodate diverse naming conventions.

​

Links

• Links should be identifiable by more than color — use underlines with proper link-foreground color token.
• Link text should be descriptive: “Learn more about accessibility” rather than “click here.”

​

Navigation

• Navigation should be consistent across the entire interface so users can build a mental model of how to get around.
• Headers, footers, and key navigation elements should follow the same structure across pages.

​

Semantic alerts

• Error messages must include a clear, actionable description in plain language. For example: “Please enter a valid email address in the format user@example.com” rather than just “Invalid email.”
• Use semantic HTML (for example, <div role="alert">) so errors and alerts are recognized by screen readers.

​

Spacing

• Leave at least 8px between interactive elements to prevent accidental clicks.
• Touch targets should be at least 44px in either width or height.

​

Text hierarchy and headings

• Use a consistent, meaningful heading hierarchy (H1, H2, H3) across all interfaces.
• Don’t skip heading levels — screen reader users rely on heading structure to navigate content.

​

User zoom

• Interfaces must remain functional when zoomed to 200%, in line with WCAG standards.
• Text and interactive elements should resize without breaking layout or requiring horizontal scrolling. Vertical scrolling is acceptable.

​

Video and audio

• All video content must include captions for spoken dialogue and relevant sounds.
• Audio-only content should include a transcript for users who cannot listen or prefer to read.

​

Visual order and importance

• Place content on the page in order of importance so users can find critical information without searching.
• Ensure content follows a logical reading order for screen reader users.