Banking and Financial Services Accessibility: What the Law Requires in 2025

<p>In 2025, a visually impaired customer tries to apply for a mortgage on a major bank's website. The application form has no visible labels, the error messages aren't announced by her screen reader, and the progress indicator is built entirely in CSS with no accessible text alternative. She abandons the process entirely. Meanwhile, her bank's legal team is already fielding a demand letter — one of the <strong>3,117 website accessibility lawsuits</strong> filed in U.S. federal court last year alone, a 27% jump from the year before. For financial institutions, 2025 is the year the legal and ethical case for accessibility converged into something impossible to ignore.</p> <h2>Why Financial Services Face Heightened Accessibility Obligations</h2> <p>Banking is not a discretionary service. People need access to their money, credit, and investment accounts to participate fully in modern economic life. <cite index="3-4">For customers with disabilities, accessible financial services aren't a luxury — they're essential for economic participation and independence.</cite> That reality is increasingly reflected in how courts, regulators, and legislators treat financial institutions.</p> <p><cite index="5-26">Banks are "places of public accommodation" and are therefore covered under Title III of the Americans with Disabilities Act (ADA).</cite> <cite index="7-5">Under Title III of the ADA, places of public accommodation — a broad category that includes banks and other businesses open to the public — are required to provide accessible services for individuals with disabilities.</cite> While the ADA was enacted in 1990 and initially focused on physical access, courts have steadily extended its reach to digital platforms, mobile apps, and online banking portals.</p> <p><cite index="9-4">With the rise of digital banking, approximately two-thirds of U.S. adults now depend on online platforms — websites and apps — to manage their finances.</cite> That shift has made inaccessible digital infrastructure not merely inconvenient but genuinely discriminatory. <cite index="5-13,5-14">For the approximately 61 million people with some form of disability in the U.S., banks and financial institutions must ensure their digital platforms are all Section 508 and ADA compliant, as web accessibility is critical for people with disabilities to use these services. Failure to provide access to websites, apps, and online documents — such as forms and PDFs — can lead to litigation, a trend that is consistently rising.</cite></p> <p>The financial sector also faces a broader web of regulatory exposure beyond just the ADA. <cite index="37-3,37-4,37-5,37-6">Financial institutions face multiple accessibility mandates: ADA Title III requires banks as places of public accommodation to provide accessible services, increasingly interpreted to include websites; Section 504 applies to financial institutions receiving federal funds; Section 508 governs government-contracted financial services; and state laws such as California's Unruh Act and the New York Human Rights Law provide additional protections.</cite> On top of that, <cite index="37-7,37-8">the Consumer Financial Protection Bureau (CFPB) examines accessibility as part of fair lending and consumer protection, and the Office of the Comptroller of the Currency (OCC) includes accessibility in risk management guidance.</cite></p> <h2>The U.S. Legal Landscape in 2025: Record Filings and Rising Stakes</h2> <p>The litigation environment has never been more intense. <cite index="11-6,11-7,11-8">Plaintiffs filed 3,117 website accessibility lawsuits in federal court in 2025 — a 27% increase from 2024. Website accessibility lawsuits filed in federal court bounced back from their two-year decline, with the total number of lawsuits alleging that plaintiffs with a disability could not use websites because they were not designed to be accessible reaching 3,117.</cite></p> <p><cite index="11-11">Website accessibility lawsuits accounted for 36% of the total number of ADA Title III lawsuits filed in federal court in 2025 — 3,117 out of 8,667 cases.</cite> And that figure almost certainly undercounts the real exposure. <cite index="15-6,15-7,15-8">Most notably in 2025, digital accessibility lawsuits and settlements are no longer confined to federal court. Plaintiffs increasingly filed in state courts, particularly in New York and California. These courts allow plaintiffs to recover financial damages, not just injunctive relief, court costs, and legal fees.</cite></p> <p>For financial institutions specifically, <cite index="7-12">web accessibility litigation in banking remains common: according to the State of Digital Accessibility Report (SODAR), 57% of financial services professionals reported involvement in legal action related to digital accessibility in the past year alone.</cite> Settlements are rarely cheap. <cite index="19-2">Settlements typically range from $5,000 to $75,000, plus attorney fees, redesign costs, and monitoring expenses.</cite> When those costs are multiplied across demand letters, state-court actions, and mandatory remediation timelines, the financial exposure grows substantially.</p> <p><cite index="2-8">The Department of Justice has increasingly emphasized digital accessibility enforcement, making it clear that online banking services must be as accessible as physical branches, with new guidelines requiring WCAG 2.1 Level AA compliance for digital services by April 2026.</cite> The forthcoming Title II rule for government entities sets a precedent that private-sector enforcement is likely to follow, and financial institutions with any government contracts or federally insured deposits would be wise to treat WCAG 2.1 AA as their floor, not their ceiling.</p> <h2>The European Accessibility Act: Now Enforceable and Directly Targeting Banking</h2> <p>For institutions operating in or serving customers in the European Union, 2025 marked a decisive turning point. <cite index="23-3">The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025 in all Member States and seeks to eliminate barriers for consumers with disabilities by harmonising accessibility requirements across the internal market for certain products, services and built environments.</cite> This is not a future obligation — <cite index="25-1,25-2">since June 28, 2025, organizations must comply with the EAA as transposed into their member state's national law, and enforcement is active with regulators watching.</cite></p> <p>The EAA is unusually explicit in its coverage of financial services. <cite index="21-6">From 28 June 2025, in-scope firms need to ensure that they design their websites, mobile apps, contracts and all forms of communication with consumers — including call centre services as well as devices such as payment terminals and ATMs — in a way that is accessible to persons with disabilities.</cite> <cite index="21-20,21-21">The directive covers "consumer banking services" including credit agreements, payment services and certain investment services; however, pure deposit business is not in scope of "consumer banking services" under this Act — only payment accounts and electronic money are covered.</cite></p> <p><cite index="21-23,21-24">The EAA requires "economic operators" of in-scope products and services to provide certain information in an accessible manner through the two-senses principle, making websites and mobile applications accessible by making them perceivable, operable, understandable and robust. "Economic operators" includes financial services providers, including banks, payment service providers and e-money providers.</cite> The technical standard underpinning the EAA is EN 301 549, <cite index="26-5">which references accessibility requirements harmonized through EN 301 549, the European standard for ICT accessibility that incorporates WCAG 2.1 Level AA criteria for digital content and documents.</cite></p> <p>The penalties for non-compliance are serious and vary by member state. <cite index="29-6">Failure to comply can result in penalties up to €100,000 or 4% of annual revenue, making EAA compliance a critical priority for any business serving EU customers.</cite> Notably, <cite index="25-14,25-15">the EAA has extraterritorial reach: if your business serves EU customers, you may need to comply regardless of where you are headquartered, creating dual compliance obligations alongside the ADA for U.S. businesses.</cite></p> <blockquote><p><strong>Good news for compliance teams:</strong> Both the ADA and EAA converge on the same technical baseline. <cite index="25-17">Both laws share WCAG 2.1 Level AA as their technical baseline</cite>, meaning a single well-executed WCAG 2.1 AA program addresses the core requirements of both frameworks simultaneously.</p></blockquote> <h2>WCAG in Banking: What the Standard Actually Demands</h2> <p><cite index="1-2,1-3">Bank websites and mobile apps are expected to align with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, and U.S. courts often reference WCAG when assessing ADA compliance in digital banking.</cite> WCAG is organized around four foundational principles — <cite index="31-9,31-10,31-11,31-12">Perceivable (users must be able to perceive the information, e.g., screen reader support and alternative text), Operable (navigation and UI elements must be usable via keyboard and assistive devices), Understandable (content and interactions must be predictable and easy to comprehend), and Robust (websites should work with current and future assistive technologies).</cite></p> <p>The latest version, WCAG 2.2, introduces criteria of particular relevance to banking. <cite index="34-4,34-5">WCAG 2.2 introduced Accessible Authentication (Minimum), which aims to make login easier for people with cognitive disabilities by avoiding tests that rely too heavily on memory, transcription, or puzzle-solving — this matters in banking apps because many teams keep adding friction in the name of security.</cite> <cite index="34-33,34-34">Tiny buttons, close-together links, and cramped menu items make the app harder to use for people with limited dexterity, and WCAG 2.2 added Target Size (Minimum) at Level AA, which requires pointer targets to be at least 24 by 24 CSS pixels unless an exception applies.</cite></p> <p>Banking platforms face unique WCAG challenges because of their inherently complex interfaces. <cite index="7-15,7-16,7-17,7-18">Despite legal requirements, users with disabilities often encounter significant barriers when accessing banking services. Issues like screen reader incompatibility, inaccessible forms, and poorly designed error handling can make the entire online banking experience frustrating and unusable. These challenges frequently emerge after the initial login stage, as many banks have focused on improving the accessibility of their public websites while the post-login experience is often neglected.</cite></p> <p>The principle applies end-to-end. <cite index="38-22,38-23,38-24">A banking service is only ever as accessible as its weakest link. If a single step fails, the entire process fails — regardless of how well the other parts are implemented. For banks, this has legal implications: a service is only considered accessible if it can be used in its entirety, from start to finish.</cite></p> <h2>The Most Common Accessibility Failures in Financial Platforms</h2> <p>Knowing where banks consistently fail is just as important as knowing what the rules require. <cite index="20-3">Of the top one million home pages on the internet, 95 percent have accessibility barriers that interfere with the ability of people with disabilities to use them, according to a 2025 report by WebAIM.</cite> In financial services specifically, certain failure patterns appear with troubling regularity.</p> <p>Here are the most critical failure categories for banking and financial platforms:</p> <ul> <li><strong>Inaccessible login and authentication flows.</strong> <cite index="34-6">Many teams keep adding friction in the name of security, such as forcing users to copy one-time codes between apps with no autofill support, requiring complex character recall from partial passwords, or using image or puzzle challenges without accessible options.</cite> Security and accessibility are not mutually exclusive — password manager support and audio CAPTCHA alternatives satisfy both requirements.</li> <li><strong>Unlabeled buttons and icons.</strong> <cite index="34-43,34-44">A major failure is the absence or weakness of labels: buttons that only show an icon can become meaningless to a screen reader if they are not labeled properly.</cite> A transfer button that renders as just a visual arrow announces itself to a screen reader user simply as "button," providing zero context.</li> <li><strong>Inaccessible transaction tables and dashboards.</strong> <cite index="32-3,32-4">Banking and financial services face challenges from complex applications, account management interfaces, and security requirements, with a common pattern being complex tables without proper headers, account data not properly structured, and dashboard widgets that are inaccessible.</cite></li> <li><strong>Session timeouts without adequate warning.</strong> <cite index="1-19,1-20">Banks often limit the amount of time a website visitor spends on a web page for security reasons. When engaging with web pages that have time limits, website visitors need to be able to turn off, or at least extend the time limit.</cite> Failing to provide this is a direct WCAG 2.1 violation (SC 2.2.1).</li> <li><strong>Inaccessible PDF documents.</strong> <cite index="10-28,10-30">Customers with motor impairments find it difficult to navigate websites that lack keyboard-friendly design, and important financial documents like monthly statements, reports, and letters in PDF format are often not designed for screen readers, making it challenging for visually impaired customers to access them.</cite></li> <li><strong>Poor color contrast.</strong> <cite index="34-36,34-37">If gray text sits on a pale background, users may miss a payment status or a fee notice, and if disabled and active states look almost the same, people may not know what action is available.</cite></li> <li><strong>Inaccessible electronic signatures.</strong> <cite index="1-16,1-17,1-18">Online documents used and featured by banks sometimes require an e-signature. Accommodations should be made for people with disabilities to sign these documents, for example by offering alternative signage methods such as a signature stamp or voice recognition software.</cite></li> </ul> <h2>Building an Accessible Banking Platform: A Practical Code Example</h2> <p>Accessible financial interfaces require care at the code level. A login form is often the first thing a user with a disability encounters, and it sets the tone for the entire experience. Below is an example of a properly structured, accessible bank login form that uses semantic HTML, ARIA attributes, and allows password manager autofill:</p> <pre><code>&lt;!-- Accessible bank login form --&gt; &lt;form id='login-form' novalidate aria-labelledby='login-heading'&gt; &lt;h1 id='login-heading'&gt;Sign In to Your Account&lt;/h1&gt; &lt;div class='form-group'&gt; &lt;label for='username'&gt;Username or Account Number&lt;/label&gt; &lt;input type='text' id='username' name='username' autocomplete='username' aria-required='true' aria-describedby='username-hint' &gt; &lt;span id='username-hint' class='hint-text'&gt; Enter the username you created at registration &lt;/span&gt; &lt;/div&gt; &lt;div class='form-group'&gt; &lt;label for='password'&gt;Password&lt;/label&gt; &lt;!-- Do NOT block paste — password managers must work --&gt; &lt;input type='password' id='password' name='password' autocomplete='current-password' aria-required='true' &gt; &lt;/div&gt; &lt;!-- Accessible error region --&gt; &lt;div role='alert' aria-live='assertive' id='login-error' class='error-region' hidden &gt; &lt;!-- Errors injected here are announced immediately --&gt; &lt;/div&gt; &lt;!-- Accessible CAPTCHA: audio option required --&gt; &lt;div class='captcha-wrapper'&gt; &lt;!-- Use accessible reCAPTCHA or SMS/email OTP instead of visual-only CAPTCHA --&gt; &lt;/div&gt; &lt;button type='submit'&gt;Sign In&lt;/button&gt; &lt;p&gt; &lt;a href='/forgot-password'&gt;Forgot password?&lt;/a&gt; &lt;a href='/forgot-username'&gt;Forgot username?&lt;/a&gt; &lt;/p&gt; &lt;/form&gt;</code></pre> <p>Key patterns demonstrated above: every input has an explicit <code>&lt;label&gt;</code> linked via <code>for</code>/<code>id</code>; <code>autocomplete</code> attributes are set so password managers and assistive technology can pre-populate fields; paste is never blocked; error messages use <code>role='alert'</code> so screen readers announce them immediately; and CAPTCHA has an accessible alternative. These patterns apply equally to loan application forms, funds transfer screens, and account settings pages.</p> <h2>The Third-Party Vendor Problem</h2> <p>One of the thorniest issues in bank accessibility compliance is vendor responsibility. <cite index="8-31">Many banks use online banking portals created and run by third-party vendors.</cite> When those portals are inaccessible, the bank — not the vendor — is the entity that gets sued. Courts have consistently held that outsourcing a function does not outsource legal liability.</p> <p>The EAA is explicit on this point. <cite index="23-15,23-16">Financial firms may be directly in-scope of the EAA, but their downstream providers and suppliers of in-scope services and products may also have obligations under the EAA, or will find their financial services clients flow down obligations to them through contracts.</cite> This means procurement teams need to make accessibility a vendor evaluation criterion, not an afterthought. Every third-party service — payment gateways, loan origination software, customer authentication modules, chatbots, PDF generation engines — must meet the same WCAG standard as first-party code.</p> <p>The integrated journey principle is especially relevant here. <cite index="38-34,38-35,38-36,38-37">A typical transaction consists of several consecutive steps: login, authentication, the transaction itself, and documentation. These steps are interconnected and are often managed by different underlying systems. The critical factor is not whether individual components are accessible, but whether the entire workflow functions. The EAA follows exactly this approach: the user journey is evaluated as a whole, rather than its individual parts.</cite></p> <h2>Compliance Strategy: Moving from Reactive to Proactive</h2> <p>Many financial institutions still treat accessibility as a reactive legal problem — fix things only after receiving a demand letter. That approach is increasingly untenable. <cite index="15-26,15-27">It has been estimated that between 7 and 10 private demand letters are filed for every 1 claim filed in court. These letters commonly warn that legal action will be pursued unless the recipient makes its digital resources accessible.</cite> By the time a formal complaint arrives, the institution has already been identified as a target.</p> <p>A proactive accessibility program in financial services should include the following elements:</p> <ol> <li><strong>Baseline audit across all digital properties.</strong> Commission a combined automated and manual audit of your public website, authenticated banking portal, mobile apps, and critical PDFs. <cite index="31-30">Automated tools detect about 30–40% of WCAG issues</cite>, so manual testing with real assistive technology users is essential to surface the rest.</li> <li><strong>Prioritize core transaction flows first.</strong> <cite index="3-10">Start with core banking functions — account access, transactions, and statements — then expand to additional services.</cite> Fixing the login form, transaction history table, and funds transfer screen delivers the highest impact for users with the most critical needs.</li> <li><strong>Embed accessibility in your SDLC.</strong> Accessibility issues are an order of magnitude cheaper to fix during design and development than after deployment. Include accessibility acceptance criteria in every user story, and integrate automated scanning into your CI/CD pipeline to catch regressions before they reach production.</li> <li><strong>Assess and contract vendors on accessibility.</strong> Require VPAT (Voluntary Product Accessibility Template) documentation from all technology vendors. <cite index="5-33,5-34">If you are working with the Federal Government or any organization that receives government funding, you will need to get a VPAT for all of your digital properties, whether that is your website, mobile app, or customer portal.</cite></li> <li><strong>Train content and compliance teams.</strong> Inaccessible PDFs, poorly written alt text, and unlabeled form fields are often created by non-technical staff. Regular training ensures that accessibility doesn't regress through ordinary content updates.</li> <li><strong>Maintain continuous monitoring.</strong> <cite index="3-11">Continuous monitoring catches issues before they impact customers or trigger complaints.</cite> Deploy automated scanning on a regular cadence and set up alerts when newly deployed pages introduce accessibility regressions.</li> <li><strong>Publish an accessibility statement.</strong> Document your conformance level, known limitations, and a clear feedback channel for users who encounter barriers. This demonstrates good faith and is explicitly required under the EAA.</li> </ol> <h2>The Business Case Beyond Compliance</h2> <p>Compliance requirements are compelling on their own, but the business case for accessible banking runs deeper. <cite index="2-11,2-12">65% of users would switch financial providers for better accessibility features, yet only 48% are satisfied with their current digital banking accessibility features, presenting both a challenge and an opportunity for financial institutions to improve their services.</cite></p> <p><cite index="20-22,20-23,20-24">According to the U.S. Centers for Disease Control and Prevention, 28.7% of adults — more than one in four — in the United States have some type of disability, translating to approximately 70 million adults. When digital assets are inaccessible, over one-quarter of U.S. consumers who could be potential customers are excluded from access to a business's goods and services.</cite> Add family members and caregivers who make financial decisions for people with disabilities, and the total addressable market impact is enormous.</p> <p>Accessible design also systematically improves usability for everyone. Clear form labels, adequate color contrast, and logical keyboard navigation are not just disability accommodations — they are simply good interface design. <cite index="4-12,4-13">Inclusive design helps make everyday services easier to use for people with disabilities, and this is particularly important for financial websites, where users need to access sensitive information and complete transactions securely and independently.</cite> An aging customer base, users on mobile devices in bright sunlight, and anyone operating a phone one-handed all benefit from the same design choices that serve users with permanent disabilities.</p> <p>Reputational risk cuts both ways. <cite index="6-27">A bank that is sued for ADA non-compliance can suffer significant reputational harm, especially if the lawsuit draws media attention.</cite> Conversely, institutions that lead on accessibility build measurable trust and loyalty with customers who have historically been underserved by financial services.</p> <h2>Key Takeaways</h2> <ul> <li><strong>The legal pressure is real and accelerating.</strong> Federal ADA website accessibility lawsuits hit 3,117 in 2025 — a 27% increase — while the European Accessibility Act became enforceable in June 2025 with penalties up to €100,000 or 4% of annual revenue. Financial institutions are in the crosshairs of both frameworks.</li> <li><strong>WCAG 2.1 Level AA is the de facto minimum standard everywhere.</strong> U.S. courts cite it in settlements, the DOJ requires it for Title II entities, and the EAA's technical backbone (EN 301 549) incorporates it directly. Targeting WCAG 2.2 prepares you for the near future while satisfying current requirements.</li> <li><strong>The entire user journey must be accessible — not just the homepage.</strong> Post-login banking portals, transaction flows, account statements, PDF documents, and third-party payment modules all carry equal legal exposure. A service is only compliant if the end-to-end workflow is usable by people with disabilities.</li> <li><strong>Vendor contracts must include accessibility obligations.</strong> Legal liability stays with the bank when a third-party portal fails WCAG. Flow EAA and ADA requirements downstream to every technology vendor and require VPAT documentation before deployment.</li> <li><strong>Proactive remediation is materially cheaper than reactive defense.</strong> Demand letters, settlements, legal fees, court-mandated monitoring agreements, and redesign costs consistently exceed the cost of building accessible products from the outset. Integrate accessibility into your SDLC and procurement processes now.</li> </ul>