Accessibility | Everfur

Last updated: June 22, 2026. Effective: July 22, 2026.

1. Our Commitment

Strand Health Inc., doing business as Everfur ("Company," "we," "us," or "our"), is committed to ensuring that our mobile applications, websites, e-commerce platform, community features, and all related digital services (collectively, the "Services") are accessible to and usable by all individuals, including persons with disabilities. We strive to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 at the AA conformance level, as published by the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI), and we are committed to continuous improvement in the accessibility of our Services.

This commitment extends to all features and functions of the Services, including but not limited to: the Everfur Health Intelligence mobile application (iOS and Android), the Everfur website (everfur.com and all subdomains), the Everfur Marketplace and e-commerce checkout flows, the Care Team Feed and community features, walk tracking features and walk history, AI health chat and health assessment tools, prescription coordination interfaces, metabolomics test kit registration and results, account management and settings, and all informational and legal pages.

2. Accessibility Standards

We design, develop, and test our Services with the goal of meeting or exceeding the following standards and guidelines:

WCAG 2.1 Level AA. We target conformance with the Web Content Accessibility Guidelines 2.1 at the AA level. This standard encompasses four core principles requiring that digital content be Perceivable, Operable, Understandable, and Robust (POUR). We monitor developments in WCAG 2.2 and plan to evaluate adoption as industry implementation matures.

Section 508 of the Rehabilitation Act. To the extent the Services are used by or on behalf of federal agencies or in connection with federally funded programs, we endeavor to comply with the accessibility requirements of Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. Section 794d).

Americans with Disabilities Act (ADA). We design our Services consistent with the requirements of Title III of the Americans with Disabilities Act (42 U.S.C. Sections 12181 through 12189), which prohibits discrimination on the basis of disability in places of public accommodation, and we recognize the evolving application of ADA requirements to digital services, mobile applications, and e-commerce platforms.

EN 301 549 (European Standard). For users accessing our Services from jurisdictions subject to the European Accessibility Act (Directive (EU) 2019/882) or similar legislation, we endeavor to comply with the accessibility requirements of EN 301 549, the harmonized European standard for ICT accessibility.

Mobile Accessibility. We follow the W3C Mobile Accessibility guidance and platform specific accessibility guidelines published by Apple (Human Interface Guidelines: Accessibility) and Google (Material Design: Accessibility) for our iOS and Android applications respectively.

3. Current Accessibility Features

We have implemented the following accessibility features across our Services. This list is representative and not exhaustive; it is updated as we introduce new features and improvements.

3.1 Structural and Semantic Design

All pages and screens use semantic HTML elements (on web) and native accessible components (on mobile) with proper heading hierarchy (H1 through H6) to support screen readers and other assistive technologies. Content is structured in a logical reading order that is preserved when CSS styles are disabled or overridden. Landmark regions (header, navigation, main, complementary, contentinfo) are used to identify major sections of each page. Data tables include appropriate header cells, scope attributes, and captions. Lists use proper ordered or unordered list markup. Forms use properly associated labels, fieldsets, legends, and descriptive error messages tied to their respective inputs via programmatic association.

3.2 Keyboard Accessibility

All interactive elements (links, buttons, form controls, navigation menus, dropdowns, modals, accordions, tabs, carousels, sliders, and custom widgets) are operable using keyboard only input. A visible focus indicator is displayed on all focusable elements, with enhanced visibility for high contrast mode users. Focus order follows a logical sequence consistent with the visual layout and reading order. Focus trapping is implemented in modal dialogs and overlays to prevent keyboard users from tabbing to content behind the overlay, with a clear mechanism (Escape key and visible close button) to close the modal and return focus to the triggering element. Skip navigation links are provided to allow keyboard users to bypass repetitive navigation and proceed directly to main content. Custom keyboard shortcuts do not conflict with common screen reader, browser, or operating system shortcuts. No functionality depends solely on mouse hover, drag and drop, or multi touch gestures without a keyboard accessible alternative.

3.3 Visual Accessibility

Text and interactive elements meet or exceed the minimum contrast ratios specified by WCAG 2.1 AA: a contrast ratio of at least 4.5:1 for normal text (below 18pt or 14pt bold) and 3:1 for large text (18pt or 14pt bold and above) and non text user interface components and graphical objects. Color is never used as the sole means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Error states, required fields, and status indicators use supplementary visual cues (icons, text labels, patterns) in addition to color. All informational images include descriptive alt text that conveys the meaning and function of the image. Decorative images are marked with empty alt attributes (alt="") or role="presentation" to be ignored by screen readers. Complex non text content (charts, graphs, diagrams, data visualizations, infographics) is accompanied by text alternatives, detailed descriptions, or data tables. Text can be resized up to 200% without loss of content or functionality. Content reflows properly at 320px viewport width (equivalent to 400% zoom on a 1280px desktop) without requiring horizontal scrolling for vertical content. User interface components and graphical objects (icons, form field borders, focus indicators) have a contrast ratio of at least 3:1 against adjacent colors.

