Website Accessibility Law in Israel and IS 5568
Website accessibility is a legal duty in Israel: claims reach ₪50,000 with no proof of damage. What IS 5568 requires, and why an overlay is not enough.
In short (TL;DR): Website accessibility in Israel is a legal requirement under the equal rights for people with disabilities regulations and Israeli standard IS 5568, which is based on WCAG 2.0 level AA. A site that is not accessible is exposed to a claim of up to ₪50,000 — with no proof of damage required. Real accessibility starts in the code, not in a floating widget, and it also improves your ranking in Google.
Most business owners in Israel discover that website accessibility exists only when a warning letter arrives from a lawyer. That is a shame, because making a site accessible is not only a legal duty — it is one of the most worthwhile investments available: it opens your site to hundreds of thousands of users with disabilities, improves the experience for everyone, and even strengthens your organic ranking in Google.
What does Israeli law actually require?
Under the equal rights for people with disabilities regulations, a website that provides a service to the public has to meet Israeli standard IS 5568 — a standard based on the international WCAG guidelines at level AA. In practice that means the site must be usable by visitors with visual, hearing, motor or cognitive impairments: full keyboard navigation, screen reader support, sufficient colour contrast, alternative text for images and more.
What is the risk? A claim of up to ₪50,000 with no proof of damage
This is the part worth knowing: the law allows compensation of up to ₪50,000 to be claimed — without the claimant having to prove that any actual damage was caused. Thousands of warning letters and accessibility claims are sent in Israel every year, and small businesses are a favoured target, because most of them are simply unaware of the requirements. The cost of making a site accessible is almost always far below the cost of a single claim. (One caveat: this article is not legal advice — for specific questions, consult a lawyer who specialises in the field.)
An accessibility overlay on its own, or accessibility built into the code?
The common solution on the market is to install a floating accessibility widget, that blue button at the side of the screen. Such a widget is a useful component, but it does not let you off: it does not fix code that was built badly, a broken heading hierarchy, forms without labels or images without alternative text. Real accessibility starts in the code itself — semantic, valid HTML, full keyboard navigation and correct contrast decided at the design stage. Much as you cannot make a building without a lift accessible by putting a sign at the entrance. Here is the difference in plain terms:
| Aspect | Floating overlay widget | Accessibility built into the code |
|---|---|---|
| Fixing broken code and heading hierarchy | Does not fix it | Fixed at the root |
| Forms without labels | Usually not detected | Proper labels built in |
| Screen reader compatibility | Partial | Full |
| Contribution to Google ranking (SEO) | None | Significant |
| Full compliance with IS 5568 | Not enough on its own | Yes, together with a statement |
| Cost over time | Low but limited | A worthwhile one-off investment |
Does accessibility really help your ranking in Google?
Yes, and here is the secret from the SEO world: Google is itself a kind of blind visitor. The search engine reads your site exactly as a screen reader does — through the code, the headings and the alternative text. An accessible site is a site Google understands better, and therefore ranks higher. And since Google holds around 90% of the search market, every improvement of that kind is worth its weight in gold. Add longer time on page and lower abandonment rates, and you get a genuine lift in organic ranking, as a bonus on top of meeting the law.
How do we make sites accessible at Aiterra?
When we at Aiterra build a new site, accessibility is embedded in the code from the first line, not bolted on afterwards. For existing sites we run a full accessibility audit, fix the technical core, put the required accessibility components in place and prepare a proper accessibility statement for you, as the regulations demand.
How to check your site today: a quick checklist
- Try navigating the site with the keyboard alone (Tab, Enter, arrow keys) — can you reach every link and button, and can you see where the focus is?
- Does every meaningful image have alternative text (alt) that describes it?
- Is the contrast between text and background sufficient, including in small type and on buttons?
- Does every form field have a clear label, and are the error messages understandable?
- Is the heading structure logical, with one H1 followed by H2 and H3 in hierarchy?
- Do the videos have captions?
- And is there an accessibility statement page on the site, reachable from every page?
For anyone who wants to go deeper, the full text of the international guidelines is published by the W3C standards body: the WCAG standards.
What is an accessibility statement and why must it appear on the site?
Beyond the accessibility work itself, the regulations require an accessibility statement to be published on the site: a page setting out which adjustments were made, which known limitations remain, and who to contact if a problem is encountered, including the details of an accessibility coordinator. It is also the first document a lawyer checks before sending a warning letter, so its existence and its quality signal that the business takes the subject seriously. You can see a live example in our own accessibility statement.
Not sure whether your site meets the requirements? Leave your details and we will run an initial accessibility check for you — better to hear about the gaps from us than from a warning letter.
Want a site that works for you? See the Aiterra website building service, or talk to us for a scoping call at no cost.
