Accessibility Statement

1.1 Covered. The public website at erianux.com, including product, documentation, store and legal pages; the checkout flow, to the extent it is rendered by the Company; and the emails the Company sends in the course of a transaction.

1.2 Partially covered. The members area and the affiliate and owner consoles, which are addressed specifically at clause 6.

1.3 Not covered. Third-party surfaces the Company does not build or control: the NinjaTrader 8 platform in which Erianux indicators run and whose interface, charting canvas and keyboard model belong to NinjaTrader; the checkout pages hosted by Stripe and PayPal; the Discord client; and any third-party marketplace listing. The Company will raise a reported barrier with the relevant vendor, but cannot remediate another company’s product and does not claim to.

2.1 Target. The Company builds toward the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, published by the W3C. Level AA is the level referenced by essentially every accessibility regime the Company’s markets impose, and WCAG 2.2 is chosen over 2.1 because it adds criteria — focus appearance, target size, dragging alternatives, accessible authentication — that matter on the kind of interfaces the Company builds.

2.2 Conformance claimed. Partial conformance, self-assessed. The Company has not commissioned a third-party audit and therefore does not claim certified or full conformance. A grade nobody checked is exactly the kind of claim this site refuses to make about its products, and accessibility is not an exception.

2.3 Relevant law, and where the Company sits in it. The Company sells into the United States, the United Kingdom, the European Union and Canada, and considers the following: Titles II and III of the Americans with Disabilities Act, under which U.S. courts have applied accessibility obligations to commercial websites, with WCAG AA used in practice as the benchmark; s.508 of the Rehabilitation Act, which applies to federal procurement and does not currently apply to the Company, which holds no federal contract; the Equality Act 2010 in the United Kingdom and its duty to make reasonable adjustments; the European Accessibility Act, Directive (EU) 2019/882, enforceable from 28 June 2025, whose e-commerce provisions reach non-EU businesses selling to EU consumers and whose presumption of conformity runs through the harmonised standard EN 301 549; and the Accessible Canada Act and provincial equivalents. The EAA exempts micro-enterprises providing services — fewer than ten employees and under €2 million in annual turnover or balance-sheet total — and the Company presently falls within that exemption. It designs to the standard regardless, because the exemption is a defence against enforcement and not a reason to exclude a user.

• 3.1 Works without JavaScript. The FAQ and every collapsible section on the site use the native HTML disclosure element. They expand and read correctly with scripts disabled, because a screen reader or a slow connection should not lose functionality that plain HTML already provides.
• 3.2 Keyboard navigable. Every link, button and form control on the public site can be reached and operated by keyboard alone, in a logical order, with a visible focus indicator. There are no keyboard traps, and no control that requires a pointer to operate.
• 3.3 Semantic structure. Headings, landmarks and lists are used for what they mean rather than for how they look, so a screen reader’s outline of a page matches what a sighted visitor sees as its sections.
• 3.4 Text alternatives. Product screenshots and diagrams carry alt text describing what they show rather than the filename, and decorative images are marked as decorative so they are skipped rather than announced.
• 3.5 Reduced motion respected. Scroll and entrance animations are skipped entirely for a visitor whose system is set to prefer reduced motion. Nothing on the site auto-plays with sound, and nothing flashes.
• 3.6 Text, contrast and zoom. Body text is real text rather than an image of text, so it responds to browser font settings; pages reflow at 400 per cent zoom without horizontal scrolling on a standard viewport; and colour is not used as the only means of conveying information.
• 3.7 Accessible authentication. Sign-in uses a one-time email link. There is no password to remember, no cognitive puzzle and no image-recognition test standing between a user and their account.
• 3.8 Forms and errors. Every input has a persistent visible label, not a placeholder standing in for one, and validation errors are described in text next to the field they concern.

4.1 Method. Testing is manual and performed by the Company: keyboard-only traversal of each template, inspection of the accessibility tree, contrast checks against the WCAG AA ratios of 4.5:1 for body text and 3:1 for large text and interface components, reflow at 400 per cent zoom, and verification that each page reads correctly with scripts disabled.

4.2 Automated checks. Automated tooling is used as a first pass. The Company does not treat a clean automated result as conformance: automated checks detect only a minority of real barriers, and the ones they miss — a meaningless link name, a focus order that makes no sense, an alt text that describes the wrong thing — are the ones that actually stop a user.

4.3 Assistive technology. Pages are checked against at least one screen reader and browser combination on the Company’s own platform. The Company does not have a test matrix covering every screen reader, browser and operating system in common use, and does not claim one.

4.4 When testing happens. Before a new template or flow is published, and on the annual review. A reported barrier is retested after the fix and the outcome recorded.

5.1 Native elements first. A button is a button, a link is a link, and a disclosure is the native disclosure element. The Company reaches for a custom control only where no native element exists, and then implements the keyboard and name-role-value expectations for it rather than approximating them with ARIA on a div.

5.2 No accessibility overlay. The Company does not install a third-party overlay, widget or plug-in that claims to make a site accessible. Overlays do not fix the underlying markup, are widely reported to interfere with the assistive technology a user already has configured, and would let the Company publish a claim it had not earned.

5.3 Procurement. Where the Company selects a supplier whose product a customer interacts with, accessibility is a selection factor, as recorded at clause 4.4 of the Sustainable Procurement Policy.

5.4 Documents. Policy and documentation PDFs are generated from structured HTML rather than scanned, so they carry a reading order and selectable text. A document that cannot be made accessible will be offered in an alternative format on request.

Stated specifically, because a statement that lists only successes is not a statement.

