Cherry Audio Accessibility Conformance Report

WCAG Edition (Based on VPAT® Version 2.5Rev)

Name of Product/Version: Cherry Audio Voltage Modular 2 (v2.x, Windows and macOS; standalone application and VST/VST3/AU/AAX plugin)

Report Date: July 9, 2026

Product Description: A desktop virtual modular synthesizer application for Windows and macOS. Users build synthesizer patches by adding modules to virtual cabinets, connecting them with on-screen patch cables, and adjusting knobs, sliders, buttons, and jacks rendered in a custom graphical user interface. The product runs as a standalone application or as a plugin inside a host digital audio workstation (DAW).

Contact Information: support@cherryaudio.com

Notes: Voltage Modular is non-web desktop software. WCAG 2.x Success Criteria were applied to this product using the guidance in Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT). Criteria that address web-specific concepts (e.g., reflow of responsive web content, text spacing overrides) are marked Not Applicable where WCAG2ICT indicates they do not translate to closed desktop software. The product interface is custom-rendered (owner-drawn); except where noted, interface content is not exposed to platform accessibility APIs (Microsoft UI Automation on Windows; NSAccessibility on macOS).

Evaluation Methods Used

The accessibility of Voltage Modular was evaluated using a combination of manual inspection, keyboard-only operation testing, assistive technology testing, and platform accessibility API inspection.

Manual Testing
Evaluators performed keyboard-only operation tests (Tab, arrow keys, Enter, Escape, and documented application shortcuts) across the primary workflows: creating a patch, adding modules from the module browser, connecting patch cables, adjusting module controls, saving/loading presets, and signing in to a Cherry Audio account. Interface zoom testing was performed using the application’s built-in zoom controls. Color contrast of application chrome, menus, dialogs, and first-party module panels was spot-checked using the TPGi Color Contrast Analyzer.
Assistive Technology
Functional testing of the primary workflows was conducted using VoiceOver (macOS) and NVDA (Windows) against the standalone application.
Accessibility API Inspection
macOS Accessibility Inspector and Windows Accessibility Insights were used to examine what the application exposes to platform accessibility APIs (names, roles, values, states, and focus events).
Scope
Testing focused on the standalone application’s primary “patch-building journey”: account sign-in, module browsing and placement, cable patching, control adjustment, preset management, and the in-application store. Plugin operation inside DAW hosts inherits the same user interface; host-specific behavior was not separately evaluated. Third-party modules sold through the Cherry Audio module store render their own panel graphics and were not individually evaluated.

Applicable Standards/Guidelines

This report covers the degree of conformance for the following accessibility standard/guidelines:

Standard/Guideline Included In Report
Web Content Accessibility Guidelines 2.0 Level A (Yes), Level AA (Yes), Level AAA (No)
Web Content Accessibility Guidelines 2.1 Level A (Yes), Level AA (Yes), Level AAA (No)
Web Content Accessibility Guidelines 2.2 Level A (Yes), Level AA (Yes), Level AAA (No)

Terms

The terms used in the Conformance Level information are defined as follows:

Supports
The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
Partially Supports
Some functionality of the product does not meet the criterion.
Does Not Support
The majority of product functionality does not meet the criterion.
Not Applicable
The criterion is not relevant to the product.

WCAG 2.x Report

Note: When reporting on conformance with the WCAG 2.x Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.2 Conformance Requirements, as applied to non-web software per WCAG2ICT.

Table 1: Success Criteria, Level A

