1. Accessibility Overview

VitalNexa is committed to providing an inclusive experience for all users, including those who rely on assistive technologies. As a health platform, accessibility is especially important -- users with visual, motor, cognitive, or auditory impairments have equal need for wellness tracking and health insights.

2. Compliance Standards

Standard	Level	Scope	Status
WCAG 2.1	Level AA	All user-facing pages, forms, interactive components, and chat interface	In Progress
Section 508	Compliance	Federal accessibility requirements (aligns with WCAG 2.0 AA)	In Progress
ARIA 1.2	Best Practices	Accessible Rich Internet Applications for dynamic content and custom widgets	Implemented

3. Accessibility Features

3.1 Semantic HTML Structure

• All pages use proper heading hierarchy (h1 through h6) without skipping levels
• Navigation uses <nav> landmarks with aria-label attributes
• Main content wrapped in <main> element for skip-navigation support
• Forms use <label> elements properly associated with inputs via for/id pairing
• Lists, tables, and other structural elements use semantically correct HTML elements
• Page regions identified with landmark roles: banner, navigation, main, contentinfo

3.2 Keyboard Navigation

• All interactive elements are reachable and operable via keyboard alone
• Logical tab order follows visual reading order (left-to-right, top-to-bottom)
• Skip-to-content link appears on focus as the first element on every page
• Modal dialogs trap focus within the dialog until dismissed
• Dropdown menus support arrow key navigation
• Chat input supports Enter to send, Shift+Enter for newline
• Escape key closes modals, dropdowns, and overlays
• No keyboard traps: users can always tab away from any component

3.3 Screen Reader Support

• All interactive elements have accessible names via labels, aria-label, or aria-labelledby
• Dynamic content updates announced via aria-live regions (chat messages, form errors, alerts)
• Icons and decorative images use aria-hidden="true" or empty alt attributes
• Informational images have descriptive alt text
• Form validation errors linked to inputs via aria-describedby
• Loading states communicated with aria-busy and status announcements
• Chart data available as accessible data tables for screen reader users
• Tested with NVDA (Windows), VoiceOver (macOS/iOS), and TalkBack (Android)

3.4 Color and Contrast

Element	Foreground	Background	Contrast Ratio	WCAG AA Requirement	Status
Body text	#334155	#ffffff	10.3:1	4.5:1	Pass
Headings	#1e293b	#ffffff	14.5:1	3:1 (large text)	Pass
Primary links/buttons	#ffffff	#0d9488	4.6:1	4.5:1	Pass
Nav links	#cbd5e1	#1e293b	9.1:1	4.5:1	Pass
Error messages	#dc2626	#ffffff	5.9:1	4.5:1	Pass
Success indicators	#16a34a	#ffffff	4.6:1	4.5:1	Pass
Placeholder text	#94a3b8	#ffffff	3.4:1	4.5:1	Fail

Information is never conveyed by color alone. Status indicators use icons and text labels alongside color coding. Charts include patterns or labels in addition to color differentiation.

3.5 Focus Indicators

• All focusable elements display a visible focus ring (2px solid outline with 2px offset)
• Focus ring color: #0d9488 (teal) providing clear visibility against all backgrounds
• Focus indicators are not removed or hidden with outline: none
• Custom components implement :focus-visible for keyboard-only focus styling
• Focus ring meets the 3:1 contrast requirement against adjacent colors

3.6 Text Resizing

• All text scales correctly up to 200% zoom without loss of content or functionality
• Layout uses relative units (rem, em, %) rather than fixed px for font sizes
• Content reflows at 400% zoom to a single column (no horizontal scrolling)
• Touch targets are at least 44x44 CSS pixels for interactive elements

4. Accessibility Audit Checklist

