POSX Legal · United States
Accessibility Statement
POSX's commitment to accessible design, the standard we build to, what is not yet conformant, and how to tell us about a barrier.
On this page
Users in the United States and in every market where POSX US Inc. is named as the app publisher
Laws of the State of Delaware
1. Our commitment
1.1 POSX US Inc. is committed to making the POSX mobile application and the POSX websites usable by everyone, including people who use screen readers, magnification, switch access, voice control, captions or other assistive technology.
1.2 We treat accessibility as a product requirement rather than a remediation exercise: it is part of our design system, our definition of done, and our release checks. Where we fall short, we say so in section 5 and give a date by which we intend to fix it.
1.3 This statement applies to the POSX mobile application for iOS and Android, and to the POSX websites at posx.io. It was prepared on 1 October 2026 and is reviewed at least annually and after any significant redesign.
2. The standard we build to
2.1 POSX builds to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, applied to native mobile interfaces as well as web. WCAG 2.2 is the current W3C Recommendation and is also published as ISO/IEC 40500:2025. Level AA is the level required or expected by every regime that applies to us.
| Where | What applies | How we meet it |
|---|---|---|
| United States | Title III of the Americans with Disabilities Act applies to the goods and services of a place of public accommodation. There is no federal regulation prescribing a technical standard for a private company's app, but WCAG Level AA is the benchmark used in settlements and enforcement practice. | We build to WCAG 2.2 AA, which meets or exceeds the WCAG 2.1 AA benchmark most commonly applied. |
| European Union | The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 to services including e-commerce and consumer banking services. The reference standard is EN 301 549; no version of it has yet been cited in the Official Journal as harmonised under the Act, so conformity is demonstrated directly against Annex I of the Directive rather than by presumption. | We build to WCAG 2.2 AA and map our conformance to Annex I. POSX does not rely on the microenterprise exemption. |
| United Kingdom | The Equality Act 2010 requires reasonable adjustments in the provision of services. | WCAG 2.2 AA, plus the feedback and alternative-format route in section 7. |
| Hong Kong | The Disability Discrimination Ordinance (Cap. 487) prohibits discrimination in the provision of goods, services and facilities. It sets no technical standard; the recognised local benchmark is WCAG 2.0 Level AA, applied through the Digital Accessibility Recognition Scheme organised by the Hong Kong Internet Registration Corporation with the Digital Policy Office as co-organiser. | WCAG 2.2 AA, which is a strict superset of WCAG 2.0 AA. |
3. Conformance status
3.1 Partially conformant with WCAG 2.2 Level AA. Partially conformant means most of the product meets the standard but some parts do not; those parts are listed in section 5.
3.2 Partially conformant is an honest description of where we are: we have evaluated the product against the standard ourselves and have not yet had that evaluation independently audited. Section 4 says how we assessed it and section 5 says what we know is outstanding. We would rather tell you that than claim a conformance we have not tested.
4. How we assess
| Method | Detail |
|---|---|
| Self-evaluation | Component-level checks against WCAG 2.2 AA during design and code review, using the POSX design system's accessible colour, spacing and target-size tokens. |
| Automated testing | axe DevTools, the Android Accessibility Scanner and the Xcode Accessibility Inspector run in the build pipeline. Automated tools catch roughly a third of issues; they do not replace manual testing. |
| Manual testing | Keyboard-only and switch navigation; VoiceOver on iOS and TalkBack on Android; Dynamic Type and font scaling to 200%; high-contrast and dark modes; reduced-motion settings; screen magnification; voice control. |
| Testing with disabled users | Not yet carried out. We will include people who use assistive technology in usability testing from our first post-launch research round, and at least annually after that. |
| Independent audit | Not yet commissioned. We will commission an independent WCAG 2.2 AA audit within twelve months of launch and will publish the result and any barriers it identifies here. |
5. What we have done, and what is not yet accessible
5.1 Measures in place
— Every interactive element has an accessible name, role and state, and supports the platform's native accessibility APIs.
— Text and meaningful non-text elements meet the WCAG 2.2 AA contrast ratios of 4.5:1 for body text and 3:1 for large text and user-interface components; the POSX colour tokens are chosen to satisfy this in both light and dark themes.
— Interactive targets meet the WCAG 2.2 minimum target size of 24 by 24 CSS pixels, and we design to 44 by 44 points on iOS and 48 by 48 density-independent pixels on Android.
— The app supports Dynamic Type and system font scaling without loss of content or function.
— Colour is never the only means of conveying information — balance changes, transaction states and errors carry a text label or an icon as well.
— Focus order is logical, focus is always visible, and no keyboard or switch trap exists.
— Motion and animation respect the operating system's reduce-motion setting.
— Form fields have persistent visible labels, programmatically associated error messages, and instructions that do not rely on placeholder text alone.
— Time limits in verification and payment flows can be extended, and we warn before a session expires.
— Media, where used, carries captions and a transcript.
5.2 Known limitations
We publish these deliberately. An honest list of gaps with owners and dates is what an auditor, a regulator and a user in difficulty each want to see.
| Area | What we know today | When this changes |
|---|---|---|
| Whole product | Our own evaluation has not found a barrier that stops someone completing a core task — registering, verifying identity, seeing a balance, or redeeming a reward. That is a self-assessment by the team that built the product, not an independent audit, and self-assessments miss things. | The independent WCAG 2.2 AA audit described in section 4 |
| Identity verification | Capturing an identity document and a selfie depends on camera framing, which is harder to do without sight. We provide audio and haptic feedback during capture, and a person can complete verification with our support team instead. | Reviewed in the first audit; the manual route is available now |
| Charts and data views | Where we show spending or reward history as a chart, the same information is available as a table and is read out by screen readers. | Reviewed in the first audit |
5.2.1 When the independent audit reports, we will replace this table with what it found, including anything we have to fix and the date by which we intend to fix it. Publishing an empty limitations table would say more about our testing than about our product.
5.2.2 Where a barrier prevents you from completing something, contact us at accessibility@posx.io and we will help you complete it another way while we fix the underlying problem.
6. Compatibility
6.1 The Application is designed to work with the current and previous major versions of iOS and Android and their built-in assistive technologies — VoiceOver, Voice Control, Switch Control, Zoom and Dynamic Type on iOS; TalkBack, Switch Access, Voice Access, Magnification and font scaling on Android. The websites are designed to work with current versions of Chrome, Safari, Edge and Firefox together with current versions of JAWS, NVDA and VoiceOver.
6.2 Support may be limited on operating-system versions older than iOS 16 and Android 10 (API level 29), because older platforms lack the accessibility APIs the product relies on.
7. Feedback, alternative formats and escalation
7.1 Tell us about any barrier you meet. We want to hear about it, and your report is the fastest route to a fix.
| Route | Detail |
|---|---|
| accessibility@posx.io | |
| In the app | Settings → Help → Report an accessibility issue |
| Post | POSX US Inc., 16192 Coastal Highway, Lewes, Delaware 19958, United States (registered office); correspondence to 340 Madison Avenue, Suite 6D, New York, NY 10173, United States |
| Acknowledgement | Within 2 business days |
| Substantive response | Within 10 business days, with either a fix, a workaround, or a date |
| Alternative formats | We will provide any of these documents in large print, plain text, or another accessible format on request, at no charge |
7.2 If you are not satisfied with our response, ask for it to be escalated to the POSX Legal team, legal@posx.io, marked "Escalation". You may also complain to a regulator:
— United States — the Civil Rights Division of the U.S. Department of Justice, or your state's civil rights agency.
— European Union — the market surveillance or enforcement authority designated under the European Accessibility Act in your member state.
— United Kingdom — the Equality Advisory and Support Service.
— Hong Kong — the Equal Opportunities Commission.
8. What we publish under the European Accessibility Act
8.1 For users in the European Union, the Act requires a service provider to publish a general description of the service in accessible formats, explaining how it meets the accessibility requirements in Annex I of the Directive. Sections 2, 5 and 6 of this statement, together with https://posx.io/accessibility, are that description.
8.2 Where we become aware that the service does not conform, we will take the corrective measures needed to bring it into conformity and, where the non-conformity is material, inform the market surveillance authority of the member state concerned, giving details of the non-conformity and of the corrective measures taken.
8.3 We keep the information supporting this statement for at least five years after the service was last provided, and we make it available to a market surveillance authority on request.
9. Technical specification
9.1 Accessibility of the POSX products relies on the following technologies working with your browser or operating system and any assistive technology you use: HTML, WAI-ARIA, CSS and JavaScript on the web; SwiftUI and UIKit accessibility APIs on iOS; and the Android accessibility framework, including content descriptions, semantics and the accessibility node tree, on Android.
10. How we keep this current
10.1 This statement is reviewed at least annually, on completion of each independent audit, and after any significant redesign. Accessibility defects are logged in the same backlog as other defects, are triaged with a severity that reflects the barrier they create, and regressions are treated as release-blocking where they affect a core flow — registration, verification, viewing a balance, or redeeming a reward.
10.2 Version, date and owner are recorded on the first page of this document.
Questions about this document
Contact POSX Legal
We can explain how this document applies to the POSX service.