• 6.1 Members area and consoles. The members area and the affiliate and owner consoles are data-dense dashboards built for a narrower audience than the public site, and have not had the same accessibility pass as the pages you are reading. Dense tables and charts in those views are likely to present barriers to screen-reader and keyboard-only use. The Company will not claim otherwise, and will assist any affected user directly while the work is outstanding.
• 6.2 Charts and visual product output. An order-flow footprint or a chart drawn on the NinjaTrader canvas is inherently visual, and the platform’s rendering is outside the Company’s control. Where the Company documents such output it provides a textual description of what the chart shows; it cannot make the third-party canvas itself screen-reader accessible.
• 6.3 Video and screencasts. Where instructional video exists, captions and a transcript are provided where practicable. Any video published without them is a gap the Company acknowledges rather than describes as a future enhancement.
• 6.4 Third-party checkout. The payment pages presented by Stripe and PayPal are those vendors’ products. The Company selects processors that publish an accessibility position but does not control their markup.
• 6.5 No independent audit. No third-party audit, VPAT or Accessibility Conformance Report exists for the site. If an enterprise or public-sector buyer requires one, the Company will say so plainly rather than supply a self-completed document dressed as an independent assessment.

If a part of the site or a document is not usable with the technology you rely on, the Company will provide the same information or complete the same transaction another way: a plain-text or large-print version of a document, an email walkthrough in place of a console screen, a manual licence issue or account change performed on your behalf, or a telephone or video call at a time that suits you. This is offered as a matter of course and at no cost, and asking for it does not require an explanation of your disability.

8.1 How to report a barrier. Write to support@erianux.com with the page or screen, what you were trying to do, what happened, and — if you are able to say — the assistive technology, browser and operating system you were using. None of those details are required; a description of the problem is enough.

8.2 What the Company undertakes. To acknowledge a report within five business days; to give an assessment and a remediation plan, or an alternative means of access under clause 7, within ten business days; to fix what can be fixed; and to say honestly when something is a longer-term piece of work rather than a quick patch. Where the barrier lies in a third-party product, the Company will report it to that vendor and tell you it has done so.

8.3 Escalation. If the response is unsatisfactory, escalate to legal@erianux.com, where it is treated as a grievance under the Code of Conduct.

8.4 External routes. Nothing here limits your right to complain to a regulator or authority: the U.S. Department of Justice Civil Rights Division under the ADA, the Equality Advisory and Support Service in the United Kingdom, the market-surveillance authority of your EU member state under the European Accessibility Act, or the Accessibility Commissioner in Canada.

The Managing Member owns this statement and the remediation backlog behind it. It is reviewed at least annually and additionally on the publication of a new template or flow, a change to the members area or consoles, the engagement of a first employee in a development role, a material change to WCAG or EN 301 549, or the Company ceasing to fall within the EAA micro-enterprise exemption. Reports received, their outcomes and their remediation dates are retained under clause 15 of the Code of Conduct. Each review is logged whether or not this text changes.

The Company’s indicators and tools render inside a third-party platform, which constrains what the Company can control. Within that constraint, the following are design rules rather than aspirations.

• 10.1 Never colour alone. Where a tool signals a condition, the signal is carried by shape, position, weight or label as well as by colour. A user who cannot distinguish red from green must be able to read the same information from the same display.
• 10.2 Configurable colour. Every colour a tool draws is exposed as a setting, so a user with a colour-vision deficiency, a high-contrast requirement or a light-on-dark preference can set a palette that works for them rather than accepting a default chosen for a screenshot.
• 10.3 Scalable type and line weight. Font size, font family and line thickness in a tool’s own drawing are settings, not constants, so a user with low vision can enlarge what the tool draws without enlarging the whole platform.
• 10.4 No motion requirement. No tool requires a drag, a hover or a precise pointer gesture to read its output. Where a tool offers a drag interaction, the same result is reachable from a settings field.
• 10.5 Documentation parity. Anything a user can only learn by looking at a chart is also written down in the documentation in words, so that a user relying on a screen reader can configure and understand a tool without interpreting a picture of it.
• 10.6 What the Company cannot do. The platform’s own menus, dialogs, chart canvas, keyboard model and screen-reader behaviour belong to the platform vendor. The Company cannot make a third-party canvas announce its contents, and does not imply that its products make an inaccessible platform accessible.

11.1 Plain language. Product pages, documentation and these policies are written to be read once. Where a term of art is unavoidable — order flow, footprint, delta, imbalance — it is defined at first use rather than assumed.

11.2 Consistency. Navigation, labels and the position of recurring controls are consistent across the site, so that a user who has learned one page has learned the pattern.

11.3 No time limits. No page imposes a countdown, a session timeout that loses entered data, or a limited-time offer designed to force a decision. A sign-in link that expires can be reissued without limit.

11.4 No dark patterns. No pre-ticked consent, no hidden recurring charge, no obstacle to cancelling that does not equally apply to subscribing, and no interface that disguises the cost or the commitment. The route out of a subscription is as simple as the route in, and is available in writing to support@erianux.com if a user finds the console difficult.

11.5 Predictable behaviour. Nothing significant happens on focus or on hover. Actions happen when a user activates a control, and a destructive action asks for confirmation.

11.6 Error recovery. Where a form can be got wrong, the error message says what is wrong and what to do about it, and the entered data is preserved rather than cleared.

Self-assessment of the public website, not an audit. “Supported” means the Company has tested the criterion and believes the public site meets it; “partial” means it is met on the public site but not throughout the members area and consoles.