Website Accessibility in Israel: What the Law Actually Requires (IS 5568)

Let me be honest with you: most business owners I meet have heard "something about an accessibility law," installed a floating widget with a wheelchair icon, and moved on feeling covered. I understand the appeal — it takes five minutes and looks official. The problem is that in most cases it does not satisfy the legal requirements, and meanwhile accessibility lawsuits against websites are no longer a theoretical scenario in Israel. They are routine.

I've been working on website accessibility for years, and this article collects everything you actually need to know: who is obligated, what the Israeli standard really demands, what that means for your site in practice, and what genuine compliance looks like — as opposed to the "we installed a plugin" kind.

Who is required to make their website accessible?

The legal foundation is Israel's Equal Rights for Persons with Disabilities Law, together with the regulations enacted under it — the Equal Rights for Persons with Disabilities Regulations (Service Accessibility Adjustments). Regulation 35 of those regulations deals specifically with the accessibility of internet services, and it is what extends the accessibility obligation to websites.

The principle is simple: if you provide a service to the public, and your website is part of how the public receives that service, the website must be accessible. That casts a very wide net:

• Businesses selling products or services through their site — online stores, obviously, but also brochure sites with a contact form
• Professional service providers: law firms, accountants, clinics, salons
• Restaurants and cafes that display a menu or take orders online
• Public bodies and government entities, which face even stricter requirements

The regulations do include certain exemptions and qualifications, some of them tied to the scale of the business — but I strongly recommend not banking on an exemption without checking with a professional. Exemptions come with specific conditions, and some still require you to take certain actions (such as publishing an accessibility statement). The assumption "we're a small business, this doesn't apply to us" is exactly the assumption that ends in a demand letter from a lawyer.

What is IS 5568, and how does it relate to WCAG?

