Skip to content

Accessibility Statement

Last updated:

Berine Metabolic is committed to making our platform usable by everyone, including users with disabilities. Our audience, adults living with diabetes and prediabetes, includes elevated rates of visual impairment from diabetic retinopathy and reduced manual dexterity from peripheral neuropathy. Accessibility is therefore both a legal commitment and a core design constraint.

1. Conformance Claim

Berine Metabolic strives to conform to Web Content Accessibility Guidelines (WCAG) 2.2 Level AA, published by the W3C in October 2023.

In our own testing, the platform substantially meets WCAG 2.2 AA; the known limitations are listed in §4 below. We have not yet undergone a third-party audit; one is planned post-launch. Full conformance is targeted as the platform matures.

This statement applies to the public site served from berine.io, including the marketing pages, the blog, and the work-with-us inquiry form. It will extend to course content and authenticated account areas as those features launch.

2. Diabetes-Specific Accommodations

In addition to WCAG 2.2 AA baseline requirements, we implement the following accommodations for our audience:

2.1 Diabetic Retinopathy & Other Visual Impairments

  • Contrast. Our design tokens enforce the WCAG AA 4.5:1 contrast ratio for body text against its background, and 3:1 for large text and UI components, so violations are caught structurally during development.
  • Text size. Body text is set at 16px (1rem) minimum. Type scales use rem units so user-agent font-size preferences are respected. Increasing your browser default font size scales the entire interface proportionally.
  • Zoom. We test layouts at 200% browser zoom so body content stays usable without horizontal scrolling.
  • High-contrast mode. A high-contrast color scheme is planned for a future release.

2.2 Peripheral Neuropathy & Motor Impairments

  • Touch targets. Interactive elements meet a minimum 24×24 pixel target size (WCAG 2.2 Success Criterion 2.5.8), with 44×44 used on primary mobile controls where possible.
  • No precision-only interactions. Course interactions that involve dragging, hovering, or precision input also support a keyboard or simple-tap alternative.
  • Generous spacing. Adjacent interactive elements are spaced to reduce accidental activation.

2.3 Cognitive Accessibility

  • Plain language. Course copy and UI use plain language by default, defining clinical terms when first used.
  • Consistent navigation. Header, footer, and in-course navigation remain in consistent locations across pages.
  • Clear progress. Course progress is displayed visibly so you always know where you are.
  • No time limits. Course content has no time-limited interactions; you can pause, replay, and resume freely.
  • No auto-playing media. Audio and video do not auto-play.

3. Implementation

Our implementation choices that support these commitments include:

  • Semantic HTML throughout (headings, landmarks, lists, tables).
  • Meaningful alt text on informative images, with decorative images marked alt="".
  • Keyboard accessibility as a build standard: interactive elements are built and tested to work without a mouse, with focus-visible outlines.
  • A skip-to-content link on every page (visible on keyboard focus).
  • A logical focus order that follows the visual reading order, so keyboard and screen-reader users move through each page in a predictable sequence.
  • ARIA labels on non-obvious interactive elements; we use the react-aria-components library to inherit accessible patterns by default.
  • Color is never the sole indicator of state. Errors, success messages, and active states include text or icon cues alongside color.
  • Respect for the prefers-reduced-motion media query: transitions and decorative animation are disabled when you set that preference.
  • Form fields are labeled, validation errors are announced, and inline help is associated with its input, including the multi-step inquiry form on our work-with-us page, where each step and its conditional fields remain keyboard- and screen-reader-navigable.

4. Known Limitations

We disclose the following known accessibility limitations honestly, and we are working to address them:

  • Third-party embeds. When paid course checkout launches, it will use Stripe’s hosted flow, whose accessibility is governed by Stripe’s accessibility statement. We will monitor for issues and surface alternatives where possible.
  • Video content. When course video launches, it will ship with captions and transcripts; audio descriptions for purely visual information will be added incrementally and may not be present on every video at first.
  • Downloadable PDFs. PDF downloads are kept to a minimum and tagged for accessibility, but older PDFs may not be fully accessible. If you encounter one, contact us for an accessible alternative.
  • Decorative motion. A small number of decorative motion effects on the marketing site rely on GPU rendering. Where the device or preference cannot support them, a static fallback renders instead.

5. Testing

We use a combination of automated and manual testing:

  • Automated checks via Lighthouse, axe-core, and equivalent accessibility audits during development and on each release.
  • Manual keyboard testing: every primary flow can be completed without a mouse.
  • Screen-reader spot checks with NVDA (Windows) and VoiceOver (macOS and iOS) on representative flows during development.
  • Color-contrast verification at design-token level so violations are caught structurally rather than ad-hoc.

A formal third-party WCAG audit is planned post-launch.

6. Feedback & Assistance

If you encounter an accessibility barrier, or if you need this content in an alternative format, please contact us:

  • Email: support@berine.io
  • Response time: we aim to respond within five (5) business days

When you report a barrier, please tell us:

  • The page URL where you encountered the issue.
  • A brief description of the problem.
  • What you were trying to accomplish.
  • The assistive technology, browser, and operating system you are using (if you know).

7. Regulatory Compliance

This statement supports our obligations under the Americans with Disabilities Act (ADA). We are not currently subject to the European Accessibility Act (its microenterprise exemption applies to us today), and we maintain WCAG 2.2 AA as our working standard regardless. WCAG 2.2 AA is the standard referenced or accepted under these frameworks at the time of writing.

8. Updates to This Statement

We review and update this statement at least annually and whenever conformance status, known limitations, or contact channels change. The “Last updated” date at the top of the page reflects the most recent revision.