Why this document exists. The European Accessibility Act (Directive (EU) 2019/882) has been enforceable since 28 June 2025. For B2B software sold into or through the EU, and increasingly for public-sector and large-enterprise procurement elsewhere, VPAT-shaped evidence is a gate on the deal, not a virtue. This statement is written to be read by a procurement reviewer.
Honesty rule (Comiine truth-in-labelling law). This statement claims only what has been verified, names the method, and lists what has not been tested. "Partially supports" is the correct and deliberate claim for a product that has not yet completed assistive-technology testing with users. Do not upgrade this claim without the evidence in §5 being closed.
1 · Scope and exclusions
| In scope | Out of scope (and why) |
|---|---|
| The Android application, all authenticated screens | The marketing site comiine.com — assessed separately under §4 |
The web console (apps/web) | Third-party OS surfaces (Android system permission dialogs, camera picker) |
Design-system primitives in @comine/ui consumed by both | Roadmap features named in-product as "coming soon" and not reachable |
The Android app is the primary surface: it is the one used in the field, offline, in gloves.
2 · Evaluation methods
- Automated source-contract gates, run on every build and enforced in CI. These are the strongest evidence in this document because they cannot silently rot — each is mutation-tested (deliberately broken, and required to fail by name). -
apps/mobile/src/features/__tests__/a11y-contract.spec.ts— Name and Role on every interactive control in the app and the kit (WCAG 4.1.2), plus the specific colour-only signals closed under 1.4.1. Mutation score 12/12. -packages/ui/__tests__/contrast.aaa.test.ts— computed contrast ratios for design-system colour pairs in both light and dark themes. -packages/ui/__tests__/*.render.spec.tsx— component render tests under the same engine the app uses (jest-expo). -one-header-per-screen.spec.ts— one programmatic heading structure per screen. - Manual code audit of every interactive control (246 in the app, 19 in the kit) for accessible name, role, and state.
- Contrast measurement recomputed from the real design tokens, not from design mockups.
Not yet performed — and therefore not claimed anywhere in this document: end-to-end testing with TalkBack or VoiceOver by a screen-reader user; testing with users with disabilities; switch-access and external-keyboard traversal on Android; automated axe/DOM scanning of the web console.
3 · Conformance by chapter
| Clause | Criterion | Status | Evidence / remark |
|---|---|---|---|
| 9.1.1.1 / 11.1.1.1 | Non-text content | Supports (app) | Every icon-only control carries accessibilityLabel; enforced by the contract spec. Decorative icons inside labelled controls are not separately announced. |
| 9.1.3.1 | Info and relationships | Partially supports | Headings carry accessibilityRole="header" at the eyebrow sites adopted in P4.3-d; a full heading-level audit of all heading sites is open (§5, gap A). |
| 9.1.4.1 | Use of colour | Partially supports | Work-order priority, asset criticality and asset status each carry a word beside the hue. Four dense surfaces still signal by hue alone (§5, gap B). |
| 9.1.4.3 | Contrast (minimum) | Supports | Design-system pairs are computed and asserted in both themes. Several pairs measured below 4.5:1 during Phase 4 were fixed, not waived (P4.2, P4.3-b, P4.3-c). |
| 9.1.4.11 | Non-text contrast | Partially supports | Not yet systematically measured for control borders and state indicators (§5, gap C). |
| 9.2.1.1 | Keyboard | Not evaluated (app) | Android external-keyboard and switch-access traversal untested (§5, gap D). |
| 9.2.5.5 / 11.2.5.5 | Target size | Partially supports | Design tokens define a 44px minimum and 56px "gloved" target. Controls below the floor found in this review were raised via hitSlop; a full sweep of every control is open (§5, gap E). |
| 9.4.1.2 / 11.4.1.2 | Name, Role, Value | Supports (app) | All 246 interactive controls carry a role; all carry an accessible name; selected/checked/expanded state is exposed on tabs, radio groups, filter chips and disclosure rows. Build-enforced. |
| 11.7 | User preferences | Supports | Honours OS light/dark theme and OS font-scaling; reduced-motion is respected via useReducedMotion. |
| 9.3.3.1 | Error identification | Supports | Form errors always render a message string, never colour alone. |
4 · The web console and marketing site
apps/web shares the design-system token and tone layer with the app (@comine/ui/styles), so the contrast and colour-vocabulary guarantees in §3 apply to it. It has not yet been through the automated control-contract gate that covers the Android app, and no DOM-level accessibility scan has been run against it. Web is therefore "Partially supports, not fully evaluated". Closing this is tracked as gap F.
5 · Open gap register
Each gap names the work required. Nothing here is a waiver.
| # | Gap | Effect | Owner |
|---|---|---|---|
| A | Heading levels not audited across all heading sites | Screen-reader users cannot navigate by heading structure reliably | design-director |
| B | Four dense surfaces still signal state by hue alone: the asset tree row criticality dot, the PM calendar day-cell health dots and its compliance rail, and notification priority on the icon tile | Users with colour-vision deficiency lose a secondary signal. In every case the word already exists in code and is simply not rendered; each needs a reviewed visual change on a dense surface | design-director |
| C | Non-text contrast (1.4.11) not systematically measured | Control boundaries may be under 3:1 in one theme | design-systems-engineer |
| D | No external-keyboard / switch-access traversal testing on Android | Unknown | qa-verifier |
| E | Target-size sweep incomplete across all controls | Some controls may sit below the 44px floor | mobile-screen-engineer |
| F | Web console not covered by the automated control contract, and never DOM-scanned | Unknown for web-only surfaces | web-engineer |
| G | No testing with assistive-technology users | The claim in §3 rests on code evidence, not lived evidence | product-manager |
Gap G is the one that matters most for an honest claim. Code-level conformance is necessary and not sufficient; until a screen-reader user has completed the golden paths, this document must keep saying "partially supports".
6 · Feedback and enforcement
Accessibility problems can be reported to game@comiine.com. We aim to acknowledge within 5 working days. Users who are not satisfied with the response may escalate to the relevant national enforcement body; for Botswana-resident users, data-protection matters fall to the Information & Data Protection Commission (IDPC), idpc.org.bw.
Maintained by the Comiine engineering org. Review before every release. The evidence in §2 is generated by the build, so a claim in §3 that the gates no longer support will fail CI before it reaches a customer. Related: docs/legal/privacy-policy.md, docs/legal/terms-of-use.md, docs/DEPTH-LEDGER.md §7.