Israeli Standard 5568 (ת"י 5568) is the standard that defines what an "accessible website" means for the purposes of the regulations. The good news: the Standards Institution of Israel did not reinvent the wheel. The Israeli standard essentially adopts WCAG — the Web Content Accessibility Guidelines — the international guidelines for web content accessibility developed by the W3C, the body that standardizes the web itself.

WCAG defines three conformance levels: A (basic), AA (intermediate), and AAA (strict). The requirement in Israel, as in most of the Western world, is conformance at level AA. In other words: if your site meets WCAG at level AA, you are on the right track for the Israeli standard as well.

This carries an encouraging implication: accessibility is not some "Israeli invention" that requires special local solutions. A site built properly to accepted international standards is an accessible site. Anyone telling you that you need a "special Israeli solution" in the form of this or that plugin is probably selling you something.

What does AA mean in practice? Ten real-world examples

"Level AA conformance" sounds like a contract clause. In practice it is a list of very concrete requirements. Here are ten of the central ones, in human language:

1. Full keyboard navigation. Everything a user can do with a mouse — menus, buttons, forms, popups — must also be possible with a keyboard alone. People with motor disabilities, and screen reader users, simply don't use a mouse.
2. Alternative text for images (alt text). Every image that conveys information needs a text description a screen reader can announce. A banner image saying "50% off everything" with no alt text is, for a blind user, an empty rectangle.
3. Sufficient color contrast. Light gray text on a white background looks "clean" to a designer but is unreadable for people with low vision — and for anyone checking their phone in the sun. The standard defines minimum contrast ratios between text and background.
4. Forms with clear labels. Every form field needs a label programmatically associated with it, and error messages must explain what went wrong and how to fix it — not just turn the field red.
5. Captions for videos. Video content with speech needs captions so that deaf and hard-of-hearing users can consume it.
6. A proper heading structure. Headings (H1, H2, H3) must reflect the logical structure of the page, because screen reader users navigate through them. A heading that is really just large bold text doesn't count.
7. Links that explain themselves. "Click here" and "read more" are meaningless when announced out of context. A link should say where it leads.
8. The ability to stop moving content. Carousels, animations, and auto-rotating sliders must be pausable. Content in constant motion is a genuine barrier for people with attention and cognitive disabilities.
9. Text resizing without breaking the page. A user who enlarges the text in their browser should get a readable, usable page — not a salad of overlapping elements.
10. Screen reader compatibility. Interactive components — accordions, modal dialogs, tabs — must be built so a screen reader understands what they are and what state they're in. That requires proper semantic code, and sometimes judicious use of ARIA.

Notice the pattern: every one of these requirements concerns how the site is built. Which brings us to the most important point in this article.

Why an overlay widget doesn't solve your problem

Floating accessibility overlays — those widgets that add a corner icon with options like text enlargement and contrast toggles — are the most common "solution" in the Israeli market. They are also, in most cases, not enough.

An overlay can change how your site looks. It cannot change how your site is built — and most of the standard's requirements are about exactly that.

Look back at the list above: a widget cannot add meaningful alt text to your images, because it has no idea what's in them. It cannot fix a form built without labels, cannot reorganize a broken heading structure, and cannot turn a menu that doesn't work with a keyboard into one that does. It is a cosmetic layer over the existing code.

Worse — some overlays actively interfere with assistive technology users, because they manipulate the page in ways that clash with screen readers users have already configured exactly how they need them. And the legal bottom line: installing a widget does not, by itself, confer conformance with the standard, and accessibility lawsuits are filed against sites with a prominent accessibility icon in the corner all the time.

That doesn't mean overlays have no place — some of what they offer is a nice addition on top of a properly accessible site. An addition, though. Not a substitute.

What happens if you don't comply? On legal exposure

Here's the part that makes business owners sit up straight. The Equal Rights for Persons with Disabilities Law allows for statutory compensation — meaning monetary damages awarded without any need to prove actual harm. A person with a disability who encounters an inaccessible website does not need to show they lost money or suffered tangible injury; the discrimination itself is the cause of action.

The practical consequence: a whole field of website accessibility litigation has emerged in Israel, and some plaintiffs scan sites systematically. A business with an inaccessible website is an easy target — the check is simple, the violation is easy to demonstrate, and the compensation doesn't require proof of damages. I'm deliberately avoiding specific figures, because they vary between cases and you should get current legal advice; but trust me that the cost of proper accessibility work is significantly lower than the cost of dealing with a lawsuit, even one that ends in a settlement.

Beyond the legal angle, there's plain business logic: people with disabilities are a large customer base, and an inaccessible site is a site voluntarily turning customers away. There's a bonus, too: many accessibility principles (semantic structure, alt text, heading hierarchy) overlap with the principles of good SEO. An accessible site is almost always a better-ranking site.

The accessibility statement: the page your site must have

Part of the requirements is publishing an accessibility statement on the site — a dedicated page, itself accessible and easy to find (usually linked from the footer), which details:

• The site's accessibility status — which adjustments it meets, under which standard and at what level
• Which parts are not accessible, if any, and why (for example, a third-party component you don't control)
• Contact details for the accessibility coordinator or responsible person — name, phone, email — so a user who hits a barrier knows who to turn to
• Physical accessibility arrangements, if the business has a branch or office serving the public (accessible parking, wheelchair access, and so on)
• The date the statement was last updated

An accessibility statement is not marketing copy, and not a file to copy-paste from another site. A statement declaring "this site is fully accessible" when it isn't can actually make your position worse — it documents, in your own words, that you knew what was required.

A practical checklist: where to start

If you've read this far and want to know what to do tomorrow morning, here's the order of operations I recommend:

1. Audit the current state. Run an automated scan (tools like Lighthouse or WAVE give a free first impression), but remember automated testing catches only a portion of the issues. Manual testing with a keyboard and a screen reader is the real test.
2. Navigate your site with a keyboard only. Try reaching every menu, button, and form without touching the mouse. If you get stuck, so do your users.
3. Check your images. Do meaningful images have descriptive alt text? Are decorative images marked as such?
4. Check contrast. Free tools will measure text-to-background contrast ratios against the standard.
5. Go through your forms. Labels, clear error messages, and the ability to complete and submit with a keyboard.
6. Handle video and moving content. Captions for videos, a pause control for carousels.
7. Write and publish an accessibility statement that reflects the true state of things, including contact details.
8. Set up ongoing maintenance. Accessibility is not a one-time project — every new page, banner, or plugin can break it. Fold an accessibility check into every significant update, and if your site accumulates technical issues over time, proper fixes and maintenance work is the place to address that too.

And if your site is old, built on an outdated template, or full of code nobody understands anymore — sometimes rebuilding it as an accessible site from the ground up is cheaper and simpler than retrofitting accessibility onto what exists. That's a calculation worth making with open eyes.

Bottom line

Website accessibility in Israel is a legal obligation, but I'd suggest looking at it another way too: it's an opportunity to build a better site — one more people can use, one Google likes more, and one that isn't waiting for a demand letter in the mail. A floating widget won't do the job; professional work on the code, content, and structure will.

Feeling like your site isn't there yet? I offer a professional accessibility audit and remediation to IS 5568 — get in touch and we'll go through it together, no jargon and no scare tactics.