Accessibility support for the public site and product workflow.

CompounderOS aims to provide an accessible public website and web client for people with disabilities, including users who rely on keyboard navigation, screen readers, magnification, higher contrast, reduced motion, or other assistive technologies.

This statement covers the public website, authentication flows, account surfaces, research workflow, company pages, and digital product surfaces controlled by CompounderOS.

The target standard for the website and web client is Israeli Standard 5568 for internet content accessibility, based on WCAG at level AA, subject to the requirements and exceptions that apply under Israeli law.

The accessibility icon provides optional display adjustments. It does not replace the need for the underlying product to support semantic structure, keyboard operation, labels, focus management, and assistive technologies by default.

• Keyboard-accessible skip link to move toward the main content area.
• Persistent accessibility controls for larger text, high contrast, underlined links, and reduced motion.
• Theme-aware focus styles for links, buttons, forms, menus, and interactive controls.
• Operating-system reduced-motion preference support, with an additional in-product reduced-motion option.
• Semantic headings, landmarks, labels, and ARIA attributes where implemented in the controlled product UI.
• Accessibility statement available from the global accessibility control and legal links.

Some third-party services, embedded payment tools, market-data assets, generated documents, older exports, or content not produced directly by CompounderOS may require additional remediation or an accessible alternative.

Financial charts, tables, exported reports, and AI-assisted research output should remain reviewable through text or table equivalents where they carry decision-relevant information.

If you encounter an accessibility barrier, need an accessible alternative, or want to report a problem, contact accessibility@compounderos.com. Include the page URL, a short description of the issue, your browser or assistive technology if relevant, and the best way to reply.

Accessibility requests should be handled as product trust issues. The service owner should keep this contact address current before any production launch or commercial use.

Accessibility should be checked after meaningful UI changes, new workflow surfaces, new document exports, and changes to authentication, payment, dashboard, company-page, or research-output flows.

Automated scans are useful for catching regressions, but manual keyboard and screen-reader checks are still required for a defensible accessibility review.