WCAG Criterion	Description	Status	Notes
1.1.1 Non-text Content	All images have alt text; decorative images hidden from AT	Pass	Audit complete March 2026
1.3.1 Info and Relationships	Semantic HTML conveys structure; forms use proper labels	Pass
1.3.2 Meaningful Sequence	DOM order matches visual order	Pass
1.4.1 Use of Color	Color is not the sole means of conveying information	Pass	Icons and labels supplement color
1.4.3 Contrast (Minimum)	Text meets 4.5:1 ratio; large text meets 3:1	Partial	Placeholder text contrast needs fix
1.4.4 Resize Text	Text resizable to 200% without content loss	Pass
1.4.10 Reflow	Content reflows at 400% (320px equivalent)	Pass
1.4.11 Non-text Contrast	UI components and graphics meet 3:1 contrast	Pass
2.1.1 Keyboard	All functionality available via keyboard	Pass
2.1.2 No Keyboard Trap	Focus can be moved away from all components	Pass
2.4.1 Bypass Blocks	Skip-to-content link on every page	Pass
2.4.3 Focus Order	Tab order is logical and intuitive	Pass
2.4.6 Headings and Labels	Headings and labels describe topic or purpose	Pass
2.4.7 Focus Visible	Keyboard focus indicator is visible	Pass	Custom teal focus ring
2.5.5 Target Size	Touch targets at least 44x44px	Pass
3.1.1 Language of Page	HTML lang attribute set correctly	Pass	lang="en"
3.3.1 Error Identification	Form errors clearly described in text	Pass
3.3.2 Labels or Instructions	Input fields have visible labels and helper text	Pass
4.1.1 Parsing	Valid HTML with no duplicate IDs	Pass	Validated with Nu HTML Checker
4.1.2 Name, Role, Value	Custom components expose correct ARIA roles and states	Pass
4.1.3 Status Messages	Status messages announced via aria-live regions	Pass	Chat, alerts, toasts

5. Responsive Design

Breakpoint	Target Devices	Layout	Status
375px - 639px	Mobile phones (iPhone SE through iPhone Pro Max)	Single column, stacked navigation, full-width cards, bottom chat input	Complete
640px - 1023px	Tablets (iPad Mini, iPad Air, Android tablets)	Two-column where appropriate, collapsible sidebar, responsive tables	Complete
1024px+	Desktops and laptops	Full layout with sidebar navigation, multi-column dashboard, expanded charts	Complete

6. Testing Methodology

6.1 Automated Testing

• axe-core: Integrated into CI pipeline via React Testing Library; runs on every component test
• Lighthouse: Accessibility score target of 95+ on all pages; run weekly
• Pa11y: Automated WCAG 2.1 AA compliance checks on build
• ESLint jsx-a11y: Linting rules enforce accessibility best practices in React components

6.2 Manual Testing

• Keyboard-only navigation testing on all user flows quarterly
• Screen reader testing with NVDA (Windows), VoiceOver (macOS), and TalkBack (Android)
• Color contrast spot-checks with browser DevTools and WebAIM Contrast Checker
• Zoom testing at 200% and 400% on Chrome, Firefox, and Safari
• Touch-only testing on iOS and Android devices

6.3 User Testing

• Planned usability sessions with assistive technology users before public launch
• Feedback mechanism on every page for reporting accessibility issues
• Accessibility-specific questions included in quarterly user surveys

7. Remediation Plan

Issue	WCAG Criterion	Severity	Remediation	Target Date	Status
Placeholder text contrast below 4.5:1	1.4.3	Medium	Darken placeholder color from #94a3b8 to #64748b (7.0:1 ratio)	April 15, 2026	Scheduled
Chart tooltip not keyboard accessible	2.1.1	Medium	Add keyboard focus support to chart data points with tooltip on focus	April 20, 2026	Scheduled
File upload drag area lacks keyboard alternative text	4.1.2	Low	Add aria-label describing the drop zone and its keyboard-accessible file browse button	April 25, 2026	Scheduled
Chat streaming text not announced incrementally	4.1.3	Low	Add aria-live polite region that announces when the AI response is complete	April 30, 2026	Scheduled

8. Ongoing Compliance

• New Feature Reviews: Every new feature undergoes accessibility review as part of the PR checklist before merge
• CI/CD Integration: axe-core and Pa11y checks run on every pull request; failures block merge
• Quarterly Audits: Full manual accessibility audit conducted every quarter with findings tracked in the remediation plan
• Training: All frontend developers complete WCAG 2.1 training during onboarding and annual refresher
• Accessibility Statement: Public accessibility statement published at /accessibility describing conformance level, known limitations, and contact information for reporting issues
• Third-Party Audit: External accessibility audit planned for Q3 2026 prior to public launch, with remediation of all critical and major findings before release