Family welcome & onboarding accessibility audit

Reproduction

1. Open representative React onboarding steps.
2. Inspect document.title on initial load and after client-side navigation.

Observed

`document.title` was empty on welcome, identity verification, concerns, service line, address, card upload, consents, and invalid-link states. Axe reported `document-title` on every scanned state.

Expected

Each page has a unique localized title describing the current step.

Impact

Browser tabs, history, and assistive-technology page identification do not distinguish onboarding steps.

Recommended correction

Define a localized title for the onboarding layout or each step and verify it changes with route navigation.

Verification

Assert the exact title on initial load and after each client-side step transition.

Reproduction

1. Open welcome with locale=es and locale=pt.
2. Compare visible language with the html lang value.

Observed

The Spanish and Portuguese welcome pages rendered localized copy while `<html lang="en">` remained unchanged.

Expected

The page language matches the resolved locale and updates with locale changes.

Impact

Screen readers and other language-aware tools may apply English pronunciation and processing rules to Spanish and Portuguese content.

Recommended correction

Set the document language from the resolved application locale and update it when locale changes.

Verification

Assert `es`, `pt`, and `en` on representative localized routes.

Reproduction

1. Advance from required to optional consents.
2. Inspect repeated Yes/No names and select a response.
3. Inspect role and selected state in the accessibility tree.

Observed

Each consent uses repeated ordinary buttons named only “Yes” and “No.” Selecting one changes colors but adds no `aria-pressed`, `aria-checked`, radio role, or programmatic association with the consent heading.

Expected

Each consent is a named single-choice group with a programmatically exposed selection, not color alone.

Impact

A screen-reader user cannot reliably determine which repeated choice belongs to which consent or which answer is selected.

Recommended correction

Model each pair as a labeled radio group or another standard single-selection control with a programmatic group name and selected value.

Verification

Inspect the accessibility tree and complete all choices using keyboard and screen reader.

Reproduction

1. Tab to a consent Yes or No button.
2. Observe focus without activating it.

Observed

A focused Yes button computed to `outline: none` and `box-shadow: none`. Space activated it, but focus location was not visually apparent.

Expected

Every focused consent choice has a persistent visible focus indicator in standard and forced colors.

Impact

Keyboard users cannot track which legal decision control will be activated.

Recommended correction

Use the shared focus-visible treatment with adequate contrast on both selected and unselected states.

Verification

Tab through every consent choice in default and forced-colors modes.

Reproduction

1. Open insurance card upload.
2. Tab from the preceding control through both visible upload targets.
3. Compare visible card-side text with computed control names.

Observed

Both file inputs use `display: none`; the clickable labels are not focusable. A real Tab sequence skipped both upload controls. The visible “Front of card” and “Back of card (optional)” text sits outside each label and is absent from the input's accessible name.

Expected

Both uploads are keyboard operable and their names include the visible side/required context.

Impact

Keyboard users cannot upload insurance images and assistive-technology users do not receive the card-side or required-state context. Manual entry is available but does not make the upload function keyboard operable.

Recommended correction

Use a visually hidden, focusable file input or keyboard-operable button/label pattern; include side, required state, and helper text in the accessible relationship.

Verification

Tab to each upload, open the file chooser from the keyboard, and inspect names/descriptions.

Reproduction

1. Open optional consents.
2. Activate Read full terms.
3. Inspect the dialog role and computed name.

Observed

The accessibility tree exposed `dialog` with no name. The popup has no `Dialog.Title`, `aria-label`, or `aria-labelledby`.

Expected

The dialog has a visible, programmatically connected title and correct focus behavior.

Impact

Screen-reader users entering high-consequence legal text are not told what dialog opened.

Recommended correction

Add a visible `Dialog.Title` connected to the dialog. Give loading and failure replacements appropriate status semantics.

Verification

Confirm the dialog's computed accessible name; verify initial focus, Escape, focus containment, and focus restoration. Escape and restoration to “Read full terms” passed in this sample.

