Accessibility & WCAG 2.2 AA

Great software must be usable by everyone. For too many productivity applications, accessibility is treated as an afterthought—an incomplete patch applied late in development to satisfy enterprise procurement checklists.

When software ignores accessibility fundamentals, users who rely on screen readers, high-contrast display modes, keyboard navigation, or switch control hardware encounter insurmountable barriers: unlabelled icon buttons, inaccessible custom dropdowns, trapped keyboard focus, and low-contrast typography.

Oyma was engineered from the very beginning with inclusive design principles. Proven in our automated test suite tests/e2e/workspace-a11y.spec.ts, Oyma is continuously validated against the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA standards using the industry-standard axe-core testing engine.

Semantic architecture and VoiceOver compatibility on macOS

Screen reader accessibility cannot be bolted on as an afterthought; it requires rigorous semantic HTML structure and disciplined ARIA markup:

1. Native macOS VoiceOver support: Every major surface—the file navigation tree, the live-preview Markdown editor, the audio recording dock, and the settings dialogs—is marked with proper semantic roles (role="tree", role="region", role="toolbar").
2. Accessible name computation: Every icon button (such as play, pause, bookmark, and fold toggles) features explicit aria-label text describing its exact action, ensuring VoiceOver users never hear generic “button” announcements.
3. Live regions for real-time status changes: When audio recording begins via meeting recording without a bot or when on-device Whisper transcription detects incoming speech, ARIA live regions (aria-live="polite") announce status updates without interrupting active reading.

Blind and low-vision users can record meetings, review transcripts, and author complex documentation with equal speed and dignity.

Total keyboard operability: Zero mouse traps

A core pillar of WCAG 2.2 compliance is ensuring that all functionality is accessible via keyboard interfaces:

• Unrestricted tab traversal: All interactive controls participate in a logical, predictable focus order. Tab keys never get trapped within custom editor components or dialog overlays.
• High-visibility focus rings: Focus rings feature prominent contrast ratios against both light and dark backgrounds, making active cursor locations unmistakable at a glance.
• Unified command HUD: The command palette (⌘O) allows power users to navigate files, run commands, and jump to headings without lifting their hands from the keyboard.
• Native macOS text shortcuts: The editor supports standard macOS navigation keybindings (⌥Left/Right for word jumping, ⌘Up/Down for document bounds, and standard readline controls like Ctrl-A and Ctrl-E).

Whether you are navigating with a standard keyboard, an ergonomic split board, or assistive switch devices, Oyma responds reliably to every keystroke.

High-contrast visual ergonomics and scalable typography

Visual comfort and clarity are essential for neurodivergent individuals, users with low vision, and anyone experiencing eye fatigue during long working sessions:

• Strict WCAG contrast compliance: Text colors, UI borders, and interactive tokens maintain a minimum contrast ratio of 4.5:1 for body copy and 3:1 for large text and interface components, satisfying WCAG AA thresholds.
• Dynamic type scaling: Interface fonts and note typography respect system text scaling preferences, reflowing gracefully without clipped text or broken layout bands.
• Subtle, non-distracting motion: Animations respect the system prefers-reduced-motion setting. Smooth fades and slide transitions are disabled automatically for users susceptible to motion sickness or vestibular disorders.

Assistive hardware compatibility and auditory feedback

Beyond keyboard and screen reader accessibility, Oyma accommodates users with diverse motor and cognitive needs:

• Switch Control and Full Keyboard Access: Fully compatible with native macOS Switch Control and Head Pointer navigation for individuals with limited upper mobility.
• Auditory feedback cues: Optional subtle audio chimes announce recording starts, pauses, and completions, giving users non-visual verification of meeting capture states.
• Accessible table interactions: Screen readers announce row and column indices as users navigate through tables, ensuring tabular data remains comprehensible without sight.
• Dyslexia and reading accommodations: Users can select open-source dyslexia-friendly font pairings (such as Atkinson Hyperlegible or OpenDyslexic) and adjust paragraph line spacing to minimize visual crowding and improve reading stamina during long study sessions.

Continuous automated testing with axe-core

To prevent accessibility regressions, Oyma incorporates automated auditing directly into its continuous integration test suite (tests/e2e/workspace-a11y.spec.ts).

On every build:

• Automated headless browsers load each workspace view, modal dialog, and tool interface.
• The axe-core rules engine audits the DOM against dozens of accessibility rules: color contrast ratios, duplicate element IDs, missing form labels, ARIA role appropriateness, and keyboard traps.
• If any pull request introduces an accessibility regression, the build fails automatically, blocking the regression from reaching users.

Experience thoughtful, inclusive note-taking and meeting intelligence designed for every user with Oyma.