Criteria Conformance Level Remarks and Explanations
1.1.1 Non-text Content (Level A) Does Not Support Module panels, knobs, sliders, jacks, patch cables, and meters are rendered as custom graphics and do not provide programmatic text alternatives. Control names and values are shown visually (panel legends and pop-up value readouts) but are not exposed to assistive technology. Menus and standard dialogs provided by the platform are the exception and carry text labels.
1.2.1 Audio-only and Video-only (Prerecorded) (Level A) Not Applicable The application contains no prerecorded audio-only or video-only informational content. Audio produced by the synthesizer is user-generated musical output, not prerecorded media.
1.2.2 Captions (Prerecorded) (Level A) Not Applicable No prerecorded video content with audio is present in the application.
1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) Not Applicable No prerecorded video content is present in the application.
1.3.1 Info and Relationships (Level A) Does Not Support The structure of the interface (cabinets, modules, control groupings, the module browser hierarchy, and preset lists) is conveyed visually through the custom-rendered UI and is not programmatically determinable. Relationships such as which jack a cable connects to, or which label belongs to which knob, are available only visually.
1.3.2 Meaningful Sequence (Level A) Does Not Support Because interface content is not exposed to accessibility APIs, no programmatically determinable reading sequence exists for the main patch-building interface. Native menus and file dialogs follow platform conventions.
1.3.3 Sensory Characteristics (Level A) Partially Supports Controls carry visible text legends and are identified by name in documentation. However, the patching workflow is inherently spatial, and some in-application guidance refers to visual position and color (e.g., cable colors, jack locations) without alternative descriptions.
1.4.1 Use of Color (Level A) Partially Supports Patch cable colors are user-assignable and serve as an organizational aid rather than the sole carrier of information; connections can also be identified by clicking a jack to inspect its connections, and animated signal-flow indicators provide a non-color cue for active connections. Some status indications (e.g., LED-style state indicators on module panels) rely on color alone.
1.4.2 Audio Control (Level A) Supports The application does not play audio automatically. Sound is produced only in response to user action (playing notes, enabling a sequencer, or DAW transport in plugin use), and a master output level control and audio panic function are always available.
2.1.1 Keyboard (Level A) Does Not Support Core workflows — connecting patch cables, adjusting knobs and sliders, and repositioning modules — require a pointing device and cannot be performed from the keyboard. Keyboard access exists for menu commands, documented shortcuts (save, undo/redo, zoom), the QWERTY musical typing keyboard for playing notes, and text entry in search and sign-in fields.
2.1.2 No Keyboard Trap (Level A) Supports In the interface areas that accept keyboard focus (menus, dialogs, text fields), focus can always be moved away using standard keys. No keyboard traps were identified.
2.1.4 Character Key Shortcuts (Level A 2.1 and 2.2) Supports Single-character keys are used only by the QWERTY musical typing feature, which is active only while that mode is explicitly enabled by the user and can be turned off at any time. Application shortcuts otherwise use modifier keys.
2.2.1 Timing Adjustable (Level A) Not Applicable No time limits are imposed on any user interaction.
2.2.2 Pause, Stop, Hide (Level A) Supports Moving content is limited to user-initiated synthesis feedback (meters, scopes, signal-flow indicators on cables). Cable animation and cable visibility/transparency can be adjusted or disabled in settings, and all motion stops when the user stops playback.
2.3.1 Three Flashes or Below Threshold (Level A) Supports LED-style indicators on module panels may blink at rates driven by user-configured modulation, but these indicators are small and fall below the general flash threshold area. No general flashing content is present.
2.4.1 Bypass Blocks (Level A) Not Applicable Per WCAG2ICT, this criterion applies to software with repeated blocks of content across multiple “pages.” The application presents a single primary workspace and does not contain repeated navigation blocks in that sense.
2.4.2 Page Titled (Level A) Supports The application window title identifies the product and the currently loaded patch name, and updates when the patch changes. Dialogs carry descriptive titles.
2.4.3 Focus Order (Level A) Partially Supports Keyboard focus applies only to menus, dialogs, and text fields, where order follows platform conventions and the visual layout. The main patch-building interface does not participate in keyboard focus at all (see 2.1.1).
2.4.4 Link Purpose (In Context) (Level A) Partially Supports The few link-style controls (e.g., store, documentation, and account links) have descriptive visible text, but their purpose is not programmatically exposed to assistive technology.
2.5.1 Pointer Gestures (Level A 2.1 and 2.2) Supports All pointer operation uses single-pointer interaction (click, double-click, drag, and scroll wheel). No multipoint or path-based gestures are required; cable dragging depends only on start and end points, not a specific path.
2.5.2 Pointer Cancellation (Level A 2.1 and 2.2) Supports Click actions complete on the up-event. Drag operations (cables, module repositioning, knob adjustment) can be aborted before completion — dropping a cable away from a jack cancels the connection, and undo is available for all patch edits.
2.5.3 Label in Name (Level A 2.1 and 2.2) Does Not Support Controls in the custom-rendered interface have visible text legends but no programmatic accessible names, so the accessible name cannot contain the visible label.
2.5.4 Motion Actuation (Level A 2.1 and 2.2) Not Applicable No motion-based interactions are implemented.
3.1.1 Language of Page (Level A) Partially Supports The application’s human language is English and native menus/dialogs inherit platform language identification. Text within the custom-rendered interface is not programmatically exposed, so no language attribute is available to assistive technology for that content.
3.2.1 On Focus (Level A) Supports No element triggers a change of context on receiving focus.
3.2.2 On Input (Level A) Supports Changing a setting or control value does not cause an unexpected change of context. Module browser search filters results as the user types, which is the expected and announced behavior of a search field.
3.2.6 Consistent Help (Level A 2.2 only) Supports Access to help (user guide and support) is available in a consistent location in the application menus on every screen.
3.3.1 Error Identification (Level A) Partially Supports Errors in account sign-in and store transactions are identified with visible text messages describing the problem. These messages are visual only and are not programmatically associated with the relevant fields or announced to assistive technology.
3.3.2 Labels or Instructions (Level A) Partially Supports Text input fields (sign-in, search, preset naming) have visible labels or placeholder prompts, and module controls carry visible panel legends. Labels are not programmatically associated with their controls.
3.3.7 Redundant Entry (Level A 2.2 only) Supports Account credentials are remembered between sessions, and no multi-step process requires re-entry of previously provided information.
4.1.1 Parsing (Level A)
WCAG 2.0 and 2.1 – Always answer ‘Supports’
WCAG 2.2 (obsolete and removed) – Does not apply
Supports For WCAG 2.0 and 2.1, the September 2023 errata update indicates this criterion is always supported. See the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata.
4.1.2 Name, Role, Value (Level A) Does Not Support Controls in the custom-rendered interface (knobs, sliders, buttons, jacks, drop-downs, the module browser, and preset lists) do not expose name, role, value, or state to platform accessibility APIs (UI Automation on Windows; NSAccessibility on macOS). Assistive technologies perceive the main interface as a single undifferentiated surface. Native menus and standard file dialogs are the exception and are correctly exposed by the platform.

