Accessibility statement
Where WinkPG stands against WCAG 2.1 Level AA, what is known to be incomplete, and what is planned.
The WinkPG platform default. An operator may replace it with their own text. Last reviewed 20 September 2026.
Our commitment
The platform is built to be usable by everyone, and WCAG 2.1 Level AA is the standard it is being brought to.
This statement is deliberately not a claim of conformance. A formal third-party audit has not yet been completed, so the honest position is the one below: a strong foundation, a known set of gaps and a dated plan.
Where the foundation is strong
The component library the application is built on publishes and maintains WCAG 2.1 Level AA conformance for its own component set, covering inputs, data grids with keyboard navigation, dialogs, forms, charts with text alternatives and navigation components.
The web framework supports ARIA attributes and semantic HTML natively. Headings, landmarks and form labels are generated by the components and by the application's own markup, keyboard navigation and focus management are handled for modal surfaces, and the typography scale is sized in relative units so that it respects browser zoom.
Component level conformance is not application level conformance, and this statement does not present it as such.
Known gaps
Color contrast on configured branding: colors an operator or a merchant chooses may not meet the contrast ratios the standard requires. Contrast validation in the branding configuration is planned.
Form error messaging: validation errors need to be announced through live regions, and that wiring is not yet consistent across every form.
Custom components: any component built outside the vendor library needs its own accessibility review.
Loading states and dynamic content: long running operations need live region announcements.
Exported PDFs need to be tagged, and transactional email templates need accessible structure.
Status changes such as a transaction authorization should be announced through live regions.
What has not been assessed
Conformance of every page against every Level AA success criterion.
Screen reader compatibility with specific assistive technologies on specific browsers.
Mobile accessibility, including touch target sizes and responsive layouts.
Complex interactions such as drag and drop and multi-step wizards.
What is planned
Near term: an internal audit baseline with automated tooling across every major page, automated accessibility tests in the build pipeline, contrast validation enforced in branding configuration, manual screen reader testing, an accessibility review gate for custom components, and developer guidance.
After that: a formal third-party audit, publication of a Voluntary Product Accessibility Template based on its results, a prioritized remediation plan and an annual re-audit.
Longer term: assessment against WCAG 2.2, Section 508, EN 301 549 and comparable regional standards as deployments require them.
Feedback
If you meet an accessibility barrier, or you have a requirement that goes beyond the Level AA baseline, tell the operator of this instance through the support contact in the footer. Specific requirements are useful input into the plan above.
Evidence and compliance materials
This surface states posture and publishes no evidence. The attestations, reports and control matrices behind these statements are in the trust documents catalogue, where a signed-in developer account can retrieve them and every retrieval is recorded.