Quayside Pay · 2022
An accessibility overhaul for an invoicing and payments app
Took a payments app from 212 WCAG failures to a clean AA re-audit, and fixed the flows that screen reader and keyboard users depend on.
- Client
- Quayside Pay
- Year
- 2022
- Role
- Lead designer, accessibility
- Duration
- 5 months
- Services
- Accessibility audit
- Inclusive research
- Design system
The problem
Quayside Pay sends invoices and collects payments for small businesses. A public-sector tender required WCAG 2.2 AA conformance, and an external audit found 212 failures across the web app, including an invoice editor that could not be used with a keyboard and a payment form that announced every field as 'edit text'. The tender deadline was five months away, and the team had no accessibility experience in-house.
An audit tells you what is broken, not what matters most, so I ran usability sessions with 7 disabled participants, including screen reader, switch, magnification and keyboard-only users, recruited through a specialist panel and paid for their time. Payers struggled most with the payment form, and business owners with the invoice line-item editor. Those two flows accounted for 70% of the audit failures, which made the plan easy to defend.
Process
- 01
Fixed the shared components first
Many failures came from four shared components: the button, form field, modal and table. I redesigned them with visible focus states, minimum 24 pixel targets and colour tokens that pass contrast in both themes, and engineers rebuilt them with correct semantics. Fixing components before pages meant a slow first month with little visible progress, but it closed 96 failures in a single release.
- 02
Rebuilt the line-item editor
The invoice editor was a grid of inputs that relied on drag and drop. I replaced dragging with move up and move down actions, set a logical tab order, and announced updated totals through a polite live region so screen reader users heard the new total without losing their place. In the second testing round, a keyboard-only participant created a five-line invoice in under three minutes, after failing to finish one at all.
- 03
Made it part of the routine
To keep the gains, I added an accessibility checklist to the design review template, put automated checks into the pull request pipeline, and ran two half-day workshops with hands-on screen reader practice. Automated checks catch only part of the problems, so the team agreed to fund one round of testing with disabled participants every quarter.
Selected images
We came for a tender requirement and ended up with a better product for every customer we have.
Outcome
Five months later, a re-audit found no AA failures in the core flows and 9 minor issues elsewhere, all fixed within a sprint. Quayside Pay won the tender. The less expected result: mobile payment completion rose 12% for all users, mostly thanks to larger targets and clearer error messages, and payment form support tickets fell by more than a quarter.
- 212 → 0
- AA failures in core flows
- +12%
- mobile payment completion
- −27%
- payment form tickets
Keep reading
All work