Accessibility Statement

Vektor Health is committed to making our website accessible to as many people as possible, including people with disabilities. We target conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, the standard set by the World Wide Web Consortium (W3C) and adopted under U.S. federal accessibility law (Section 508 and the ADA Title III interpretive framework).

Healthcare information should be reachable by everyone — and patients with disabilities are disproportionately likely to need the kind of care we provide. Accessibility is not a checklist item for us; it's table stakes.

The Vektor Health website is designed and tested against WCAG 2.1 Level AA. We regularly review the site against these guidelines, including automated and manual checks.

We aim for full conformance, but cannot claim perfect compliance across every page at every moment. If you encounter a barrier, please report it (see the Feedback section below) and we will address it as soon as possible.

Structure and navigation

• Skip-to-content link: keyboard and screen-reader users can jump past the header directly to the main content area on every page
• Semantic HTML landmarks: every page uses proper header, main, nav, article, and footer elements so assistive technology can navigate efficiently
• Heading hierarchy: pages use sequential heading levels (h1 → h2 → h3) without skipping, so screen-reader users can navigate by heading and understand page structure
• Breadcrumbs: long-form pages (blog posts, treatments, legal documents) include a visible breadcrumb back to the parent page

Keyboard and focus

• Full keyboard navigation: every interactive element is reachable and operable using only a keyboard. There are no mouse-only interactions
• Visible focus rings: a clear, high-contrast focus indicator appears on every focusable element so keyboard users can always see where they are
• Logical tab order: focus order follows the visual reading order on every page
• Mobile menu Escape support: the mobile navigation menu closes when the Escape key is pressed

Visual design

• Color contrast: body text meets a contrast ratio of at least 4.5:1 against the page background. Headings and large text meet at least 3:1
• No color-only meaning: information is never conveyed by color alone. Form errors, status indicators, and badges always include text or an icon
• Readable font size: body text starts at 16px or larger. Mobile font sizing avoids the iOS zoom-on-focus issue
• Responsive layout: pages reflow cleanly at 320px width, 200% zoom, and across screen orientations without horizontal scrolling

Forms and feedback

• Labeled inputs: every form field has a visible, programmatically associated label
• Inline error messages: validation errors appear next to the field they describe, with the error linked to the input via aria-describedby
• Submit feedback: forms visibly indicate loading and success states; users always know whether a submission succeeded

Motion and animation

• Reduced motion respected: users who set the prefers-reduced-motion preference at the OS level see static or minimally-animated transitions instead of motion effects
• Decorative animations are short (under 300ms) and never block interaction

Images and media

• Alt text: meaningful images have descriptive alt text. Decorative images are marked aria-hidden so screen readers skip them
• Icon-only buttons: buttons that show only an icon (e.g., the mobile menu toggle) have an aria-label describing their purpose

Assistive-technology testing

• We test with VoiceOver (macOS / iOS), NVDA (Windows), and keyboard-only navigation as part of our development workflow
• Each major release goes through a manual a11y review against the WCAG 2.1 AA criteria

We are honest about gaps. The following items are known issues we are tracking and working to address:

• Embedded third-party content (such as future payment-form embeds from Stripe Checkout) may not fully meet our internal standard. We work with vendors to push them toward conformance and will document known issues here when they apply
• Live signup counter on the homepage and pricing page uses CSS-driven motion. Users with reduced-motion enabled see the static fallback; users without see a 700ms ease-in animation. If this is a barrier, please let us know

If you discover a barrier we have not listed here, please report it — see Feedback below.

If you encounter an accessibility barrier on the Site, or have a suggestion for how we could improve, please reach out. We commit to:

• Acknowledging your message within 2 business days
• Providing a substantive response within 10 business days, including a description of the issue we identified, what we plan to do about it, and a target timeline
• Offering an alternative way to access the information you needed in the meantime, where possible

Reach us

• Email: hello@vektor.health
• Subject line: please include “Accessibility”
• Helpful detail (optional): the page URL, what you were trying to do, and the assistive technology and browser you were using

The Vektor Health website is built with the following technologies and follows accessibility-focused practices in each:

• HTML5 with semantic landmarks and ARIA where needed
• CSS (Tailwind) with prefers-reduced-motion queries respected
• React 18 with Next.js 15 App Router and Server Components
• Cloudflare Workers (Edge runtime) — no client-side framework lock on accessibility behavior

The site is designed to be compatible with the latest two major versions of Chrome, Firefox, Safari, and Edge, on Windows, macOS, iOS, and Android, with major screen readers (VoiceOver, NVDA, JAWS, TalkBack).

If you have made a good-faith effort to resolve an accessibility issue with us and remain unsatisfied, you may file a complaint with:

• U.S. Department of Justice, Civil Rights Division — ada.gov
• U.S. Department of Health and Human Services, Office for Civil Rights — hhs.gov/civil-rights

We hope you give us a chance to fix the issue first.