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.Documentation Index
Fetch the complete documentation index at: https://docs.cognite.com/llms.txt
Use this file to discover all available pages before exploring further.
Acronyms used in this section
- WCAG — Web Content Accessibility Guidelines
- WAI-ARIA — Web Accessibility Initiative – Accessible Rich Internet Applications
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.