Table 2: Success Criteria, Level AA

Criteria Conformance Level Remarks and Explanations
1.2.4 Captions (Live) (Level AA) Not Applicable No live audio or video media content is present in the application.
1.2.5 Audio Description (Prerecorded) (Level AA) Not Applicable No prerecorded video content is present in the application.
1.3.4 Orientation (Level AA 2.1 and 2.2) Not Applicable The product is desktop software; display orientation is controlled by the operating system, not restricted by the application.
1.3.5 Identify Input Purpose (Level AA 2.1 and 2.2) Does Not Support The account sign-in fields collect information about the user (email address, password) but are custom-rendered and do not programmatically expose their input purpose.
1.4.3 Contrast (Minimum) (Level AA) Partially Supports Application chrome, menus, and dialogs meet the minimum contrast ratios. Module panel graphics vary by design: most first-party panel legends meet 4.5:1, but some panel styles use low-contrast legend text against dark or textured backgrounds, and third-party module panels are outside Cherry Audio’s control.
1.4.4 Resize text (Level AA) Supports The application provides built-in interface zoom that scales all interface content, including text, to at least 200% without loss of content or functionality. The window is freely resizable.
1.4.5 Images of Text (Level AA) Partially Supports Module panel legends are rendered as part of the panel graphics. This presentation is essential to the product’s hardware-emulation design, and the built-in zoom scales legends cleanly, but text is not independently customizable.
1.4.10 Reflow (Level AA 2.1 and 2.2) Not Applicable Per WCAG2ICT, reflow applies to content viewports that support reflowing. The modular patching workspace is a spatial canvas; two-dimensional layout is essential to its operation. Built-in zoom with scrolling is provided.
1.4.11 Non-text Contrast (Level AA 2.1 and 2.2) Partially Supports Primary interface components (buttons, jacks, cable connectors) generally meet 3:1 contrast against adjacent colors. Some control boundaries and state indicators on darker module panel designs fall below 3:1, and third-party module panels vary.
1.4.12 Text Spacing (Level AA 2.1 and 2.2) Not Applicable Per WCAG2ICT, this criterion applies where the technology supports user overrides of text style properties. The application’s rendered interface is closed to user text-style overrides.
1.4.13 Content on Hover or Focus (Level AA 2.1 and 2.2) Partially Supports Hover tooltips and pop-up value readouts are dismissed by moving the pointer and do not obscure the control being adjusted. Because they are pointer-driven only, keyboard-triggered equivalents do not exist (see 2.1.1).
2.4.5 Multiple Ways (Level AA) Supports Within the application, modules and presets can be located multiple ways: browsing by category, text search, favorites, and recently used lists.
2.4.6 Headings and Labels (Level AA) Partially Supports Visible labels and section headings (module browser categories, settings sections, panel legends) are descriptive. They are not programmatically exposed as headings or labels.
2.4.7 Focus Visible (Level AA) Partially Supports Menus, dialogs, and text fields show platform-standard focus indication. The main patch-building interface does not support keyboard focus, so no focus indicator exists there (see 2.1.1).
2.4.11 Focus Not Obscured (Minimum) (Level AA 2.2 only) Supports In the interface areas that accept keyboard focus (menus, dialogs, text fields), the focused element is never obscured by other content.
2.5.7 Dragging Movements (Level AA 2.2 only) Partially Supports Patch cables can be connected without dragging by Ctrl-clicking jacks, and knob and slider values can be adjusted with the scroll wheel without dragging. Repositioning modules requires a drag movement with no single-pointer non-drag alternative.
2.5.8 Target Size (Minimum) (Level AA 2.2 only) Partially Supports At default zoom, some targets (jacks, small buttons, and trim controls on dense module panels) measure below the 24×24 pixel minimum. The built-in interface zoom allows users to enlarge all targets well beyond the minimum.
3.1.2 Language of Parts (Level AA) Supports All interface content is in English; no passages in other languages are present.
3.2.3 Consistent Navigation (Level AA) Supports Menus, toolbars, the module browser, and transport controls appear in the same relative order throughout the application.
3.2.4 Consistent Identification (Level AA) Supports Components with the same functionality (save, undo, zoom, favorites, jack and cable interactions) are identified and behave consistently throughout the application.
3.3.3 Error Suggestion (Level AA) Partially Supports Sign-in and store errors include visible text suggesting the correction (e.g., incorrect password). Suggestions are visual only and are not announced to assistive technology.
3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) Supports In-application store purchases present a review-and-confirm step before completion. Patch edits are protected by undo, and closing with unsaved changes prompts for confirmation.
3.3.8 Accessible Authentication (Minimum) (Level AA 2.2 only) Partially Supports Account sign-in uses email and password with no CAPTCHA or cognitive function test, and credentials are remembered between sessions. Paste support into the custom-rendered password field requires verification to confirm password managers are fully usable.
4.1.3 Status Messages (Level AA 2.1 and 2.2) Does Not Support Status messages (save confirmations, store transaction results, sign-in status, CPU/voice indicators) are presented visually within the custom-rendered interface and are not exposed to assistive technology as status messages.

Legal Disclaimer

This document is provided for informational purposes only. Cherry Audio makes no warranties, express or implied, regarding the accuracy or completeness of the information contained herein. The accessibility conformance levels reported are based on evaluation methods described in this document and may change as the product is updated. For questions or to report accessibility issues, contact support@cherryaudio.com.

© 2026 Cherry Audio. Based on VPAT® Version 2.5Rev by the Information Technology Industry Council (ITI).