Reproduction

1. Activate Continue on representative route and internal panel transitions.
2. After the new content settles, inspect document.activeElement and new-view announcement.

Observed

Welcome → identity, verification → concerns, and concerns → service line all left `document.activeElement` on `<body>` after the new view settled. Titles also remained empty.

Expected

Focus moves to a deliberate target and the new context is announced once.

Impact

Keyboard and screen-reader users lose their interaction point and receive no deterministic indication of the new step.

Recommended correction

Establish one route-change strategy that updates the localized title and moves focus to the new primary heading or a deliberate route-status target without causing duplicate announcements.

Verification

Test browser Back/Forward and every step transition with keyboard, VoiceOver/Safari, and NVDA/Chrome or Firefox.

Reproduction

1. Open the carrier search and matching Specialty filter.
2. Inspect each popup role and computed name.

Observed

Opening “Insurance carrier” exposed a popup with `role="dialog"` and no `aria-label` or `aria-labelledby`. The search combobox inside was named, but the containing dialog was not.

Expected

Every dialog popup has a name derived from its visible heading or field label.

Impact

Screen-reader users are not given a programmatic name for the popup context they enter.

Recommended correction

Give the popup a visible or programmatic name derived from its field label, while preserving the names and relationships of the trigger, search input, and listbox.

Verification

Inspect every shared `SearchableSelect` usage and verify popup naming, Escape, keyboard selection, and focus restoration with AT.

Reproduction

1. Enable forced-colors mode.
2. Tab to a waitlist time cell and select it.
3. Inspect computed outline, box-shadow, border, and selected state.

Observed

A focused waitlist availability cell computed to `outline: none` and `box-shadow: none` in Chromium forced-colors mode because the implementation removes the outline and relies on a Tailwind ring. The grid places all 91 cells in the Tab order.

Expected

Focused cells retain a visible system-color indicator and selected state.

Impact

Keyboard users with Windows High Contrast or another forced-colors configuration cannot reliably see which time slot has focus; reaching controls after the grid also requires excessive tabbing.

Recommended correction

Preserve a system-color outline under forced colors. Consider a composite grid or roving-tabindex interaction so arrow keys traverse cells while the grid contributes one Tab stop.

Verification

Check selected and unselected cells with keyboard in Windows High Contrast themes and standard color modes.

Reproduction

1. Navigate from React onboarding to the Rails payment host.
2. Inspect the host html lang and the Stripe iframe language.

Observed

The Rails-rendered payment host page had no `lang` attribute on `<html>`. Axe reported `html-has-lang`. Stripe's embedded document separately declared `lang="en"`.

Expected

Host and embedded documents declare the resolved locale.

Impact

Assistive technology cannot reliably select the correct language rules for Cartwheel's payment instructions surrounding the embedded checkout.

Recommended correction

Set the payment layout's document language from the resolved locale and preserve language across the React-to-Rails handoff.

Verification

Assert the host and embedded-document language for English, Spanish, and Portuguese payment routes.

Reproduction

1. Open the payment handoff.
2. Inspect the host document title.

Observed

The payment host page title was only “Cartwheel,” despite the page purpose being payment-information collection.

Expected

The title identifies Cartwheel and the payment-information step.

Impact

Browser tabs, history, and assistive-technology page lists do not identify this onboarding step.

Recommended correction

Provide a localized title that identifies both Cartwheel and the payment-information step.

Verification

Assert the exact host-page title in each supported locale.

Reproduction

1. Open Finding matches.
2. Inspect the full accessibility tree during and after the animation.
3. Observe whether completion and Continue availability are announced.

Observed

Completed checklist rows simultaneously exposed images named “Loading” and “Done” because CSS opacity and animation changed only the visual presentation. The active row later changed visually and a Continue button appeared, but the checklist had no live or status semantics. The hardcoded English image labels were also exposed in localized flows.

Expected

Each row exposes one current state and completion is announced concisely once.

Impact

