Accessibility Statement

Our commitment

Family is built to be usable by every adult, child, and family member regardless of disability or assistive technology. Accessibility is not a feature we add at the end, it shapes how we design and what we ship from day one.

Scope of this statement

This statement covers all Family web properties:

The marketing site at fffam.app.
The three apps at app.fffam.app/life, /biz, and /grows.

Standards we conform to

We aim to conform to:

Web Content Accessibility Guidelines (WCAG) 2.0, Level AA the international standard.
Israeli Standard 5568 (2013) the Israeli adoption of WCAG 2.0 AA, referenced by the Equal Rights for Persons with Disabilities Law, 1998 and the Accessibility of Service Regulations, 5773–2013.

Conformance status

Substantially conforms to WCAG 2.0 Level AA as of the date above, with the limitations listed below. Conformance is verified by a combination of automated and manual review (see "How we test").

What we do to maintain accessibility

A custom color palette engineered for WCAG 2.0 AA contrast, body text at ≥ 4.5:1, large text and icons at ≥ 3:1.
Semantic HTML landmarks (<header>, <nav>, <main>, <footer>) for screen-reader navigation.
Programmatic labels on form inputs, every field has either a <label> or an aria-label.
Right-to-left (RTL) layout throughout, with Hebrew as a first-class locale alongside English.
Resizable text, pinch-zoom is not blocked on mobile; layout adapts when browser zoom is increased.
No reliance on color alone, every place where color carries meaning, an accompanying sign, icon, or label is present too.
An internal pre-publication checklist for designers and animators that covers contrast, motion, captions, and color-blindness simulation.
Ongoing review, every shipping change is run through axe-core; manual review is performed before each significant release.

Known limitations + remediation timeline

We're being transparent about what's still being improved. If you encounter an accessibility issue that isn't listed here, please tell us, your report directly shapes our remediation queue.

Modal dialogs keyboard focus management (focus-trap, ESC to close, focus return after close) is being refactored across all three apps. Target: before the public beta (July 2026).
Color-only meaning audit income/expense entries use a +/− sign prefix alongside red/green coding; we are auditing every additional surface (charts, tooltips, badges) to confirm a non-color cue is always present. Target: before the public beta.
Mixed-direction text in Hebrew screen-reader output some surfaces have English brand names embedded in Hebrew sentences; screen readers may stumble on the language switch. Under review.
Some legacy form patterns a small number of older form components still rely on placeholder text instead of programmatic labels. Migration in progress.

How we test

Automated axe-core 4.10 (an industry-standard accessibility engine) is run against every surface after each deploy.
Manual keyboard-only navigation walkthroughs, screen-reader spot-checks (VoiceOver on macOS and iOS, NVDA on Windows), and color-blindness simulation (Stark, Color Oracle).
Pre-publication every CSS and HTML change is reviewed against our internal accessibility cheatsheet before merging.

Hebrew availability

This statement is available in English and Hebrew via the language toggle in the top navigation. Both versions are intended to be equivalent.

How to contact us about accessibility

If you encounter an accessibility barrier, please tell us. We will respond within 7 business days with an acknowledgement and a plan.

In your report, please include:

The page or feature where you encountered the issue (a URL helps).
What you were trying to do.
What happened instead.
Your assistive technology, if relevant (screen-reader name, magnifier, etc.).

Accessibility reports are treated as priority and go directly to our small core team.