Outcome
Accessibility moved from a downstream compliance check into the design operating model: visible on the roadmap, built into shared foundations and treated as a release-quality requirement across consumer products.
Overview
Accessibility was elevated from “nice to have” to an explicit criterion in the UX Quality Bar across Skrill and PaysafeCard, with shared foundations also serving the wider consumer portfolio. Products were audited against WCAG 2.1 AA, working toward 2.2, with European Accessibility Act readiness as important regulatory context.
I set up and sponsored the programme; specialist auditors ran the product reviews against the shared criteria. The aim was not simply to find accessibility defects. It was to make accessibility harder to lose as products changed — with audit findings becoming the backlog for component-level fixes.
Approach
-
01
Put accessibility inside the definition of done
WCAG AA expectations became part of the same quality bar used in design review (Design Gates & UX Quality Bar →). Accessibility was no longer treated as a polish pass after the experience had already been designed.
-
02
Audit products as roadmap work
Accessibility reviews were treated as product initiatives rather than informal design clean-up. Audits covered Skrill and PaysafeCard (web, iOS and Android) and identified 680+ issues across the two products, which became the backlog for component-level fixes — visible alongside other product priorities rather than dependent on spare design capacity.
-
03
Fix the system before fixing the same screen twice
Some issues belonged at product level; others were symptoms of shared foundations. Colour and token alignment in the Global Design System allowed recurring problems to be addressed closer to their source rather than patched independently across products — tokens first where possible, then screens.
-
04
Make assessment consistent
I maintained an accessibility assessment framework and checklist so designers, partners and agencies could review work against the same expectations. A contrast issue, missing focus state or inaccessible error pattern should not depend on who happened to review the work; shared criteria made findings easier to compare, discuss and prioritise.
Each component in the library was audited against nine categories. Colour contrast was checked separately for each brand theme, which made 15 checks per component, each marked compliant, partially compliant, not compliant or still to test.
How each check was recorded: a status, a severity tag where it applied, and notes on the next step. -
05
Combine automated and manual review
Automated checks were useful for identifying repeatable issues quickly, but they were not treated as a replacement for judgement. The review approach combined automated support with manual assessment before handoff, including BrowserStack-assisted accessibility review where appropriate — automation can accelerate inspection; humans still own the decision.
Outcomes
- Accessibility as governance — WCAG expectations in the UX Quality Bar and design-readiness conversation.
- Roadmap visibility — audits and remediation as explicit product work.
- System-level fixes — tokens and semantic palette reduced one-off corrections.
- Shared assessment language — clearer criteria for Design, Product, Engineering and partners.
- Earlier risk visibility — issues surfaced before handoff rather than after implementation.
- Regulatory readiness — accessibility, usability and navigation connected to evolving European requirements.
Reflection
Accessibility is easiest to deprioritise as a separate improvement stream. The more durable approach is to put it inside how teams already decide: design systems, roadmaps, reviews and definitions of done. If the same problem keeps returning across products, fixing the screen is only part of the answer.