Insurance Website Accessibility: Quote Forms, Documents, and EAA/ADA Compliance

Insurance products are legally binding contracts sold through interfaces of real complexity. A homeowner comparing deductibles, a disabled veteran filing a disability claim, or an older adult renewing auto coverage are all squarely within your customer base and disproportionately likely to rely on assistive technology. When the quote flow or claims portal is unusable, you do not just lose a sale; you may exclude a protected group from a financial service.

The regulatory picture reinforces this. The EAA (Directive (EU) 2019/882) reaches consumer banking and many insurance services, with conformance demonstrated against EN 301 549, which incorporates WCAG 2.2 Level A and AA. US ADA litigation names no specific WCAG version, but courts and settlements treat 2.1/2.2 AA as the working standard. If you operate in both markets, building to WCAG 2.2 AA satisfies both at once and, as a superset, also covers Section 508 and Ontario's AODA, which are still pegged to WCAG 2.0 AA.

The quote funnel is where most insurance website accessibility problems concentrate, because it combines long forms, conditional logic, and time pressure. Get the fundamentals right here first.

• Programmatic labels and errors: every field needs a real label associated with its input, not just placeholder text. When validation fails, identify the error in text (SC 3.3.1 Error Identification, Level A), suggest a correction where you can (SC 3.3.3 Error Suggestion, Level AA), and move focus or announce it via a live region so screen reader users are not stranded (SC 4.1.3 Status Messages, Level AA).
• Redundant Entry (SC 3.3.7, Level A, new in WCAG 2.2): if a multi-step quote already collected the applicant's address, do not force re-entry on the payment step. Auto-populate or let them select the prior value.
• Accessible Authentication, Minimum (SC 3.3.8, Level AA): member portals must not rely on a cognitive function test such as transcribing a code from memory with no alternative. Allow password managers, copy-paste, and email or app-based options.
• Target Size, Minimum (SC 2.5.8, Level AA): interactive controls such as the plus/minus steppers for number of drivers or dependents must be at least 24 by 24 CSS pixels, unless a documented exception applies.
• Dragging Movements (SC 2.5.7, Level AA): any coverage slider must also be operable by a single pointer without dragging, for example by clicking a track position or typing a value.
• Error Prevention (SC 3.3.4, Level AA): before a binding purchase, let users review, correct, and confirm. This is both a usability win and an explicit AA requirement for legal and financial commitments.

For patterns and code-level detail, the guide to accessible forms walks through label association, fieldset grouping, and error handling end to end.

Insurers run on documents, and most of them are PDFs. A Schedule of Benefits exported straight from a layout tool, or a scanned policy wording, is typically untagged: a screen reader sees one undifferentiated blob or, worse, an image with no text at all. Under both the EAA and ADA, a document you deliver as part of your service is in scope.

• Tag the reading order and structure so headings, paragraphs, and lists are exposed to assistive technology.
• Set the document title and language so the screen reader announces the file correctly and pronounces it in the right language (mirroring SC 3.1.1 Language of Page and 3.1.2 Language of Parts for HTML).
• Add alternative text to charts and diagrams, such as a benefits illustration or a network map.
• Tag tables with header cells so a premium table is navigable cell by cell rather than read as a flat run of numbers.

Where you can, offer an accessible HTML version of key documents alongside the PDF; HTML is far easier to keep conformant and to retest as policies change.

Rate cards and plan-comparison grids are the densest content on an insurance site, and they are routinely built as visual layouts that mean nothing to a screen reader. The fix is semantic HTML, not a screenshot or a stack of divs.

• Use real table elements with th for header cells and the scope attribute (scope="col" or scope="row") so each premium value is tied to its plan and its row label.
• For comparison tables with both a plan dimension and a coverage dimension, associate data cells with their headers so a user landing on a single figure hears something like 'Gold plan, annual deductible, 1,500'.
• Add a caption or accessible name describing what the table shows.
• Do not rely on color alone to flag the recommended or most-popular plan; pair the color with text or an icon that has a text alternative. Keep contrast at 3:1 for that UI emphasis and large text (18pt, or 14pt bold) and 4.5:1 for normal body text.

If a table grows wide enough to scroll horizontally on mobile, make sure it remains keyboard reachable and does not trap focus.

Automated scanning catches a large share of issues fast, especially contrast, missing labels, alt text, and heading order, but it cannot confirm that a five-step quote flow is actually completable with a keyboard and a screen reader. Combine both. Run the free checker at /#scan against your quote start page, member login, and a representative document landing page, then do manual keyboard and screen reader passes on the funnel itself.

Build the work into a repeatable process with the accessibility checklist, and publish an accessibility statement describing your conformance level, known limitations, and a contact route for users who hit a barrier. Both the EAA and good ADA practice expect that kind of transparency. The statement generator produces a starting draft you can tailor to your carrier's specifics.