Why Insurance Websites Fail Accessibility Audits

The problem with insurance websites

Insurance is, at its core, about protection. People buy insurance to protect against risk — health complications, car accidents, property damage, business disruptions. The implicit promise of an insurance product is that when something goes wrong, the insurer will be there.

That promise sits in uncomfortable tension with the reality of most insurance digital platforms, which regularly exclude users with disabilities from the very services designed to protect them.

Quote calculators that can’t be navigated by keyboard. Claim forms with unlabeled inputs. Policy documents distributed as inaccessible PDFs. Customer portals that break when a screen reader is active. These aren’t obscure edge cases — they’re the kind of failures found routinely in accessibility audits of insurance websites.

Under the European Accessibility Act, which came into force on June 28, 2025, these failures carry legal consequences. Insurance companies that provide services to EU consumers are within scope.

The most common insurance accessibility failures

Inaccessible quote tools

Quote calculators are often the first meaningful interaction a potential customer has with an insurance brand. They’re also frequently inaccessible.

Common failures:

• Range sliders for premium values that can only be dragged with a mouse — no keyboard equivalent
• Dropdown menus for policy options that use custom components without correct ARIA roles or keyboard behavior
• Multi-step wizard flows where moving between steps doesn’t manage focus correctly — a screen reader user completes step 2 and has no way of knowing step 3 has appeared

The quote tool is often the highest-priority fix. It’s where the sales journey begins.

Complex forms with missing labels

Insurance applications involve a lot of fields: personal details, address history, claims history, beneficiary information. The density of form fields makes proper labeling even more important — and more commonly overlooked.

The specific failures:

• Fields with placeholder text instead of visible labels (placeholder text disappears when the user starts typing; if it was the only label, the user loses their context)
• Related fields grouped visually but not grouped with <fieldset> and <legend> — screen readers have no way to know the fields relate
• Date fields where the intended format isn’t communicated until after an error occurs

Our guide on accessible error messages covers how to handle validation properly once the form structure is correct.

Inaccessible policy documents

Policy documents, renewal notices, certificates of insurance, and terms and conditions are almost always distributed as PDFs. And almost all insurance PDFs are inaccessible.

The problem is in how they’re created. Documents generated from legacy document management systems, exported from Word without accessibility processing, or produced by PDF generation tools that don’t output tagged content will typically have no reading order, no heading structure, and no alt text for any tables or figures they contain.

A blind user who downloads their policy document to understand what they’re covered for and receives an unreadable wall of content has not been served by their insurer. Under the EAA, this is a compliance failure.

See our PDF accessibility guide for what tagged accessible PDFs require and how to produce them from common sources.

Claim submission flows

The claim submission experience is where inaccessibility has the most direct human cost. A user with a disability — perhaps the very disability that prompted the claim in the first place — needs to be able to submit their claim independently and confidently.

Common claim flow failures:

• File upload components that can’t be operated by keyboard
• Progress indicators that aren’t communicated to screen readers (the user doesn’t know which step they’re on)
• Session timeouts that don’t warn users in advance — a user who takes longer to gather documents may find themselves logged out mid-submission
• Confirmation states that don’t announce to screen readers

Insufficient contrast in customer portal UI

Insurance customer portals often use the brand’s secondary palette for supporting information — policy numbers, coverage limits, renewal dates. Light grey text on white backgrounds is a design trend that consistently fails WCAG 1.4.3 Contrast Minimum (4.5:1 for normal text).

When this information is low-contrast in the portal, users with low vision may not be able to read their own policy details without specific effort to override the styling.

What the EAA requires

Insurance services are explicitly covered by the EAA as a financial services category. The technical standard is WCAG 2.1 Level AA applied across websites, mobile apps, and digital documents.

The EAA also requires a feedback mechanism for users to report accessibility barriers, and a process for providing accessible alternatives where digital content is not yet accessible.

Where to start

Given the typical surface area of an insurance digital estate, prioritize by customer impact:

Highest priority:

1. Quote and purchase flows — this is where new customers are acquired
2. Claim submission — this is where the product’s promise is delivered (or broken)
3. Policy documents — users have a right to understand what they’ve purchased

Second priority:

1. Customer portal core functions: view coverage, manage payments, update details
2. Renewal flows
3. Mobile app equivalents of all of the above

Run automated scanning to catch contrast, labeling, and structural issues across your public-facing pages. For authenticated flows — quote tools with complex state, claim submission, customer portals — automated scanning alone is not sufficient. Manual testing with real assistive technology is necessary to find the keyboard navigation failures and screen reader announcement issues that automated tools miss.

Start with a free scan of your public-facing site to understand the current baseline, then talk to our team about extending testing into the authenticated flows where the most significant customer-facing barriers typically live.