Accessibility Statement

MixOps is committed to making its platform usable by people with the widest practical range of abilities. We design and build to Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as our baseline target across all customer-facing surfaces, and we treat accessibility as an ongoing process rather than a one-time audit.

This statement describes the standards we work toward, the assistive technologies we test against, where we know our coverage is incomplete, and how to report a barrier you encounter.

1. Conformance Target

Our target standard is WCAG 2.1 Level AA, published by the W3C Web Accessibility Initiative. This standard is the basis for accessibility law in the United States (Title III of the ADA, Section 508), the European Union (EN 301 549, EAA), the United Kingdom, and most jurisdictions where our customers operate.

We do not claim that every page of the Service currently meets every WCAG 2.1 AA success criterion. We claim that AA is the bar we design against, that we test new surfaces against it before release, and that we will remediate identified gaps under the timelines described in Section 5 below.

2. What We Test

For each customer-facing surface, we verify the following before release:

• Keyboard navigation — every interactive control can be reached and operated using a keyboard alone, in a logical order, without keyboard traps;
• Focus visibility — keyboard focus is always indicated by a visible outline that meets the 3:1 contrast minimum;
• Color contrast — body text meets 4.5:1 against its background; large text and UI components meet 3:1;
• Semantic structure — pages use proper heading hierarchy, landmarks (<main>, <nav>, <article>), and form labels;
• Text resizing — content remains usable at 200% browser zoom without horizontal scrolling on standard desktop viewports;
• Reduced motion — animations and transitions respect the prefers-reduced-motion user preference;
• Alternative text — meaningful images carry descriptive alt attributes; decorative images are marked as such;
• Color independence — status and state are communicated by shape or text in addition to color (relevant where users include color-blind operators on facility rigs); and
• No keyboard-only or pointer-only paths — every action can be completed by either input method.

3. Assistive Technologies

We perform manual testing against the following assistive technologies on current and prior-version operating systems:

• Screen readers: VoiceOver (macOS, iOS, iPadOS), NVDA (Windows), JAWS (Windows);
• Voice control: Voice Control (macOS, iOS), Dragon NaturallySpeaking (Windows);
• Keyboard-only navigation across Safari, Chrome, Firefox, and Edge; and
• System-level zoom and high-contrast modes on macOS and Windows.

4. Known Limitations

We disclose these limitations in the interest of honesty and to set expectations. We are actively working on remediation in each case.

4.1 Complex editor surfaces

Editors that present dense spatial data — for example, the Layout Editor, the Knob Map Editor, and the immersive (Atmos/spatial) session viewer — rely heavily on direct visual manipulation. Keyboard equivalents exist for many actions but not yet all. Screen-reader narration of spatial layouts is incomplete and is best understood as "structural orientation, not full reading." For these surfaces we recommend pairing with a sighted colleague for the spatial-editing portions of the workflow.

4.2 Data visualizations

Charts, treemaps, sankey diagrams, and other data visualizations include text alternatives for the underlying numeric data but do not yet expose the full graph structure to assistive technologies in every case. Where a chart is the only way to access an answer, the same data is available in a table view or via a JSON export.

4.3 Third-party content

Some embedded content originates from third parties — for example, font files served by Google Fonts, error reports rendered by browser developer tools, or PDF documents you upload. We cannot guarantee the accessibility of content we do not author. Where we control the framing, we ensure focus management and screen-reader announcement of the embed itself.

4.4 Beta and pilot surfaces

Surfaces marked as beta or pilot may be released ahead of full accessibility review. These are labeled in-product. We will not promote a beta surface to general availability without completing an AA review and remediating blocking issues.

5. Remediation Process

When an accessibility issue is identified — by our own testing, by a user report, or by a third-party audit — we triage it on the following timeline:

• Critical (a barrier that blocks core sign-in, account access, or completing a primary workflow): targeted resolution within 5 business days;
• High (a barrier that prevents a non-primary workflow or significantly degrades a primary workflow): targeted resolution within 30 days;
• Medium (a barrier that creates friction but has a documented workaround): targeted resolution within the next quarterly release cycle; and
• Low (a cosmetic or edge-case issue): targeted resolution at the next planned refactor of the affected surface.

6. Reporting an Issue

If you encounter a barrier using MixOps, or if assistive technology you depend on does not work as expected, please report it. We aim to acknowledge receipt within two business days and to provide an initial triage assessment within five.

Email: accessibility@mixops.io
When possible, please include: the URL or page where you encountered the barrier, the assistive technology and version you were using (e.g., "VoiceOver on macOS 15.2 / Safari 18"), and a brief description of what happened versus what you expected.

We do not require you to use any specific format; the above details simply help us reproduce the issue faster.

7. Formal Complaints

If you believe MixOps has not adequately addressed an accessibility complaint, you may also contact relevant regulatory authorities, including:

• United States — the U.S. Department of Justice (www.ada.gov) for ADA Title III complaints;
• European Union — the national enforcement body for your member state under the European Accessibility Act;
• United Kingdom — the Equality and Human Rights Commission; and
• Canada — the Accessibility Commissioner under the Accessible Canada Act.

We would prefer to resolve issues directly. The contact at Section 6 is the fastest route to a fix.

8. What This Statement Does Not Cover

This statement covers the MixOps web application at mixops.io and its subdomains. It does not cover:

• Pro Tools, S6, S4, S1, S3, EuCon, Dolby Atmos Renderer, or other third-party software MixOps integrates with — those products have their own accessibility statements published by their respective vendors;
• Configuration files you produce using MixOps — the resulting XML or session files do not inherently carry accessibility metadata, and how they are consumed downstream is outside our control; and
• Customer-authored content — names, notes, and uploads written by other users of the Service.

9. Review Cadence

This statement is reviewed at least annually and after any material change to the platform's accessibility posture. The "Updated" date at the top of this page reflects the most recent substantive revision; cosmetic edits to wording do not trigger a date bump.

10. Contact Us

For accessibility questions or to report an issue: accessibility@mixops.io

For all other contact, see our Terms of Service.