3.4 Motion and Animation

Animations, transitions, auto playing content, and parallax effects respect the prefers-reduced-motion operating system setting. When reduced motion is enabled, animations are either disabled entirely or replaced with non animated equivalents that convey the same information. No content flashes more than three times per second to reduce seizure risk. Auto playing video or audio content includes visible controls to pause, stop, or mute the content within the first three seconds. Carousels and auto advancing content include pause controls and are stoppable by keyboard interaction. Parallax scrolling effects are minimized and degrade gracefully to standard scrolling when prefers-reduced-motion is active.

3.5 Responsive and Adaptive Design

Layouts adapt to a wide range of screen sizes and viewport widths, from mobile (320px) through desktop (1920px and above), without loss of content, functionality, or reading order. Touch targets on mobile interfaces meet the minimum recommended size of 44x44 CSS pixels as specified by WCAG 2.5.5 (Target Size Enhanced). Content maintains proper spacing, alignment, and visual hierarchy across all supported breakpoints. Text does not clip, truncate behind overflow, or overlap at any standard viewport size or when text is resized up to 200%. Orientation is not locked; content adapts to both portrait and landscape orientations unless a particular orientation is essential (such as for certain data visualizations).

3.6 Screen Reader Compatibility

We test our Services with common screen reader and assistive technology combinations, including VoiceOver (iOS and macOS), TalkBack (Android), NVDA (Windows), and JAWS (Windows). Dynamic content updates use ARIA live regions (aria-live="polite" or "assertive" as appropriate) to announce changes to screen reader users without disrupting their current focus or reading context. Custom interactive components implement appropriate ARIA roles, states, and properties as specified by the WAI ARIA 1.2 specification and ARIA Authoring Practices Guide. Status messages, error messages, loading indicators, toast notifications, and progress updates are announced to screen readers using appropriate ARIA live regions or role="status" and role="alert" attributes. Images within the Care Team Feed and health assessments include alt text provided by the user (when uploading) or generated by our systems.

3.7 Media Accessibility

Video content hosted on our platforms includes closed captions or subtitles in at minimum English. Audio content (such as educational materials, product guides, and onboarding tutorials) is accompanied by text transcripts. Audio descriptions for video content are provided where visual information is essential to understanding the content and is not conveyed through dialogue or narration alone. Media players include accessible controls for play, pause, stop, volume, mute, closed captions/subtitles toggle, playback speed, and full screen, all operable via keyboard and announced to screen readers.

3.8 Forms and Input Accessibility

All form inputs include visible labels that are programmatically associated with their controls via the for/id attribute pairing or aria-labelledby. Required fields are indicated both visually (with a visual indicator such as an asterisk) and programmatically (using the required or aria-required attribute). Error messages clearly describe the nature of the error and provide actionable suggestions for correction. Error messages are associated with the specific field in error using aria-describedby or aria-errormessage. Form validation provides inline feedback in real time where possible and always provides a comprehensive error summary upon submission. Input purposes for common fields (name, email, address, phone, credit card) are identified using autocomplete attributes to support browser and assistive technology autofill features. Time limits on form submissions, checkout flows, and session timeouts can be extended, adjusted, or turned off, with advance warning before timeout. Complex multi step forms (such as checkout) include clear step indicators and allow users to review and correct previous steps.

3.9 E-Commerce Accessibility

The Everfur Marketplace and checkout experience are designed with accessibility as a core requirement, including: accessible product listing pages with properly labeled images and structured descriptions; accessible filtering, sorting, search, and category navigation; accessible product detail pages with expandable sections for descriptions, ingredients, reviews, and shipping information; accessible shopping cart management with quantity adjustment, item removal, and price updates announced to screen readers; accessible multi step checkout flow with clear step indicators, progress tracking, and the ability to review and edit previous steps; accessible payment form fields with proper labels, input masking, and error handling; accessible order confirmation and receipt pages; accessible order history, order tracking, and return/exchange interfaces; and accessible product review submission forms.

3.10 Care Team Feed Accessibility

The Care Team Feed is designed to be navigable and usable with assistive technologies, including: properly labeled images with user provided or auto generated alt text; accessible interaction controls (react, comment, share, report) with clear labels and ARIA attributes; screen reader compatible navigation between feed items using standard list semantics; keyboard accessible comment composition, editing, and submission; accessible content moderation and reporting flows; accessible user profile viewing; and accessible navigation between feed, notifications, and profile sections.

