Accessibility Statement

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.

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.

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. Known exceptions are listed in section 5.
• 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. Known exceptions are listed in section 5.
• 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 to be at least 44 pixels, and key resident calls to action at least 48 pixels. Known exceptions: the language and theme switchers at the foot of the page, and further exceptions listed in section 5.

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 Use. 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.

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 sign-in (payment, voting, committee and resident screens) were checked in an internal manual and automated review on 7 October 2026. Findings still open are listed here. These screens are not yet covered by the routine automated check.
• On some links in the site header, and on buttons styled as links, the keyboard focus indicator is not visible.
• The notifications button on signed-in screens adds an extra keyboard stop that a screen reader announces without a name, and its tap area is smaller than 44 pixels.
• Files attached to votes do not have an accessible name.
• Some charts on the finance screen receive keyboard focus although they are hidden from screen readers. The chart data is available in the alternative table.
• In the error message shown when an invitation link is not valid, part of the text has a contrast ratio below 4.5:1.
• 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.

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.

Have you run into a page, a screen or an action that is not accessible, or do you need an adjustment to use the Service? Contact us by email at hello@myvaad.co.il or by phone on 050-7774760. Accessibility requests are handled as a priority.

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.

Codebyte employs fewer than 25 people and is therefore not required to appoint an accessibility coordinator (regulation 91(a) of the Equal Rights for Persons with Disabilities (Service Accessibility Adjustments) Regulations, 2013). Accessibility requests are handled directly by the MyVaad team, using the contact details in this section.

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.

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