Users trust
To improve your product metrics, build extra trust, and avoid fines, make accessibility a core part of your product development workflow. Especially in fintech.


Pavel Chelyuskin
Founder
WCAG 2.0 (Web Content Accessibility Guidelines) was first released in late 2008 and introduced the POUR principles: Perceivable, Operable, Understandable, Robust. Today, meeting WCAG is no longer just “nice to have” UX hygiene—it is a regulatory requirement in many markets.
The European Accessibility Act (EAA, Directive (EU) 2019/882), which applies in full from 28 June 2025, requires digital accessibility for financial services, including banking platforms, mobile apps, and payment services. The directive does not name WCAG explicitly, but it does require that services follow the POUR principles as the basis for accessibility.
Legal cases are still relatively rare, but they are already happening. For example, airline Vueling has reportedly been fined 90,000 euros and lost access to state subsidies for six months over accessibility issues. With the EAA now fully in force, enforcement activity and case statistics are expected to grow in the coming years.
Title III of the Americans with Disabilities Act (ADA) requires private businesses—such as banks, restaurants, shops, hotels, cinemas, and medical offices—to provide equal access to goods, services, and premises for people with disabilities. While the ADA originally focused on physical accessibility (ramps, parking, etc.), federal guidance and case law now make it clear that banking and fintech websites and apps must also be accessible and are expected to follow WCAG.
Section 508 of the Rehabilitation Act requires federal agencies and their vendors, including fintech providers selling into the federal space, to meet WCAG 2.0 AA at minimum. In practice, many organizations now treat WCAG 2.1 AA as the current baseline.
Earlier cases often ended without monetary penalties and focused on requiring companies to fix their websites and apps and then report on WCAG compliance. Examples include:
Litigation has accelerated. By 2025, more than 2,000 web accessibility lawsuits had already been filed in a single year in the US, with many cases ending in out-of-court settlements.
In real projects, most hands-on accessibility work typically lands with frontend engineers. However, designers and product managers have a lot of influence and should actively steer this work.
Key areas to control in design and product:
A very helpful resource is Ardvark’s WCAG in Plain English, which explains each WCAG criterion in clear language and lets you filter by role (design, code, content) and other dimensions. This is a good starting point for teams that find the official W3C text too dense.
While designing interfaces in Figma, it is useful to integrate automated accessibility checks into the workflow. In practice, most plugins do not go much further than color contrast checks—but even that is already a meaningful improvement in everyday work.
Popular plugins include:
A common issue with many plugins is that they do not always correctly detect which colors are used for text and backgrounds, which leads to false positives or missed failures. In our agency work, BrowserStack’s toolkit has proven to be the most reliable among the popular options, with fewer detection errors overall.
Accessibility is a competitive advantage. Regulatory pressure is increasing across markets, but the main benefit remains product quality and conversion. Accessible interfaces tend to convert better, especially because people with reduced mobility and older adults often represent between 15% and 30% of the user base, depending on the market.
WCAG
European Union
United States
Figma plugins