Accessibility Statement

1. The legal basis and the standard#

• Equal Rights for Persons with Disabilities Law, 5758-1998. The law establishes that a person with a disability is entitled to receive a public service on equal terms, and that making the service accessible is part of the service rather than an add-on to it.
• Equal Rights for Persons with Disabilities Regulations (Service Accessibility Adjustments), 5773-2013. These regulations extend the duty to services delivered over the internet and point to the Israeli standard.
• Israeli Standard 5568, "Guidelines for Web Content Accessibility". The standard adopts the W3C's WCAG 2.0 guidelines at conformance level AA.

2. Conformance claimed, and what was actually tested#

Target conformance: level AA under IS 5568, meaning WCAG 2.0 level AA.

There is a real difference between "targets" and "fully proven", so here is exactly what was tested:

What automated testing does not prove. An automated tool catches some failures, not all of them. Zero axe violations is a good sign, not a certificate of full conformance. Things like logical reading order, clarity of wording, and full screen reader behaviour are judged by a person.

• Who carried out the review: a self-assessment by the developer who built the site. It was not carried out by a certified service accessibility consultant, and there is no certification behind it.
• Date of the last review: 5 August 2026.
• Screen reader testing: none was performed. No screen reader has been run manually against this site. That is a known limitation, and section 5 sets it out.

3. What has been made accessible#

Navigation and keyboard

• The entire site can be operated with a keyboard alone, no mouse required. That includes the services dropdown, the mobile menu, the accessibility widget and the form.
• A skip link to the main content is the first focusable item on every page, so you are not forced through the whole navigation on every visit.
• A visible focus indicator on every reachable element, in every display mode. Under high contrast it thickens and turns white.
• In the dropdown: up and down arrows move between items, Home and End jump to the ends, and Escape closes the menu and returns focus to the button that opened it.
• In the accessibility widget, focus is trapped inside the panel while it is open, and Escape closes it and returns focus to where it came from.

Structure and screen readers

• One top-level heading per page, and a heading hierarchy with no skipped levels.
• Landmark regions are marked: banner, navigation, main content and footer. Every major section is tied to its own heading, so a screen reader can list the sections and jump between them.
• Links that open in a new tab announce that fact to a screen reader.
• Text in Hebrew and in other scripts is tagged with its own language, so a screen reader pronounces it correctly.
• Decorative illustrations are hidden from screen readers, so nothing reads out as noise.

This section describes what was built into the code and confirmed by automated testing. It does not describe a real screen reader session, because none has been run yet.

Contrast and text

• A contrast ratio of at least 7:1 for every text intended to be read, measured against its real background. The standard requires 4.5:1.
• Body text starts at 17 pixels on a phone and rises to 18 on a wide screen, with a line height of 1.75.
• Text reflows and expands when the browser is zoomed, without clipping or overlap.

Forms

• Every field has a real label, not just placeholder text inside the box.
• Error messages appear in the form next to the field and are announced live to a screen reader.
• The message says what to fix rather than merely that something is wrong. For example: "an Israeli number starts with 0 or +972".
• On a failed submission, focus moves to the first field that failed.
• No browser dialog boxes. No message depends on pressing "OK".

Automatic adaptation to preferences you already set

The site reads your operating system's accessibility settings and adapts to them without you doing anything:

The accessibility widget

A permanent accessibility button sits in the corner of the screen. Inside it:

• Text size in three steps: normal, large, huge
• High contrast
• Stop animations
• Underline all links
• Reset, which returns everything to its initial state

Your choice is saved in your browser and returns on your next visit. It stays on your device and is never sent to any server.

The accessibility button is never hidden. There is no state in which it disappears, collapses behind a menu, or gets pushed into a footer.

4. What the site deliberately does not do#

The site does not try to work out by itself which visitors need an accessibility adjustment. There is no technical signal that indicates a disability. Any attempt to guess at one is an assumption about a person based on nothing, and an intrusion on their privacy.

Instead there are two routes, and you control both: the preferences you already set in your own operating system, and an explicit choice in the widget. That is also why the accessibility button is always visible.

5. Known limitations#

No screen reader test has been performed. This is the most significant item on the list, which is why it comes first. The site was built with the semantic structure, the labels and the state announcements a screen reader needs, and all of that passed automated testing, but nobody has yet sat down with NVDA, JAWS or VoiceOver and worked through the site by ear. Until that happens, screen reader support here is a design verified in code rather than an experience verified in use. If you use a screen reader and something does not behave as it should, your message is worth more than any automated run.

The review was a self-assessment. The person who tested the site is the person who built it, not a certified service accessibility consultant. There is no external opinion and no certification behind it.

Third-party content. Two components on the site come from external services, and their accessibility is not under my control:

• WhatsApp. The contact buttons hand off to a WhatsApp conversation. The conversation window itself is a Meta product and behaves according to their accessibility. Anyone who would rather not use WhatsApp can call instead.
• Google Fonts. The fonts load from the Google Fonts service. If that service is unavailable, the browser falls back to a system font. The text stays readable; the appearance changes.

Documents. There are no PDFs and no downloadable documents on the site. If any are added, they will be made accessible before publication.

Video and audio. There is no video and no audio on the site, so captioning and audio description requirements are not currently engaged. If media is added, it will arrive with captions.

Service pages. All nine service pages were tested to the same level as the homepage: the same axe-core run, the same display modes, zero violations. Both legal documents were tested the same way. No page on the site was left out of the review.

Accessibility here is under continuous improvement. If you hit a component that does not work for you, that is not an imposition, it is exactly the information I am missing.

6. Accessibility coordinator#

Coordinator

Oren Grach

Role

Business owner

Phone and WhatsApp

+972 54 481 2109

Maximum response time

Two business days

WhatsApp is the channel for accessibility feedback, and it is the only one. When you get in touch, it helps to say what you were trying to do, on which page, and with which browser or assistive technology. Those three details save a round of questions and shorten the fix.

7. Dates#

Date of this statement

5 August 2026

Date of the last accessibility review

5 August 2026

Next scheduled review

5 August 2027, or sooner on any material change to the site