Accessibility Statement

Last updated: 27 July 2026

MyVaad is a platform for managing residential building committees, and we want every resident to be able to use it — to pay, to vote, to read notices, and to reach the committee — regardless of disability, device, or assistive technology. This statement describes the accessibility state of the myvaad.co.il website and the MyVaad services as of the date at the top of this page: what has already been done, what has not, and how to reach us when something is not accessible.

This statement is written in the spirit of Israel's Equal Rights for Persons with Disabilities Law, 5758-1998, and the Equal Rights for Persons with Disabilities (Service Accessibility Adjustments) Regulations, 5773-2013, which point to Israeli Standard IS 5568 — based on the WCAG 2.1 guidelines at level AA.

1. What this statement covers

This statement applies to the myvaad.co.il website and all MyVaad services (the "Service"), operated by Codebyte ("we"). It covers the digital accessibility of the Service only; physical accessibility of the building itself is the responsibility of the building committee or the management company, not ours.

The Hebrew version of this statement is the binding one; this English version is provided for convenience.

2. The level we are aiming for

Our target is IS 5568 at level AA — that is, the WCAG 2.1 guidelines at level AA, the standard referenced by the Equal Rights for Persons with Disabilities (Service Accessibility Adjustments) Regulations, 5773-2013.

This is a target we work towards, not a declaration of full conformance. Sections 5 and 6 below set out exactly what has not been tested and what has not been done.

3. What is already in place

These are the adjustments that exist in the product today:

  • Bilingual layout and writing direction — every page declares its content language and writing direction: Hebrew right-to-left, English left-to-right. Floating menus and dialogs receive the correct direction too, and an automated test measures this in the rendered page.
  • Logical layout properties — the interface is written with CSS "start" and "end" properties instead of "left" and "right", and an automated lint rule blocks any deviation. Switching between Hebrew and English therefore does not break reading order.
  • Semantic structure — a heading hierarchy, a marked main content region on every page, and navigation wrapped in navigation elements, so a screen reader can orient within a page and move between its parts.
  • Keyboard navigation and focus management — the interface components (menus, forms, tabs, dialogs, date picker, the side navigation tree) are built on a component library based on React Aria, which provides keyboard navigation, focus management, and ARIA roles by default.
  • Forms — label, description, and error message are associated with the field by that same library, and an error state is conveyed in text, not by colour alone.
  • Colour and contrast — the light and dark themes are built on colour tokens chosen for a contrast ratio of at least 4.5:1 for body text and 3:1 for large text and interface components. Information is never conveyed by colour alone: payment and arrears states also carry text or a mark.
  • Text alternative for charts — the trend chart on the finance screen is accompanied by a data table intended for screen readers.
  • No emoji — product text contains no emoji, which screen readers announce inconsistently and which break Hebrew alignment; an automated rule enforces this on the translation files. Interface symbols are vector graphics.
  • Touch targets — buttons and tap areas are designed at a minimum of 44 pixels, and primary resident calls to action at a minimum of 48 pixels, with documented exceptions in the language and theme pickers in the page footer.

4. How we test

Every code change runs an automated accessibility check with the axe engine, scoped to the WCAG 2.1 level A and AA rules, across the public pages of the Service — in Hebrew and in English, at a mobile viewport and a desktop viewport. A finding with an impact of serious or critical blocks the change from being merged.

The permanent coverage of that automated check currently includes the home page, the login page, and the marketing pages: About, Contact, Guides & Help, Pricing, Privacy Policy, and Terms of Service. A further test measures the direction of floating dialogs and the order of the elements inside them, in both languages and both themes.

The internal component library has an accessibility inspection tool installed, which developers use during development.

One thing must be said plainly: automated testing detects only part of the possible problems — those a machine can detect. It is not a substitute for manual testing, for testing with assistive technologies, or for testing with users.

5. Known limitations

These are the things we know are still missing or untested. We publish them here explicitly so you do not have to discover them the hard way:

  • No comprehensive manual testing with screen readers (such as NVDA, JAWS, or VoiceOver) has been carried out across all screens.
  • The pages have no "skip to content" link at the start of keyboard navigation.
  • The reduced-motion system preference (prefers-reduced-motion) is currently honoured for some animations only, not all of them.
  • Focus order and focus trapping in dialogs rely on the behaviour of the component library, and no dedicated automated test verifies them.
  • The screens behind login — payment, voting, the committee screens, and the management console — have been tested on an ad-hoc basis and are not covered continuously by the automated check.
  • Findings with a moderate or minor impact do not block a code change, so such findings may exist in the Service.
  • Files uploaded to the system by the building committee or the management company — meeting minutes or bylaws as PDF files, for example — are created by users and do not undergo accessibility remediation by us.
  • Testing is performed in current versions of Chromium-based browsers; we cannot guarantee identical behaviour in older or unsupported browsers.

6. External audit and certification

As of the date of this statement, no external, independent accessibility audit by a licensed accessibility expert has been performed, and the Service is not certified and carries no accessibility approval of any kind.

We therefore do not declare full conformance with IS 5568 or with WCAG 2.1 AA. What we declare is the target and the adjustments actually made, as set out above. Once an external audit is completed we will update this statement and state its date and its principal findings.

7. Reporting an accessibility problem

Have you run into a page, a screen, or an action that is not accessible? Write to us at hello@myvaad.co.il — this is the general contact address for the Service, and accessibility reports are handled through it.

So we can act quickly, please describe: the page address, what you were trying to do, what actually happened, and which browser, device, or assistive technology you were using.

We treat a report like this as a defect in its own right: we will acknowledge it, investigate it, and come back to you with what was fixed or with a timeline for a fix. If an adjustment is needed so you can complete an action in the meantime, we will help by an alternative route.

No dedicated accessibility coordinator has been appointed at this stage; reports are handled by the MyVaad team.

8. Updates to this statement

This statement reflects the state of the Service on the date shown at the top of the page. We will update it on any material change to the accessibility of the Service, whenever one of the limitations listed above is resolved, and in any event once an external accessibility audit is completed.

9. Contact

Accessibility matters: hello@myvaad.co.il. Privacy matters: privacy@myvaad.co.il. General support: support@myvaad.co.il. The Service is operated by Codebyte, Israel.