Accessibility Statement

Orno’s goal is to deliver a platform that anyone can use, regardless of ability, assistive technology, network speed, or device. We are working toward substantial conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. We are not claiming that we have already achieved full conformance, because the platform is actively evolving, some parts of it (especially staff and administrative tools, and embedded third-party content) lag behind our public-facing surfaces, and accessibility is a moving target. What we are committing to is (a) applying accessibility standards to all new work, (b) progressively remediating existing issues on a prioritized schedule, (c) responding quickly when you tell us something does not work, and (d) being transparent about what is and is not done.

We design with the following legal and standards frameworks in mind. This is not legal advice, and the applicability of any given framework depends on your jurisdiction and use case, but these are the reference points we use when we evaluate whether a feature meets the bar:

• Americans with Disabilities Act, Title III (42 U.S.C. §§ 12181 et seq.), as it applies to places of public accommodation, including websites and applications offered to the general public;
• Section 508 of the Rehabilitation Act (29 U.S.C. § 794d) and its Revised 508 Standards (36 C.F.R. Part 1194), which harmonize U.S. federal accessibility requirements with WCAG 2.0 Level AA (and are in the process of being further updated in line with WCAG 2.x);
• EN 301 549, the European harmonized accessibility standard for ICT products and services, which incorporates WCAG by reference and adds requirements for non-web software, documents, and hardware;
• EU Web Accessibility Directive (Directive (EU) 2016/2102), governing public-sector bodies’ websites and mobile applications within EU Member States;
• European Accessibility Act (Directive (EU) 2019/882), which extends accessibility obligations to a broader range of consumer-facing products and services;
• Accessibility for Ontarians with Disabilities Act (AODA) in Ontario, Canada, and Accessible Canada Act at the federal level;
• UK Equality Act 2010, to the extent it applies to our UK-facing services.

Where these frameworks impose conflicting or overlapping requirements, we apply the more protective standard.

Our current design target is WCAG 2.1 Level AA. We evaluate new and existing pages against every Level AA success criterion and track known gaps in an internal remediation backlog. We are tracking WCAG 2.2 as an aspirational target and will adopt specific 2.2 criteria as we build or redesign affected components (for example, focus-appearance and accessible-authentication requirements are being applied to new work now, even though we are not claiming full WCAG 2.2 conformance today).

This statement covers the public-facing web surfaces operated by Orno, including:

• The marketing and informational site at orno.io and its subdomains;
• The creator and partner portal;
• The order-tracking surfaces used by partners and brands;
• Legal Center and policy pages;
• Public-facing application flows such as sign-up, onboarding, and contact.

Across the surfaces in scope, we have implemented (or are in the process of implementing) the following accessibility features. None of these is a substitute for manual testing, and we know there are still rough edges; we include the list so you have a concrete picture of what to expect.

We think you deserve an honest picture of where we fall short today. We are actively remediating each of the following, but we want to be upfront rather than claim a level of conformance we do not have:

• Third-party embeds. Some social-media embeds (for example, platform preview iframes and analytics widgets) do not consistently meet WCAG 2.1 AA. We evaluate vendors on accessibility before adoption where possible, but cannot remediate third-party code directly;
• Legacy marketing pages. A small number of legacy pages predate this statement and are being reviewed and rewritten. Headings, alt text, and color contrast on those pages may not yet meet our current standard;
• Video captions and transcripts. New video content is published with captions. For some older video content, captions, transcripts, or audio description may be missing or lag behind upload. If you encounter a video without captions, please contact us (Section 10) and we will prioritize it;
• Administrative & staff interfaces. Internal tools are accessibility-aware but not held to the same external conformance target as user-facing surfaces. If you use a staff tool and need an accommodation, please contact us so we can provide one;
• Complex data visualizations. Some charts and dashboards may not yet expose fully accessible data tables or summaries. Textual equivalents are being added progressively;
• PDF and document attachments. Not every downloadable document is fully tagged. We will provide an alternative format on request (Section 9).

We test with the following assistive technologies across the latest two major versions, paired with the browsers in which they are commonly used:

Other assistive technologies (Dragon NaturallySpeaking, ZoomText, Narrator, switch access, eye-tracking input) should work through standard input APIs, but receive less frequent coverage. If you use one of these technologies and something does not work, please let us know so we can prioritize it.

Our accessibility work uses a combination of automated and manual testing. Automated tools catch a meaningful fraction of issues but miss most context-dependent problems, so they are only the starting point.

• Automated scans. Tools such as axe-core, Lighthouse accessibility audits, and Pa11y are run during development and on deployments. Findings are triaged and either fixed or documented in the remediation backlog;
• Manual keyboard testing. Every user-facing flow is walked without a mouse to confirm focus order, focus visibility, and operability;
• Screen-reader testing. Key flows are tested with at least one desktop screen reader (JAWS or NVDA) and one mobile screen reader (VoiceOver or TalkBack);
• Contrast checks. Color tokens and text/background combinations are checked with contrast-ratio tools before being promoted to the design system;
• Zoom and reflow checks. Layouts are validated at 200% browser zoom and at the 320-CSS-pixel width requirement;
• Third-party audits (aspirational). We intend to commission independent third-party accessibility audits on a periodic basis and will publish the date of the most recent audit in this statement when one has been completed.

If a page, document, video, or feature is not accessible to you, or you need the information in a different format (large print, plain-text, tagged PDF, a transcript, an audio description, a different file type, or a human-assisted walkthrough), email accessibility@orno.io with:

• The URL or name of the page, document, or feature;
• A brief description of the barrier you encountered;
• The format you would prefer (if known);
• The assistive technology, browser, and operating system you are using (helpful, but not required);
• A way we can reply to you.

We will acknowledge your request within two (2) business days and, for most requests, provide the alternative format or accommodation within ten (10) business days. Some complex requests (for example, high-quality human captions on a long video) may take longer; if so, we will tell you what to expect and keep you informed.

If something does not work for you, please tell us. Accessibility reports are the fastest way we learn about real-world barriers, and we treat them as high-priority issues. You can report a problem through any of the following channels:

Please include, if you can: the URL or screen where the issue occurred; a short description of what happened and what you expected; and the assistive technology, browser, and operating system you were using. If you would prefer not to share any of that, we will still do our best to investigate with what you are comfortable providing.

If you have reported an accessibility issue and are not satisfied with the response, you can escalate in the following ways:

• Internal escalation: email legal@orno.io with the original correspondence attached; the legal team will review and respond;
• United States — U.S. Department of Justice, Civil Rights Division, Disability Rights Section, which enforces Title III of the ADA. Information on how to file a complaint is available at www.ada.gov;
• United States — State civil-rights agencies (for example, the Florida Commission on Human Relations) for state-law accessibility complaints;
• European Union — national supervisory body designated under the Web Accessibility Directive or EAA in your Member State;
• United Kingdom — Equality Advisory and Support Service (EASS), for queries and complaints under the Equality Act 2010.

Filing an external complaint does not waive any contractual rights you may have, and Orno will not retaliate against any User who pursues a good-faith accessibility complaint.

Accessibility is not a one-time project. Every release is an opportunity to either improve or regress, and we treat feedback from disabled Users as an authoritative source of bugs — in many cases more informative than automated scans. Our commitments to continuous improvement are:

• Accessibility requirements are included in new-feature specifications, not bolted on after release;
• Design-system components are audited once and then reused, so downstream teams inherit accessible defaults;
• Regressions identified by automated scans on each deployment block the promotion of the build until resolved or consciously risk-accepted;
• Accessibility training is provided to new engineers, designers, and product managers during onboarding, and is refreshed when standards evolve (for example, adoption of WCAG 2.2 criteria);
• This statement is reviewed annually and republished with the date of the most recent review.

This Accessibility Statement was last reviewed on January 1, 2026. We commit to reviewing this statement at least once every twelve (12) months, and whenever a material change to the platform would affect the accuracy of this statement (for example, a significant redesign, a newly-adopted conformance target, or the completion of a third-party audit). The next scheduled review is January 2027.

For accessibility reports, alternative-format requests, and accommodation inquiries, please contact:

Thank you for taking the time to read this statement and for helping us improve. If anything in this document is itself inaccessible to you, that is exactly the kind of thing we want to know about — please reach out.