Loan application landing pages and the application forms themselves are the highest-stakes accessibility surface on a financial institution's public site. They're also the most-cited surface in ADA Title III complaints against banks, credit unions, and lenders.

This is a focused checklist of what to verify, organized by what plaintiff firms most often cite.

Labels and instructions

Every input field needs a programmatically associated label. Placeholder text disappears as the user types and does not satisfy WCAG 3.3.2.

  • [ ] Every <input>, <select>, and <textarea> has a <label> element with for= matching the input's id
  • [ ] Required fields are marked with text in addition to color or asterisk (<span class="required">required</span>)
  • [ ] Optional fields are explicitly indicated when most fields are required (so users don't have to infer)
  • [ ] Field instructions (e.g., "Format: XXX-XX-XXXX") are programmatically associated via aria-describedby

Error handling

Loan applications are heavy on validation. Error patterns that frequently fail accessibility:

  • [ ] Error messages are programmatically associated with the field via aria-describedby or by inserting the error text immediately after the input
  • [ ] Error states are announced to screen readers via role="alert" or aria-live="polite"
  • [ ] Error icons (red X, exclamation marks) are not the only signal — paired with text
  • [ ] Inline validation does not fire on every keystroke (excessive announcements degrade screen reader UX)
  • [ ] Submit-time validation aggregates errors and provides a summary at the top of the form, with anchor links to each erroring field

Dynamic state

Loan applications often have multi-step flows, conditional fields, and progress indicators. Each requires accessibility consideration:

  • [ ] Progress indicator (e.g., "Step 2 of 4") is programmatically perceivable, not just visual
  • [ ] When fields appear/disappear conditionally (e.g., "if married, show spouse income"), the change is announced
  • [ ] Modal dialogs (e.g., "What is APR?" tooltips) are keyboard-accessible, focus-trapped while open, and dismissable via Escape
  • [ ] The "back" button preserves entered data and screen reader announces the page change

Date pickers and calendars

Date pickers are the single most common accessibility failure on loan applications. Most third-party date-picker components are inaccessible by default.

  • [ ] Date picker is keyboard-operable (arrow keys, page-up/page-down for month, Enter to select)
  • [ ] Date picker has a manual text-entry fallback (MM/DD/YYYY)
  • [ ] Selected date is announced when chosen
  • [ ] Disabled dates (e.g., past dates, holidays) are programmatically marked as disabled, not just visually grayed

If your date picker fails any of these, replace it. The libraries with strong accessibility (react-day-picker, react-aria) are now mature enough that there's no good reason to use an inaccessible one.

File uploads

Loan applications increasingly require document uploads (pay stubs, tax returns, ID).

  • [ ] File input has a clear label
  • [ ] File-type and size restrictions are stated visibly and programmatically
  • [ ] Upload progress and completion are announced
  • [ ] Errors (wrong file type, too large) are announced and clear

CAPTCHA

Most CAPTCHAs are accessibility nightmares. Banks use them on loan applications to prevent fraud, but they need accessible alternatives:

  • [ ] Audio alternative for image-based CAPTCHAs
  • [ ] reCAPTCHA v3 (invisible, no user challenge) preferred over v2 where fraud risk allows
  • [ ] If image CAPTCHA must be used, instructions are clear and the audio alternative is functional

Multi-step navigation

For applications longer than a single page:

  • [ ] Each step has a unique <title> and <h1>
  • [ ] Browser back/forward works correctly
  • [ ] Saving progress is possible (or clearly stated if not)
  • [ ] On submit-error, focus moves to the error summary, not back to the top of the form

Test it yourself, in 15 minutes

  1. Keyboard-only: open your loan application in a browser. Use only Tab, Shift+Tab, Enter, and arrow keys. Note every place focus disappears, every place you can't determine what field you're on, every place a control responds only to mouse.
  2. Screen reader: turn on VoiceOver (Mac), NVDA (Windows), or TalkBack (Android). Navigate the application. Note every place the announcement is wrong or missing.
  3. Mobile: do the same on a phone. Mobile screen readers (TalkBack, VoiceOver iOS) reveal issues desktop testing doesn't.

If your application has more than 5 issues across these tests, you have remediation work to do — and likely demand-letter exposure.

Specific patterns we've seen flagged

From public ADA complaints against banks and credit unions:

  • Co-borrower toggle: a checkbox to add a co-borrower that conditionally reveals a second set of fields, with the new fields not announced and not focus-managed.
  • Income source dropdown: a dropdown that conditionally reveals a "specify other" text field that is unlabeled.
  • Date-of-birth field: three separate inputs for month/day/year with no group label (<fieldset> + <legend>).
  • SSN field: a four-digit input that is not announced as "last four digits of Social Security Number" — just "input."
  • Submit button label: button labeled "Submit" instead of "Submit loan application," providing no context for screen-reader users tabbing through the form.

Each of these is mechanically detectable and would be flagged by continuous scanning.

How does the SEO Score API help?

Our financial services vertical runs WCAG 2.1 AA scans across loan-application landing pages plus the surrounding marketing pages, with examiner-ready timestamped audit logs. We don't scan authenticated pages (online banking, signed-in member portals); the public marketing flow is what's in scope, which is also what's in the demand-letter pattern.

What about live applications behind a login?

Authenticated loan applications (where the borrower has already logged into online banking) require a different audit approach — typically a manual review by a specialist. Our scanner only covers the unauthenticated public flow, but that's where most demand-letter exposure lives anyway.

What's the minimum I should do today?

Three things:

  1. Run a free scan of your loan-application landing page.
  2. Test the application keyboard-only for 15 minutes.
  3. Fix any keyboard-only failures found in step 2 before the next CMS deploy.

Those three steps eliminate the most common demand-letter triggers in a few hours of work.

Run a free scan now →