Our accessibility commitment.
Fluxa aims to meet Web Content Accessibility Guidelines (WCAG) 2.2 Level AA across the website, the merchant dashboard, and every cardholder-facing checkout surface. WCAG 2.2 became a W3C Recommendation on 5 October 2023 and is now ISO/IEC 40500:2025; meeting it is the established baseline for "reasonable steps" under the UK Equality Act 2010 and the technical reference standard cited by the European Accessibility Act for digital payment services.
Accessibility is not a project with a finish line. The page below is a snapshot of what is true today: the standards we have committed to, the techniques the code applies, the assistive technology we test against, the gaps we have not closed yet, and the route to tell us about something that does not work. Reviewed quarterly.
This statement covers fluxapay.co.uk and the hosted checkout served at pay.fluxapay.co.uk. The merchant dashboard at dashboard.fluxapay.co.uk is in scope on the same standard; its current conformance level is partial and the gaps are listed below.
Standards we follow.
Four documents define what Fluxa builds against. Each one is referenced by name so the commitment is testable, not aspirational.
WCAG 2.2 Level AA
The W3C Web Content Accessibility Guidelines, version 2.2, conformance Level AA. Eighty-six testable success criteria covering perceivable, operable, understandable and robust content. The current target for every page Fluxa ships.
ISO/IEC 40500:2025
The ISO publication of WCAG 2.2, identical text. Cited where a procurement requirement asks for an ISO reference rather than a W3C recommendation.
EN 301 549
The European harmonised standard for ICT accessibility, presumed-conformance route for the European Accessibility Act. Currently references WCAG 2.1; the next revision will reference WCAG 2.2 directly.
WAI-ARIA 1.2
The W3C Accessible Rich Internet Applications specification. Used wherever native HTML semantics are not sufficient (custom dropdowns, dialogs, tabs in the dashboard). Combined with native elements wherever possible, ARIA layered only when needed.
The four principles.
WCAG organises every success criterion under four principles: Perceivable, Operable, Understandable, Robust. The acronym is POUR. Each section of Fluxa is checked against all four.
Perceivable
Information and interface components must be presentable in ways the user can sense. Alt text on informative images, captions on video, sufficient colour contrast (minimum 4.5:1 for body text, 3:1 for large text and UI components), no information conveyed by colour alone.
Operable
Every interface component is reachable and usable with a keyboard alone. Focus is always visible, never obscured by sticky UI (WCAG 2.4.11). Interactive targets are at least 24×24 CSS pixels (WCAG 2.5.8). No time limits on form completion. No content flashes more than three times per second.
Understandable
Text is in plain English, jargon is defined the first time it appears, error messages are specific and recoverable (WCAG 3.3.3). The page language is declared on every document (lang="en-GB"). Form labels describe their inputs. Navigation is consistent across pages.
Robust
Markup is valid HTML5, parsable by current and future assistive technologies. Components are built on native elements first, ARIA layered only where needed. Name, role and value are programmatically determinable for every custom widget (WCAG 4.1.2).
Built-in accessibility.
Specific techniques the codebase already applies. Each one maps to a WCAG success criterion so a third-party auditor can check it directly.
Skip to main content
Every page exposes a "Skip to main content" link as the first focusable element. Hidden until focused, visible on Tab press, jumps past the navigation. Maps to WCAG 2.4.1 Bypass Blocks.
Keyboard navigation throughout
Every interactive element is reachable with Tab, dismissable with Escape where applicable, and operable with Enter or Space. No keyboard traps. Focus order follows visual reading order. Maps to WCAG 2.1.1, 2.1.2 and 2.4.3.
Visible focus indicators
The default browser focus ring is preserved on every interactive element, never removed without a higher-contrast replacement. Custom focus styles use a two-pixel outline with three-pixel offset, contrast ratio at least 3:1 against adjacent colours. Maps to WCAG 2.4.7 and 2.4.11.
Semantic landmarks
Each page uses <header>, <nav>, <main>, <aside> and <footer> landmarks so screen readers can jump between regions. Headings descend in order (h1, then h2, no skipping levels). Maps to WCAG 1.3.1 and 2.4.6.
Form labels and autocomplete
Every form input has a programmatically associated label (<label for> or aria-labelledby). Autocomplete tokens are set on personal-information fields (autocomplete="email", autocomplete="cc-number") so password managers and browser autofill work cleanly. Maps to WCAG 1.3.5 and 3.3.2.
Colour contrast
Body text is checked at minimum 4.5:1 contrast against background, large text and UI components at minimum 3:1. The primary brand blue #1860b0 on white is 6.29:1. Muted text #556a8a on white is 5.5:1. Default body ink #0a1628 on white is 18:1. Maps to WCAG 1.4.3 and 1.4.11.
Decorative imagery marked aria-hidden
The wave canvases, brand pattern graphics and decorative SVG icons all carry aria-hidden="true" so they do not pollute the screen-reader transcript. Informative images carry meaningful alt text. Maps to WCAG 1.1.1.
Reduced motion respected
The site reads prefers-reduced-motion: reduce and disables decorative animation when the user has set that preference at the operating-system level. Functional animation (loading states, focus transitions) remains. Maps to WCAG 2.3.3.
Target sizes
Interactive targets are minimum 24×24 CSS pixels, or smaller with sufficient spacing around them, per WCAG 2.5.8 introduced in WCAG 2.2. The primary navigation, checkout buttons and dashboard controls all meet this.
Language declared
Every page declares lang="en-GB" on the root <html> element so screen readers pronounce content correctly. Any embedded content in a different language carries its own lang attribute. Maps to WCAG 3.1.1 and 3.1.2.
Assistive technology.
The matrix Fluxa is built to be compatible with. The first four (NVDA, VoiceOver macOS, VoiceOver iOS, keyboard alone) run during day-to-day development. The remaining four are verified by the pre-launch third-party audit. Automated tooling alone catches roughly 30 to 40 per cent of accessibility issues, so the remaining checks are run manually.
NVDA on Windows
NV Access NVDA (latest stable) with Firefox and Chrome on Windows 10 and Windows 11. NVDA is free, widely used, and the practical reference screen reader for most accessibility audits. Used for day-to-day verification during development.
VoiceOver on macOS
VoiceOver with Safari on macOS Sonoma and Sequoia. Built in to every Mac and the most common screen reader among professional users on macOS. Used alongside NVDA during development.
VoiceOver on iOS
VoiceOver with Safari on iPhone, iOS 17 and iOS 18. Critical for the cardholder-facing checkout since most card payments now complete on mobile. Verified manually before each checkout release.
Keyboard alone
Every page is exercised with no mouse and no trackpad. Tab to advance, Shift-Tab to retreat, Enter to activate, Space for buttons, arrow keys for menus, Escape to dismiss. If any flow cannot be completed this way, it is logged as a bug, not an enhancement.
TalkBack on Android
TalkBack with Chrome Mobile on Android 14 and Android 15. Compatibility is targeted; formal verification is run by the pre-launch third-party audit, since TalkBack on dynamic content can behave differently to iOS VoiceOver.
JAWS on Windows
Freedom Scientific JAWS with Chrome and Edge on Windows. The commercial enterprise screen reader most often deployed in regulated industries. Compatibility verified by the pre-launch third-party audit; JAWS behaves differently to NVDA on dynamic content, so the audit covers both.
Screen magnification
200% browser zoom and 400% browser zoom checked on every layout. No horizontal scrolling at 320 CSS pixels width (WCAG 1.4.10 Reflow). Text reflows; UI does not break.
Voice control
Apple Voice Control on macOS and iOS, plus Windows Speech Recognition. Every visible control has a label that matches its accessible name so it can be spoken to activate. Maps to WCAG 2.5.3 Label in Name.
Checkout accessibility.
The cardholder checkout at pay.fluxapay.co.uk is where accessibility matters most: a person paying for something they need cannot route around the payment page if it is not accessible. The standard is the same WCAG 2.2 AA, the techniques are tighter, and there is no shared content layer that an inaccessible third party can inject into the surface.
No CAPTCHA
Fluxa does not use Google reCAPTCHA, Cloudflare Turnstile, hCaptcha, or any other cognitive challenge that would block users with cognitive disabilities or screen readers. Fraud risk is managed at the gateway and payments partner layer using behavioural and transactional signals, not user-side puzzles. Maps to WCAG 3.3.8 Accessible Authentication.
Password manager and autofill friendly
Card-number, expiry, CVV, billing-address and email fields all carry the correct autocomplete tokens (cc-number, cc-exp, cc-csc, etc.) so browser-native autofill and password managers (1Password, Bitwarden, Apple Keychain) populate them directly. No copy-paste restrictions.
Error messages that explain
If a payment fails, the message names the reason (insufficient funds, card declined, 3DS verification failed) and tells the user what to do next. Errors are announced to screen readers via an aria-live="polite" region. No vague "something went wrong" dead ends. Maps to WCAG 3.3.1 and 3.3.3.
Apple Pay and Google Pay support
For users where typing in card details is difficult, Apple Pay (on iOS/macOS Safari) and Google Pay (on Chrome) are offered as one-tap alternatives. The platform handles biometric authentication on the user’s own device, which is more accessible than CVV plus 3DS for most disability profiles.
3-D Secure flows verified for assistive tech
The Strong Customer Authentication step required by PSD2 is the most common accessibility failure in payment flows industry-wide. The SCA challenge is verified with NVDA and VoiceOver as part of the pre-launch audit, including the bank-side iframe content where the issuer hosts it.
Focus management on multi-step flows
When a step changes (card details, address, 3DS challenge, confirmation), focus moves to the new step heading rather than resetting to the top of the page. Screen-reader users land on the right content. Maps to WCAG 2.4.3 Focus Order.
No time limits without warning
The checkout does not silently expire a session mid-payment. If a session is approaching expiry, the user is warned with at least 60 seconds to extend (WCAG 2.2.1). Default session length is generous enough for a screen-reader-paced flow.
Known limitations.
Honest list of where Fluxa is not yet at the standard. WCAG conformance is binary at each success criterion: there is no part-credit. The items below are not in conformance today and the remediation date is published next to each one.
Dashboard data visualisations (in remediation)
Some merchant-dashboard charts (settlement timeline, chargeback ratio sparklines) currently convey information through visual differentiation alone. The underlying data is exportable as accessible CSV today; rich chart descriptions and screen-reader-friendly tabular alternatives are scheduled for Q3 2026 (WCAG 1.1.1 and 1.4.1).
PDF settlement reports (in remediation)
Settlement reports exported as PDF are not currently tagged for screen-reader navigation. The same data is available as accessible CSV and on-screen HTML today. Tagged PDF export (PDF/UA compliance) is scheduled for Q4 2026.
Future media content
Fluxa does not currently publish video or audio walkthroughs. When video content is added to the site (product walkthroughs, founder updates), it will ship with captions, a full transcript and audio descriptions from day one. Maps to WCAG 1.2.1, 1.2.2 and 1.2.5.
Mobile app (not yet released)
A native iOS and Android merchant app is on the roadmap for late 2026. When released, it will target WCAG 2.2 AA from the first beta and follow Apple and Google platform accessibility guidelines (VoiceOver, TalkBack, Dynamic Type, Switch Control).
Third-party content embeds
Where Fluxa embeds content from third parties (the bank-hosted 3DS challenge frame, font files from Google Fonts), accessibility depends partly on the third party. The third parties used are mainstream and themselves WCAG-conformant, but Fluxa cannot independently warrant their content.
Pre-launch state
Fluxa is pre-launch. Sections of the platform built since the last review may not yet have completed the full assistive-technology matrix above. Anything caught in the pre-launch third-party audit will be remediated before live processing begins, or listed here with a date if remediation cannot land before launch.
Reporting an issue.
If you encounter a barrier on any Fluxa surface, write to accessibility@fluxapay.co.uk. The inbox is monitored by Fluxa and a human reply comes within one working day. Critical issues (a cardholder cannot complete a payment) are treated as P1 and worked on the same day.
Useful details to include if you can: the URL or page name, the assistive technology and browser version you were using, what you were trying to do, and what happened or did not happen. None of these are required; a one-line description is enough to open the case.
Fluxa logs every accessibility report, replies with what action will be taken and an expected date, and confirms when the fix is shipped. Where a barrier cannot be removed quickly, an interim workaround is offered. Where the report identifies a WCAG non-conformance not already on the limitations list above, that list is updated within five working days.
If you believe Fluxa has not made reasonable adjustments under the Equality Act 2010, you can raise a formal complaint via /complaints. EU users have the right to lodge a complaint with the relevant national enforcement body under the European Accessibility Act.
Review and audit.
Fluxa reviews this statement and the underlying conformance quarterly. The review covers: any new pages or features shipped since the last review, any reports received from users, automated testing (axe-core, WAVE, Lighthouse) across every published surface, and manual testing against the assistive-technology matrix above.
A formal third-party accessibility audit by a UK-registered accessibility specialist is planned before live launch, then annually. The audit report and remediation log will be published at /changelog once the first audit is complete.
This statement is versioned. Every material change is logged with a date and a one-line description on the changelog page. Last reviewed May 2026. Next scheduled review August 2026. First third-party audit planned for Q3 2026.
Legal compliance.
This statement is published under the Equality Act 2010 (UK), which requires service providers to make reasonable adjustments so that disabled people are not placed at a substantial disadvantage compared with non-disabled people. WCAG 2.2 AA is the established benchmark courts and the Equality and Human Rights Commission use when assessing reasonable digital adjustments.
For users in the European Union, Fluxa’s consumer-facing surfaces (the hosted checkout served to EU cardholders, and any documentation aimed at EU merchants) are scoped under the European Accessibility Act (Directive (EU) 2019/882), in force since 28 June 2025. The presumed-conformance route is EN 301 549, which references WCAG. Fluxa’s primary obligations under the EAA relate to payment services under PSD2 where they reach EU consumers; merchant-only services (the dashboard accessed by business merchants) sit outside the directive’s consumer scope but are built to the same standard.
The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 apply to UK public-sector organisations and do not directly bind Fluxa. The standard those regulations require (WCAG 2.2 AA) is the same standard Fluxa commits to here.
Nothing on this page constitutes legal advice. Where a specific accessibility need or legal question is not covered, write to accessibility@fluxapay.co.uk and Fluxa will respond with the position and any escalation route.