3.11 Walk Tracking Accessibility

Walk tracking features include accessibility considerations such as: audio and haptic feedback for walk start, pause, resume, and stop actions; accessible display of walk statistics (distance, duration, pace, elevation) with properly labeled data fields; screen reader compatible map views with text alternatives for route display, including textual route descriptions; accessible walk history browsing and detail views with sortable and filterable walk records; VoiceOver and TalkBack compatible walk controls; and consideration for users who may use walk tracking with mobility aids or adaptive equipment.

3.12 Cognitive Accessibility

We strive to support users with cognitive disabilities through: clear, plain language in user interface text, instructions, and error messages; consistent navigation patterns and interface layouts across screens; avoidance of jargon without explanation; meaningful link text (avoiding "click here" patterns); clear visual hierarchy and information architecture; confirmation dialogs for destructive or irreversible actions; and undo functionality where practical.

4. Known Limitations

While we strive for comprehensive accessibility, we acknowledge the following current limitations and are actively working to address them:

Third Party Content. Some third party integrations, embedded widgets, payment processor interfaces, and map services may not be fully accessible. We work with our third party partners to improve the accessibility of their components within our Services, but we cannot guarantee full conformance for content and functionality controlled by third parties.

User Generated Content. Images uploaded by users to the Care Team Feed, product reviews, or other community features may not include alt text. We provide tools and prompts for users to add image descriptions at the time of upload, and we are developing automated alt text generation capabilities to improve the accessibility of user uploaded images when user provided descriptions are absent.

PDF Documents. Some older PDF documents (such as laboratory reports uploaded by users, legacy marketing materials, or third party generated documents) may not be fully tagged for screen reader accessibility according to PDF/UA (ISO 14289) standards. We are working to ensure that all PDFs generated by our Services (including metabolomics reports and health summaries) meet PDF/UA accessibility standards.

Complex Data Visualizations. Some health data charts, walk tracking route maps, metabolomics result visualizations, and trend graphs may present accessibility challenges for screen reader users and users who cannot perceive visual data representations. We provide text based alternatives, data tables, and narrative summaries for all critical data, and we are continuously improving the accessibility of our data visualization components.

Legacy Content. Some older marketing pages, help articles, or informational content published before our current accessibility standards were adopted may not fully conform to WCAG 2.1 AA. These pages are being identified and remediated on a rolling basis, prioritized by traffic volume and functional importance.

Real Time Features. Some real time features (such as live walk tracking map updates) may present challenges for screen reader users due to the frequency and nature of dynamic content updates. We balance the need for real time information with the need to avoid excessive screen reader announcements.

5. Accessibility Testing

Our accessibility testing program includes the following components:

Automated Testing. We run automated accessibility scans using industry standard tools (such as axe-core, Lighthouse, and pa11y) on a regular cadence as part of our continuous integration and deployment pipeline. Automated scans check for common WCAG violations including missing alt text, insufficient color contrast, missing form labels, incorrect heading hierarchy, ARIA implementation errors, keyboard traps, and missing landmark roles. Automated testing catches approximately 30 to 40 percent of WCAG issues; manual testing is required for the remainder.

Manual Testing. Our product and QA teams conduct manual accessibility testing as part of each significant feature release cycle. Manual testing includes keyboard navigation testing across all interactive flows, screen reader testing of key user journeys, zoom and magnification testing (up to 200% text resize and 400% page zoom), color contrast verification for custom components, cognitive walkthrough of new features, and verification of focus management in dynamic content.

Assistive Technology Testing. We test critical user flows with common assistive technology combinations, including: VoiceOver on iOS (latest two major iOS versions); VoiceOver on macOS (latest version); TalkBack on Android (latest two major Android versions); NVDA on Windows (latest version) with Chrome and Firefox; JAWS on Windows (latest version) with Chrome; and voice control and switch access on iOS and Android.

Third Party Audits. We engage qualified third party accessibility consultants to conduct independent accessibility audits of our Services on a periodic basis (at minimum annually for significant product surfaces). Audit findings are prioritized and remediated according to the severity classifications described in Section 6. Audit reports are maintained internally and made available to enterprise customers upon request.

User Feedback. We actively solicit accessibility feedback from users with disabilities through our accessibility contact channels and incorporate their input into our accessibility roadmap and prioritization decisions. User reported accessibility issues receive the same priority treatment as issues identified through testing.

6. Remediation Process

Accessibility issues are treated as product defects and managed through our standard engineering workflow with the following severity classifications and target remediation timelines:

Critical (P0). Issues that completely block access to core functionality for users relying on assistive technologies (for example, an inaccessible login flow or checkout process). Targeted for remediation within seven (7) business days of identification.

Serious (P1). Issues that significantly impair the usability of a feature or require a difficult or unreliable workaround (for example, missing labels on form fields in a key flow, or a keyboard trap in a modal). Targeted for remediation within thirty (30) days of identification.

Moderate (P2). Issues that cause inconvenience but do not prevent completion of the relevant task (for example, low contrast on a non essential decorative element, or a missing landmark role). Targeted for remediation within ninety (90) days of identification.

Minor (P3). Issues that are cosmetic, affect edge cases, or have straightforward and well understood workarounds (for example, a redundant ARIA attribute or a minor heading hierarchy irregularity). Addressed in the normal product development cycle.

We track remediation progress internally and include accessibility metrics in our product quality reporting. All new features undergo accessibility review before release.

7. VPAT and Accessibility Conformance Reports

We are in the process of developing a Voluntary Product Accessibility Template (VPAT) based on the ITI VPAT 2.4 Rev (March 2022) format, which will document the conformance of our Services with WCAG 2.1 AA, Section 508, and EN 301 549. The VPAT will be made available upon request by enterprise and government customers. Contact accessibility@everfur.com for the current status and availability of our VPAT documentation.

8. Accessibility Feedback and Contact

If you encounter an accessibility barrier when using our Services, or if you need information in an alternative format, please contact us. We take all accessibility reports seriously and will use your feedback to identify and prioritize improvements.

How to Report an Accessibility Issue:

Please provide as much of the following information as possible: the specific page, screen, URL, or feature where the barrier occurred; a description of what you were trying to do; the assistive technology you were using (if applicable), including name and version; your device type, operating system version, and browser name and version (if applicable); screenshots or screen recordings demonstrating the issue (if available); and any error messages or unexpected behavior you observed.

Contact Information:

Email: accessibility@everfur.com
General Support: hello@everfur.com

Strand Health Inc.
d/b/a Everfur
1002 Dean Street, Suite 101
Brooklyn, NY 11238

We will acknowledge receipt of your report within five (5) business days and provide a substantive response, including a severity classification and estimated remediation timeline if applicable, within fifteen (15) business days.

9. Accessibility Roadmap

We maintain an internal accessibility roadmap that prioritizes improvements based on user impact, frequency of use, regulatory requirements, severity of the current gap, and technical feasibility. Current and planned accessibility initiatives include:

Implementing automated alt text generation for user uploaded images in the Care Team Feed using AI image description capabilities. Enhancing the accessibility of complex data visualizations including health trend charts, walk route maps, and metabolomics result displays with data table alternatives and screen reader optimized descriptions. Completing VPAT (Voluntary Product Accessibility Template) documentation for enterprise and government customers. Expanding assistive technology test coverage to include additional screen readers, voice control tools, alternative input devices, and switch access. Implementing user preference settings for reduced motion, high contrast, increased text size, and other accessibility customizations within the Application settings. Improving the accessibility of all PDF reports generated by the Services to meet PDF/UA (ISO 14289) standards. Conducting accessibility training for all engineering, design, and QA team members. Evaluating conformance with WCAG 2.2 Level AA for potential adoption. Improving the accessibility of real time walk tracking features for screen reader users.

10. Compliance and Legal

This Accessibility Statement reflects our good faith efforts to ensure the accessibility of our Services. It is not a legal certification, warranty, guarantee, or representation of full conformance with any specific accessibility standard. Accessibility is an ongoing effort, and we are committed to continuous improvement. Our current level of conformance is "partially conformant" with WCAG 2.1 Level AA, meaning that some portions of the content may not yet fully conform.

Nothing in this statement limits or modifies the rights and remedies available to individuals under applicable law, including the Americans with Disabilities Act (42 U.S.C. Sections 12101 et seq.), Section 508 of the Rehabilitation Act (29 U.S.C. Section 794d), the European Accessibility Act (Directive (EU) 2019/882), or comparable state and local accessibility laws. If you believe you have been denied equal access to our Services on the basis of disability, you may contact us at the information provided in Section 8, and we will work to resolve the issue promptly.

11. Updates to This Statement

We will review and update this Accessibility Statement at least annually, or more frequently as material changes to our Services, our accessibility practices, or the applicable regulatory environment occur. The date of the most recent update is indicated at the top of this page.

12. Contact Information

Strand Health Inc.
d/b/a Everfur
1002 Dean Street, Suite 101, Brooklyn, NY 11238

Accessibility: accessibility@everfur.com
General: hello@everfur.com
Website: everfur.com/accessibility