Accessibility at NeuroPath

Our commitment

NeuroPath is designed to be accessible to people of all abilities. We believe that accessibility is not a feature — it's a foundation. Every user-facing surface we build, including the public marketing site, signed-in clinical applications (Classroom Compass, Home Compass, Specialist Portal, Admin Dashboard), and all generated artifacts (Blueprints, printable toolkits, IEP packets, audio overviews), must meet or exceed WCAG 2.1 Level AA accessibility standards.

What we conform to

Web Content Accessibility Guidelines (WCAG) 2.1 Level AA

All public and signed-in web interfaces meet WCAG 2.1 Level AA. This standard covers:

• Perceivable content (text alternatives, adaptable layouts, distinguishable colors and contrast)
• Operable interfaces (keyboard navigation, navigation aids, enough time for interaction)
• Understandable information (readable text, predictable behavior, error prevention)
• Robust code (valid HTML, ARIA landmarks, semantic markup)

Section 508 (US Federal Accessibility Standard)

We align with Section 508 for federal and state deployments. Section 508 adoption tracks WCAG 2.1 AA, so meeting WCAG means meeting Section 508.

Authoring Tool Accessibility Guidelines (ATAG) 2.0

For any tools we provide that allow users to author or edit content (e.g., custom case-study templates, user-generated text fields in blueprints), we follow ATAG 2.0 to ensure the creation process itself is accessible.

Where we stand today

Fully in place (verified through testing)

• Color contrast across all marketing and application interfaces meets or exceeds AA standards (4.5:1 for normal text, 3:1 for large text)
• All interactive elements (buttons, links, form fields) are keyboard-navigable
• Focus states are visible and clear on all interactive elements
• Form labels are properly associated with their inputs via <label> elements
• Navigation landmarks (<nav>, <main>, <footer>) are in place
• All audio content (welcome videos, audio overviews) includes captions and transcripts

In progress (active development)

• Full screen-reader pass on the Tier 3 Blueprint Workspace (complex dashboard with nested tables and charts)
• Reduced-motion preferences honored across all animations and transitions
• Complete audit of color-as-only-conveyor-of-information (all critical states now have text labels or icons in addition to color)
• Heading hierarchy verification across all pages

Not yet implemented

• Real-time collaboration features (Tier 3 multi-user editing) — planned for Q3 2026

Generated artifacts (PDFs and printables)

Every PDF and visual artifact generated by NeuroPath — including Blueprints, behavior-tracking forms, printable intervention cards, and IEP advocacy packets — must pass automated accessibility checks before download. We use a combination of PDF automated scanners and manual review to ensure:

• Tagged PDF structure (proper heading hierarchy, logical reading order)
• Text alternatives for images and charts
• Form fields are labeled and usable with screen readers
• Sufficient color contrast in printables
• Searchable text (no image-only PDFs)

If a generated artifact fails accessibility checks, the user is notified and offered a text-alternative summary or a regeneration with accessible formatting.

Third-party content and services

When we embed or link to external services (payment processing via Stripe, identity management via Firebase Auth, video hosting), we review those vendors' accessibility statements. We won't integrate a third-party service that has materially lower accessibility support than NeuroPath unless we provide an accessible alternative.

The marketing website uses analytics only in anonymized, privacy-respecting mode (no tracking pixels, no third-party cookies). Non-tracking analytics tools do not impact accessibility.

Reporting an accessibility issue

If you encounter something that isn't accessible, we want to know. Please report it to:

In your report, please include:

• Which page or feature (e.g., “Classroom Compass crisis-log chart”)
• What browser and assistive technology you're using (if applicable)
• What you expected to happen and what actually happened
• Steps to reproduce the issue

Our commitment to you:

• We will acknowledge your report within 5 business days
• We will provide a remediation plan within 30 days
• Critical issues (blocking access to core features) are prioritized within 14 days
• Non-critical issues are addressed in the next feature release or sooner

Our design and development approach

Shift-left accessibility

We audit for accessibility early in design, not as an afterthought. Prototypes are tested with screen readers and keyboard navigation before they reach implementation.

Semantic HTML

We use semantic HTML elements (<button>, <nav>, <fieldset>, <heading>, etc.) rather than generic <div> elements wherever possible. This means assistive technology can understand the page structure correctly.

ARIA (Accessible Rich Internet Applications) sparingly

ARIA is useful for complex interactive components (dropdowns, date pickers, tabs) where native HTML can't express the interaction model. We use ARIA only where semantic HTML is insufficient, and we test extensively with screen readers.

Automated testing

Every build runs axe, Lighthouse, and pa11y accessibility scanners. We fix any failures before merging code.

Manual user testing

We conduct periodic accessibility testing with users who rely on screen readers, magnification, or keyboard navigation. Their feedback directly shapes our product roadmap.