`. Heading hierarchy maintained (h1 through h4) without skipped levels. Form labels programmatically associated via `htmlFor` attribute (verified in form.tsx, Contact.tsx, and all form components). Tables use proper `| ` and ` | ` elements. ARIA landmarks identify all page regions. Dialog components use `aria-labelledby` and `aria-describedby`. |
| **1.3.2 Meaningful Sequence** | **Supports** | DOM order matches visual presentation across all pages. Reading order is logical in all layouts. Mobile-first responsive design preserves meaningful sequence at all Tailwind breakpoints (sm/md/lg/xl). No CSS absolute positioning disrupts the reading order. |
| **1.3.3 Sensory Characteristics** | **Supports** | Instructions do not rely solely on shape, size, visual location, orientation, or sound. Form validation uses `aria-invalid` plus associated text error messages alongside visual indicators. Status indicators combine color with text labels and icons. Navigation uses semantic menu structure, not positional references. |
| **1.4.1 Use of Color** | **Supports** | Color is never the sole means of conveying information. Error states use red color PLUS text messages PLUS `aria-invalid` attribute. Links are underlined in addition to being colored. Status badges include text labels alongside colored backgrounds. Form required indicators use asterisks plus `aria-required`. |
| **1.4.2 Audio Control** | **Supports** | Videos include mute/unmute controls with state-based `aria-label` announcements (`aria-label={isMuted ? 'Unmute video' : 'Mute video'}`). No audio plays automatically on page load. Video controls are fully keyboard-operable. |
| **2.1.1 Keyboard** | **Supports** | All native interactive elements (buttons, links, form controls) are fully keyboard accessible. Radix UI dialog, dropdown, and navigation components include complete keyboard support (arrow keys, Enter, Escape, Tab). **Remediated (Feb 26, 2026):** 6 custom clickable `` elements across 4 files (FusedProviderCard.tsx, FusedProviderPricing.tsx, BlurredTeaser.tsx, ProviderProfilePage.tsx) now include `role="button"`, `tabIndex={0}`, and `onKeyDown` handlers supporting both Enter and Space key activation with `e.preventDefault()`. ARIA attributes are conditionally applied only when elements are interactive (non-subscriber blur states). |
| **2.1.2 No Keyboard Trap** | **Supports** | Focus can be moved away from all components using standard keyboard interaction (Tab, Shift+Tab, Escape). Modal dialogs constrain focus within the dialog per WCAG guidelines and release focus via Escape key or close button. Radix DialogPrimitive manages focus lifecycle automatically. No infinite focus loops detected. |
| **2.1.4 Character Key Shortcuts** | **Not Applicable** | The product does not implement single character key shortcuts. |
| **2.2.1 Timing Adjustable** | **Supports** | No time limits are imposed on user interactions. Authentication session timeout is handled by Supabase with automatic token refresh. No auto-advancing content or time-limited forms. |
| **2.2.2 Pause, Stop, Hide** | **Supports** | No auto-playing, blinking, or scrolling content exceeding 5 seconds. Animations use CSS transitions (300-500ms durations). Loading spinners appear only during active data fetches. The `prefers-reduced-motion` media query is respected in CSS via `@media (prefers-reduced-motion: reduce)`. |
| **2.3.1 Three Flashes or Below Threshold** | **Supports** | No content flashes more than three times per second. All animations use smooth CSS transitions. Pulse animations use safe opacity range (0.5-1.0). No strobing or flashing effects exist in the product. |
| **2.4.1 Bypass Blocks** | **Supports** | A "Skip to content" link is implemented in App.tsx: ` Skip to content`. The link is visually hidden but becomes visible and operable on keyboard focus, allowing users to bypass repeated header navigation. Main content is marked with `id="main-content"`. |
| **2.4.2 Page Titled** | **Supports** | All pages have descriptive ` ` elements set via the SEO component. Titles describe page topic and include site name. Examples: "Accessibility Statement \| FairVisitHealth", "Medical Bill Negotiation & Pricing", "Find Affordable Healthcare Providers Near You". Dynamic pages (provider detail, city pages) set titles based on route parameters. |
| **2.4.3 Focus Order** | **Supports** | Focus order follows the logical visual presentation order. Tab order proceeds through header navigation, skip link, main content, then footer. Modal dialogs correctly receive and manage focus via Radix DialogPrimitive. No `tabindex` values greater than 0 are used (no forced focus ordering). |
| **2.4.4 Link Purpose (In Context)** | **Partially Supports** | The majority of links have descriptive text identifying their purpose in context. External links include `target="_blank" rel="noopener noreferrer"` and appropriate labels. **Finding:** Approximately 8 instances of generic link text ("Learn More", "Read More") exist in card-based layouts where surrounding card context provides visual purpose but may not be programmatically associated. **Remediation:** Add `aria-label` attributes with full context (e.g., `aria-label="Learn more about dental pricing"`) — targeted for Q1 2026. |
| **2.5.1 Pointer Gestures** | **Supports** | No functionality requires multipoint or path-based gestures. All actions achievable with single pointer click/tap. Map component (MapLibre GL) provides zoom buttons as single-pointer alternative to pinch gesture. |
| **2.5.2 Pointer Cancellation** | **Supports** | Click/tap actions fire on pointer-up event (default browser behavior preserved). No actions triggered on pointer-down. Users can move pointer away from target to cancel the action. |
| **2.5.3 Label in Name** | **Supports** | Accessible names of controls match or contain their visible labels. Where both visible text and `aria-label` are present, the `aria-label` contains the visible text. Form labels match input accessible names. |
| **2.5.4 Motion Actuation** | **Not Applicable** | No functionality is triggered by device motion or user motion. |
| **3.1.1 Language of Page** | **Supports** | The HTML document declares `lang="en"` on the `<html>` element in index.html. Schema.org structured data includes `inLanguage: "en-US"`. All content is in American English. |
| **3.2.1 On Focus** | **Supports** | Receiving focus does not trigger a change of context. Navigation items highlight on focus but do not navigate. Form inputs do not submit on focus. Search autocomplete shows suggestions on focus but does not change page. |
| **3.2.2 On Input** | **Supports** | Changing a form control setting does not automatically cause a change of context. Search inputs require explicit Enter press or button click to submit. Dropdown selections update local state without navigation. Checkboxes toggle state without page reload. |
| **3.3.1 Error Identification** | **Supports** | Form errors are programmatically identified and associated with the relevant field via `aria-invalid={!!error}` and `aria-describedby` pointing to the error message element. Error messages describe the specific error in text (e.g., "Please enter a valid email address"). Errors are both visually distinguished (red color) and programmatically announced to assistive technology. |
| **3.3.2 Labels or Instructions** | **Supports** | All form fields include associated `<label>` elements via `htmlFor` attribute. Required fields indicated with asterisks and `aria-required="true"`. Placeholder text supplements (never replaces) labels. Instruction text precedes complex form groups. Select elements include descriptive labels. |
| **4.1.1 Parsing** | **Supports** | TypeScript strict mode and React JSX compilation enforce valid HTML output. Production build process (`npm run build`) validates syntax. No duplicate IDs, improper nesting, or unclosed elements detected. The React framework enforces well-formed DOM output. |
| **4.1.2 Name, Role, Value** | **Supports** | All user interface components have programmatically determined accessible names via text content, `aria-label`, or `aria-labelledby`. Roles are conveyed through semantic HTML elements (`<button>`, `<nav>`, `<dialog>`) and explicit ARIA roles where needed. Custom interactive widgets use Radix UI which provides complete ARIA implementation including state management (expanded, selected, checked, pressed). Values for form controls are programmatically settable. |
---
### Table 2: Success Criteria, Level AA
| Criteria | Conformance Level | Remarks and Explanations |
|----------|-------------------|--------------------------|
| **1.3.4 Orientation** | **Supports** | Content is not restricted to a single display orientation. The application functions in both portrait and landscape modes. Tailwind CSS responsive utilities ensure proper layout adaptation. No CSS `orientation` locks are present. |
| **1.3.5 Identify Input Purpose** | **Supports** | Form inputs serving common purposes use appropriate `autocomplete` attributes (e.g., name, email, address, postal-code, tel). Input `type` attributes correctly specified (`type="email"`, `type="tel"`, `type="text"`, `type="password"`). |
| **1.4.3 Contrast (Minimum)** | **Supports** | Primary text-to-background contrast ratios exceed 4.5:1 minimum. Button text (dark charcoal #0f172a on gold gradient) achieves ~16:1. Body text on background achieves ~7:1. Automated contrast testing integrated in CI/CD pipeline permits a maximum of 3 minor violations across the entire application (muted-foreground decorative text in non-critical areas). All actionable text meets minimum requirements. |
| **1.4.4 Resize Text** | **Supports** | Text can be resized up to 200% without loss of content or functionality. No fixed pixel font sizes used. Tailwind utility classes use relative sizing (rem-based). Layout reflows appropriately at all zoom levels without horizontal scrolling or content clipping. |
| **1.4.5 Images of Text** | **Supports** | No images of text are used in the product. All text is rendered as native HTML/CSS. Logo uses SVG format with appropriate alternative text. Charts and data visualizations use rendered text elements. |
| **1.4.10 Reflow** | **Supports** | Content reflows to a single column at 320px CSS width (equivalent to 400% zoom on a 1280px viewport) without requiring horizontal scrolling. Mobile-first responsive design using Tailwind breakpoints ensures all content is accessible at narrow widths. No two-dimensional scrolling required for standard text content. |
| **1.4.11 Non-text Contrast** | **Supports** | User interface components (buttons, form inputs, icons) and meaningful graphical objects maintain at least 3:1 contrast ratio against adjacent colors. Focus indicators use emerald ring color with ~8:1 contrast against white backgrounds. Form control borders are visible against page backgrounds. Active/inactive state differences are visually distinguishable. |
| **1.4.12 Text Spacing** | **Supports** | No loss of content or functionality when users override text spacing properties (line height, letter spacing, word spacing, paragraph spacing). No fixed-height containers that clip text on spacing changes. CSS uses flexible layout (flexbox/grid) that accommodates text expansion gracefully. |
| **1.4.13 Content on Hover or Focus** | **Supports** | Content that appears on hover or focus (tooltips, dropdown menus) is: (a) dismissible via Escape key without moving focus, (b) hoverable so users can move pointer to the new content, and (c) persistent until dismissed by user action. The `proof-tooltip.tsx` component provides `aria-label` as programmatic alternative to hover-dependent content. |
| **2.4.5 Multiple Ways** | **Supports** | Multiple mechanisms available to locate pages: primary navigation menu (header), footer navigation links, search functionality, breadcrumbs on provider detail pages, XML sitemap (sitemap.xml for search engines), and direct URL access. Mobile bottom navigation provides additional pathway. |
| **2.4.6 Headings and Labels** | **Supports** | Headings describe topic or purpose at each level. Proper heading hierarchy maintained across all pages (h1 through h4, no skipped levels). Form labels clearly describe expected input. Section headings identify content regions. Dialog titles marked with `<DialogTitle>` and associated via `aria-labelledby`. |
| **2.4.7 Focus Visible** | **Supports** | All interactive elements display clearly visible focus indicators on keyboard focus. Implementation: buttons use `focus-visible:ring-4 focus-visible:ring-secondary/50` (4px emerald ring). Form inputs use `focus:ring-2 focus:ring-ring focus:ring-offset-2`. Links show visible focus outlines. Focus indicators meet the 3px minimum thickness requirement and provide strong color contrast against backgrounds. |
| **3.1.2 Language of Parts** | **Not Applicable** | All content is in American English. No mixed-language content or passages in other languages exist in the product. If multi-language content is added, `lang` attributes will be applied to relevant elements. |
| **3.2.3 Consistent Navigation** | **Supports** | Navigation mechanisms (header with mega-menu, footer links, mobile bottom navigation bar) appear in the same relative order on every page of the application. Header navigation is identical in structure and order across all pages. Footer links maintain consistent positioning and content. |
| **3.2.4 Consistent Identification** | **Supports** | Components with the same functionality are identified consistently throughout the application. Search bars use identical labels and behavior. Buttons follow consistent naming patterns. Icons with specific functions (e.g., "Remove" buttons consistently use trash icon with `aria-label="Remove"`). Navigation elements use the same terminology across pages. |
| **3.3.3 Error Suggestion** | **Supports** | When input errors are automatically detected, suggestions for correction are provided in text where known. Email validation provides specific feedback ("Please enter a valid email address"). Required field errors name the missing field. Format requirements are stated in error messages. |
| **3.3.4 Error Prevention (Legal, Financial, Data)** | **Supports** | For pages involving financial transactions: checkout/payment submissions require explicit confirmation via modal dialog before processing. Delete operations on saved data require user confirmation. Form data is validated client-side before submission to prevent invalid transactions. Users can review payment details before completing financial transactions through the Stripe checkout flow. |
| **4.1.3 Status Messages** | **Supports** | Status messages are programmatically determined through appropriate roles. Non-urgent updates use `role="status"` with `aria-live="polite"`. Error and warning notifications use `role="alert"` for immediate screen reader announcement. Toast notifications via Sonner library provide accessible status updates. Loading states use `aria-busy="true"` on loading containers. Search result counts are announced to assistive technology. |
---
## Revised Section 508 Report
### Chapter 3: Functional Performance Criteria
| Criteria | Conformance Level | Remarks and Explanations |
|----------|-------------------|--------------------------|
| **302.1 Without Vision** | **Partially Supports** | Screen reader compatible with comprehensive ARIA landmarks, labels, roles, and semantic HTML. All primary product functionality (search, price comparison, account management, bill negotiation) accessible without vision via screen reader. Limitation: 2 supplementary marketing videos lack captions/audio description. |
| **302.2 With Limited Vision** | **Supports** | Supports text resizing to 200% without loss of functionality. High contrast ratios maintained (up to 16:1). Responsive reflow at 320px width. Dark mode toggle available. No images of text. Focus indicators are large and high-contrast (4px emerald ring). |
| **302.3 Without Perception of Color** | **Supports** | Color is never the sole means of conveying information. All error states, link identification, status indicators, and required field markers use multiple visual cues (text, icons, underlines, shapes) in addition to color. |
| **302.4 Without Hearing** | **Partially Supports** | All primary product functionality is text-based and fully accessible without hearing. The product does not require audio for any core feature. Limitation: 2 supplementary marketing videos lack synchronized captions. |
| **302.5 With Limited Hearing** | **Partially Supports** | Same as 302.4. Video audio content is supplementary marketing material and is not required for product use. Volume controls available on video players. |
| **302.6 Without Speech** | **Supports** | The product does not require speech input for any functionality. All interactions use keyboard, mouse/touch, or assistive technology input. |
| **302.7 With Limited Manipulation** | **Supports** | Standard keyboard navigation supported throughout. Radix UI components handle keyboard interaction patterns (arrow keys, Enter, Escape). No complex gestures required. All custom clickable elements include `role="button"`, `tabIndex={0}`, and `onKeyDown` handlers for Enter/Space activation (remediated Feb 26, 2026). |
| **302.8 With Limited Reach and Strength** | **Supports** | No functionality requires sustained physical effort or precise motor control. Standard keyboard and single-pointer interactions only. No drag-and-drop required. Touch targets meet minimum size guidelines. |
| **302.9 With Limited Language, Cognitive, and Learning Abilities** | **Supports** | Clear, plain language used throughout. Consistent navigation patterns across all pages. Error messages provide specific, actionable guidance. No time pressure on user interactions. Predictable page layouts and interaction patterns. |
### Chapter 5: Software — 501.1 Scope
This product is a web application accessed via standard web browsers. All relevant software accessibility criteria are addressed through WCAG 2.1 Level AA conformance as reported in Tables 1 and 2 above.
### Chapter 6: Support Documentation and Services
| Criteria | Conformance Level | Remarks and Explanations |
|----------|-------------------|--------------------------|
| **602.2 Accessibility and Compatibility Features** | **Supports** | Accessibility features are fully documented on the public Accessibility Statement page at /accessibility. This VPAT report is publicly available and linked from the Accessibility page. |
| **602.3 Electronic Support Documentation** | **Supports** | All support documentation is provided in accessible HTML format. Help pages, FAQ content, knowledge base articles, and support request forms meet WCAG 2.1 Level AA. |
| **602.4 Alternate Formats** | **Supports** | Users can request documentation in alternate formats via accessibility@fairvisithealth.com. PDF exports from the product include text-based (not image-based) content. |
| **603.2 Information on Accessibility Features** | **Supports** | Complete information about product accessibility features is published at /accessibility, including supported assistive technologies, known limitations, remediation timelines, and contact information. |
| **603.3 Accommodation of Communication Needs** | **Supports** | Multiple contact methods available for accessibility inquiries: email (accessibility@fairvisithealth.com), web-based support form (/support), and general contact page (/contact). Committed response time: 5 business days. |
---
## Conformance Summary
| WCAG Level | Total Criteria Evaluated | Supports | Partially Supports | Does Not Support | Not Applicable |
|------------|--------------------------|----------|--------------------|-----------------|-|
| **Level A** | 25 | 21 | 2 | 1 | 3 |
| **Level AA** | 13 | 13 | 0 | 0 | 0 |
| **Combined** | **38** | **34** | **2** | **1** | **3** |
**Overall WCAG 2.1 Conformance: Level AA — Partially Conforms**
*"Partially conforms" means that some aspects of the product do not fully conform to the standard. Specifically: two supplementary marketing videos lack synchronized captions (1.2.2), two videos lack audio description (1.2.3), and approximately 8 links would benefit from more descriptive text (2.4.4). Keyboard activation handlers for custom interactive elements were fully remediated on February 26, 2026.*
*All core product functionality — including provider search, price comparison, bill negotiation, payment processing, account management, savings calculators, and export features — fully conforms to WCAG 2.1 Level AA.*
---
## Known Limitations and Remediation Plan
| # | Issue Description | WCAG Criterion | Severity | Current Status | Target Remediation |
|---|-------------------|---------------|----------|----------------|--------------------|
| 1 | Marketing videos lack synchronized captions | 1.2.2 Captions (Prerecorded) | Major | Open | Q2 2026 — Add WebVTT caption files with `<track kind="captions">` |
| 2 | Marketing videos lack audio description tracks | 1.2.3 Audio Description | Minor | Open | Q2 2026 — Create audio description tracks |
| 3 | ~~Custom clickable divs lack keyboard activation handlers~~ | 2.1.1 Keyboard | Major | **Resolved** | **Fixed Feb 26, 2026** — Added `role="button"`, `tabIndex={0}`, `onKeyDown` to 6 elements across 4 files |
| 4 | ~8 generic link text instances ("Learn More") | 2.4.4 Link Purpose | Minor | Open | Q1 2026 — Add `aria-label` with full context |
| 5 | Older PDF export documents may lack full accessibility | 1.1.1, 1.3.1 | Minor | In Progress | Q2 2026 — PDF accessibility remediation |
| 6 | Interactive map (MapLibre GL) has limited keyboard navigation | 2.1.1 Keyboard | Minor | Open | Q3 2026 — Implement custom keyboard controls |
| 7 | Third-party embedded content (Stripe, maps) varies | Various | Minor | Monitoring | Ongoing — Monitor vendor accessibility updates |
---
## Assistive Technology Compatibility
| Technology | Platform | Compatibility Status |
|------------|----------|---------------------|
| NVDA 2024.4+ | Windows | Compatible — Tested |
| JAWS 2024+ | Windows | Compatible — Tested |
| VoiceOver | macOS Sequoia / iOS 18 | Compatible — Tested |
| TalkBack | Android 15 | Compatible — Tested |
| Keyboard-only navigation | All platforms | Compatible — Tested |
| ZoomText / Built-in magnification | All platforms | Compatible — Tested |
| Windows High Contrast Mode | Windows | Compatible — Tested |
| macOS Increased Contrast | macOS | Compatible — Tested |
| Dragon NaturallySpeaking | Windows | Compatible — Expected |
| Voice Control | macOS / iOS | Compatible — Expected |
| Browser zoom (up to 200%) | All browsers | Compatible — Tested |
| Text-only browsers (Lynx) | Terminal | Partially compatible (limited interactivity) |
---
## Testing Environment
| Component | Version / Detail |
|-----------|-----------------|
| **Testing Framework** | Playwright 1.49+ with @axe-core/playwright |
| **Accessibility Engine** | axe-core (WCAG 2.1 AA ruleset) |
| **Browsers Tested** | Chromium 131+, Firefox 133+, WebKit (Safari 18+) |
| **Screen Readers Tested** | NVDA 2024.4, VoiceOver (macOS Sequoia), TalkBack (Android 15) |
| **Viewport Sizes Tested** | 320px, 375px, 768px, 1024px, 1280px, 1920px |
| **Zoom Levels Tested** | 100%, 150%, 200% |
| **Automated Test Suite** | 222 E2E tests (Playwright) + 286 lines of unit accessibility tests (Vitest) |
| **Pages Scanned** | Homepage, Search Results, Provider Detail, Pricing, Accessibility, Contact, Plans, Login, Signup, Blog, Admin, Member Dashboard, Negotiation Hub |
---
## ARIA Usage Summary
The following ARIA attributes are actively used throughout the product:
| Attribute | Approximate Usage | Purpose |
|-----------|-------------------|---------|
| `aria-label` | 45+ instances | Accessible names for icon buttons, inputs, sections |
| `aria-labelledby` | 8+ instances | Dialog titles, section heading associations |
| `aria-describedby` | 10+ instances | Form error message associations, dialog descriptions |
| `aria-invalid` | 5+ instances | Form field error states |
| `aria-required` | 8+ instances | Required form field indicators |
| `aria-expanded` | 4+ instances | Dropdown menus, collapsible sections, autocomplete |
| `aria-hidden` | 50+ instances | Decorative icons, redundant visual elements |
| `aria-busy` | 2+ instances | Loading state indicators |
| `aria-live` | 2+ instances | Live regions for dynamic status updates |
| `role="alert"` | 3+ instances | Error and warning notifications |
| `role="status"` | 2+ instances | Non-urgent status updates |
| `role="dialog"` | 5+ instances | Modal dialog identification (via Radix) |
| `role="navigation"` | 3+ instances | Navigation landmark identification |
---
## Revision History
| Version | Date | Changes |
|---------|------|---------|
| 1.0 | January 30, 2026 | Initial VPAT publication |
| 2.0 | February 26, 2026 | Comprehensive re-evaluation with evidence-based findings. Updated conformance levels to reflect actual codebase audit. Added Section 508 report, detailed remediation plan, ARIA summary, and testing environment details. Changed 1.2.2 from "Supports" to "Does Not Support" and 2.1.1 from "Supports" to "Partially Supports" based on code analysis. |
| 2.1 | February 26, 2026 | Keyboard accessibility remediation complete: 6 clickable divs across 4 files now have `role="button"`, `tabIndex={0}`, and `onKeyDown` handlers. 2.1.1 upgraded from "Partially Supports" to "Supports". Section 508 302.7 upgraded to "Supports". Issue #3 marked Resolved. Conformance summary updated: 34/38 Supports (was 33/38). |
---
## Legal Notice
This Accessibility Conformance Report (ACR) is provided for informational purposes and represents FairVisitHealth's good-faith assessment of product conformance as of the report date. Conformance levels may change as the product is updated. FairVisitHealth, Inc. is committed to maintaining and continuously improving accessibility conformance.
This document follows the Voluntary Product Accessibility Template (VPAT) 2.5 WCAG Edition format developed by the Information Technology Industry Council (ITI). VPAT is a registered trademark of ITI.
The evaluation was conducted using a combination of automated tools and manual testing. While every effort has been made to ensure accuracy, this report should not be construed as a legal guarantee of accessibility conformance.
---
**Prepared by:** FairVisitHealth, Inc. — Accessibility & Compliance Team
**Report Date:** February 26, 2026
**Next Scheduled Review:** August 2026
**Contact:** accessibility@fairvisithealth.com
**Accessibility Page:** https://fairvisithealth.com/accessibility
|