Building interfaces that work for everyone.
Good UI doesn't exclude people. Odyssey UI is built to be usable by default—no extra configuration needed for basic accessibility. We believe that inclusive design creates better experiences for all users, not just those with disabilities.
Motion & Animation
Understanding motion sensitivity
Some people experience discomfort, dizziness, or nausea from animation. Browsers and operating systems include a Reduced Motion setting (prefers-reduced-motion) for this.
When enabled, users typically prefer:
- Skip large movements like scaling, sliding, or rotating
- Subtle opacity fades instead of motion
- No parallax or auto-scrolling effects
- No looping or auto-playing background animation
How we handle it
Odyssey UI uses Motion under the hood. Wrap your app once to automatically respect this setting across all components:
This ensures that users who have requested reduced motion in their system preferences will automatically receive a more comfortable experience without any additional code changes in your components.
Keyboard Navigation
Full keyboard support
All interactive elements in Odyssey UI are fully accessible via keyboard:
- Tab navigation: Logical focus order follows the visual layout
- Focus indicators: Clear, high-contrast focus rings show where you are
- Shortcut keys: Common actions support standard keyboard shortcuts
- Escape handling: Modals and dropdowns close with the Escape key
- Trap focus: When a modal opens, focus stays within it until closed
Testing keyboard accessibility
You can verify keyboard support by unplugging your mouse and navigating your application using only:
Tab/Shift+Tabto move between elementsEnterorSpaceto activate buttons and linksArrow keysfor radio groups, sliders, and menusHome/Endfor jumping to start/end of lists
Screen Readers
Semantic HTML and ARIA
Odyssey UI components use proper semantic HTML elements and ARIA attributes to ensure screen readers can interpret them correctly:
- Landmarks: Header, main, navigation, and footer regions are properly marked
- Headings: Hierarchical heading structure for easy navigation
- Labels: All form inputs have associated labels
- Live regions: Dynamic content updates are announced appropriately
- Descriptions: Complex components include supplementary text when needed
Testing with screen readers
We test with the following screen reader combinations:
- NVDA + Firefox (Windows)
- JAWS + Chrome (Windows)
- VoiceOver + Safari (macOS and iOS)
- TalkBack + Chrome (Android)
Accessibility Note: While our components are designed with accessibility in mind, we recommend always testing with real assistive technologies and users. Automated tools catch only about 30% of accessibility issues—human testing is irreplaceable for creating truly inclusive experiences.