Accessibility Statement

This statement applies to the CutOps website and the CutOps web application, including:

• public marketing pages and documentation;
• authentication, profile, billing, and contact flows;
• the browser-based optimizer workspace and results views; and
• legal and support pages, including privacy, terms, and accessibility content.

Some areas currently provide a stronger accessibility experience than others. In particular, highly visual planning workflows and dense operational tables may require further refinement.

Based on the current implementation, CutOps already includes a number of accessibility-supporting measures across the site and app.

• Skip navigation: a global “Skip to main content” link is present at the application root.
• Semantic navigation and landmarks: the site and workspace use labeled navigation regions, structured headings, and consistent page sections.
• Keyboard-visible focus treatment: interactive controls use visible focus-visible states across buttons, fields, links, tabs, checkboxes, and other primitives.
• Dialog labeling: modal components are built with labeled titles, descriptions, close controls, and overlay behavior.
• Status and progress semantics: the UI includes progress bar semantics, live status patterns for notifications, and alert/status banners for key feedback.
• Form labeling: core forms such as contact flows and major product inputs include labels or explicit accessible names.
• Responsive support: layouts are designed to adapt across desktop and smaller screens, including mobile navigation patterns.
• Reduced motion support: global reduced-motion rules are applied when the user requests less motion.
• Readable presentation: the interface uses a single, stable light theme with explicit contrast, spacing, and interaction states.

Our aim is to move toward alignment with recognized accessibility best practices, including the principles of the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA where reasonably applicable to the product.

We do not currently claim full conformance with WCAG 2.2 Level AA. Instead, we use accessibility principles to guide product decisions, prioritize improvements, and reduce barriers over time.

CutOps includes advanced, data-dense, and highly visual workflows. Some parts of the product may still present difficulty for keyboard-only users, screen reader users, or users who need a simpler interaction model.

• the optimizer workspace includes large editable tables with many repeated controls and state changes;
• visual layout and sheet-rendering views may not communicate every planning detail equally well through non-visual output alone;
• some operational flows rely on complex UI state, dense summaries, or side-by-side comparison patterns that may need further refinement; and
• parts of the experience that depend on third-party services or browser behavior may not always provide the same level of accessibility support as first-party content.

Accessibility improvements in CutOps are driven through product iteration, design review, implementation changes, and focused testing as features are added or revised.

• review of semantic HTML, heading structure, and navigation landmarks;
• improvements to accessible names, labels, and helper text;
• focus on feedback surfaces such as dialogs, notices, toasts, and loaders;
• attention to contrast, readability, and interaction states; and
• ongoing cleanup of dense or repetitive interface patterns.

Some parts of CutOps rely on third-party libraries, browser APIs, analytics tooling, infrastructure services, or payment flows. We aim to choose and configure these responsibly, but we cannot guarantee the accessibility of third-party elements that are outside our direct control.

This may include, for example, external payment interfaces, browser-native controls, or third-party UI primitives and platform behaviors.

If you encounter an accessibility barrier, need help completing a workflow, or want to request an accessible alternative for specific content, please contact us with as much detail as possible.

Helpful details include the page or feature involved, the device and browser you were using, any assistive technology involved, and what you were trying to accomplish.

We aim to respond to accessibility-related contacts within 30 days. If the issue requires more time to investigate or resolve, we will acknowledge your message and keep you informed of progress.

Accessibility contact: Accessibility contact form