Screen-reader users receive contradictory progress states and may not be told when matching is ready or when a new action becomes available.

Recommended correction

Represent each row with one programmatic status at a time, hide replaced decorative graphics, localize any meaningful state labels, and announce concise progress/completion without replaying the whole checklist.

Verification

Observe the complete success, delayed, fallback, and error sequences with VoiceOver and NVDA; ensure each stage has one current state and completion is announced once.

Reproduction

1. Open matching results and navigate by buttons.
2. Open one clinician schedule with a selected slot.
3. Inspect each time name, grouping, and selected state.

Observed

Matching results exposed many repeated buttons named only “7:00 am,” “7:15 am,” and similar values without a programmatic relationship to the visual clinician card or date label. On the clinician schedule, a preselected time changed only border/background classes; it exposed no `aria-pressed`, `aria-checked`, or equivalent selected state.

Expected

Every time has unique date/clinician context and the current selection is programmatically exposed.

Impact

Screen-reader button navigation cannot distinguish appointment choices, and users cannot determine which date/time is currently selected before continuing.

Recommended correction

Give each time control a name or description containing the full date and relevant clinician context, group controls under programmatic date/clinician labels, and expose selection with a standard radio or toggle pattern.

Verification

Navigate matching and schedule controls by buttons, groups, and form controls in VoiceOver and NVDA; confirm every choice is unique and the selected slot is announced.

Reproduction

1. Open reassurance and the post-insurance interstitial.
2. Wait without interaction and observe route timing.
3. Repeat with reduced motion.

Observed

The reassurance screen and post-insurance “You're in the right place” interstitial each navigated away after three seconds. Users could not turn off, adjust, extend, pause, or manually advance the limit. Reduced-motion preference did not stop the reassurance animation or timeout.

Expected

Content remains until user action or offers a conforming pause/extend mechanism.

Impact

Users who need more time to read, understand, magnify, or translate content can lose it before finishing and may be disoriented by the unsolicited route change.

Recommended correction

Remove the automatic limit and provide a clear Continue action, or offer a conforming mechanism to pause/extend it. Respect reduced-motion for nonessential animation independently.

Verification

Confirm content remains until the user advances it; test keyboard, magnification, reduced motion, and screen readers.

Reproduction

1. Open representative option-set screens.
2. Navigate by radio, checkbox, or form controls.
3. Inspect each group name.

Observed

Joint-custody, insurance self-report, service-line, and consent choices expose individually named controls but do not connect their visual question to the radio, checkbox, or button group with `fieldset`/`legend`, `aria-labelledby`, or an equivalent name. Rendered accessibility trees showed unnamed radio groups.

Expected

Every related option set has a programmatic name matching its visible question.

Impact

Screen-reader users navigating by form controls lose the question that gives repeated answers such as Yes, No, or No preference their meaning.

Recommended correction

Use native `fieldset`/`legend` where practical or give each group a stable accessible name derived from its visible prompt.

Verification

Navigate each set by form controls with VoiceOver and NVDA and confirm the question is announced with the options.

Reproduction

1. Open Spanish welcome FAQ and inspect Close.
2. Review localized matching/loading/completion source and rendered states.
3. Compare dates, control names, and status text with active locale.

Observed

The Spanish welcome FAQ exposed its close control as “Close.” Matching filters, loading/error text, and date/time formatters include hardcoded English; shared loading status uses “Loading...” instead of the localized visible context. Completion formatters force `en-US` output in Spanish and Portuguese flows.

Expected

All content and accessible names use the active locale or declare intentional language changes.

Impact

Families using Spanish or Portuguese can encounter controls and essential scheduling information they cannot understand or that assistive technology pronounces using the wrong language rules.

Recommended correction

Route all user-facing and accessible strings through i18n, format dates/times with the active locale, and use `lang` only for intentionally retained foreign-language parts.

Verification

Complete matching, scheduling, consent, payment, and completion in Spanish and Portuguese while inspecting visible copy and computed names.