Which Accessibility Standard Is Your Site Actually Built To?

“The site is accessible per the standard” appears in the accessibility statement of almost every Israeli website. The question almost nobody asks is which standard, exactly - and the answer has a practical effect on what your customer feels when they arrive from a phone.

The Israeli standard points at a document from 2008

The legal basis is the accessibility regulations, where Regulation 35 points to Israeli Standard SI 5568. That standard does not write the rules itself; it adopts an international document called WCAG, at level AA.

Here is the detail that goes missing almost everywhere: part 1 of the standard adopts the 2.0 edition, from December 2008. Not 2.1 and not 2.2. Plenty of Hebrew articles and accessibility plugins say “based on WCAG 2.1”, and that is simply not accurate.

2008 was before the iPhone 4. Almost everyone browsing then sat at a desktop. A document written that year does an excellent job on the things that have not changed, like alternative text or colour contrast, but it could not have known that within a decade most of your customers would arrive as a finger on a small screen.

We build to a newer version, deliberately

On every site we build we work against WCAG 2.2 at level AA, two editions past what the law requires. Not out of purism, for two practical reasons.

First: 2.2 contains 2.0 in full. Every requirement in the older version exists in the newer one. A site that meets 2.2 automatically meets the Israeli legal duty; the reverse is not true. Nothing is given up, only added.

Second: what was added between the versions is precisely the phone. This is not an academic nuance. It is three things you already recognise as a visitor:

The page does not slide sideways. The requirement is called reflow: on a narrow screen the content has to settle into one column without you dragging left and right to read a line. Everyone has met a site like that and assumed it was just “untidy”. It is a requirement in the standard.

A button is not too small for a finger. Version 2.2 sets a minimum touch target size. When a close button is too small, or two links sit too close together, people tap the wrong thing and give up.

You can always see where the focus is. Anyone navigating by keyboard needs to know where they are at every moment. A site that hides that marker becomes impossible to use without a mouse.

Notice that none of the three is an “adjustment for people with disabilities” in the narrow sense. All three improve the experience of every person trying to contact you from a phone, which is most of your customers.

And one more reason, coming from Europe

European digital accessibility regulation already requires version 2.1, and the European standard moves to 2.2 in its next edition. An Israeli business selling to or serving customers in Europe is already in that world. Everyone else gets a clear signal about where the requirements are heading, and there is no reason to build a site today against a document from 2008 when you can build against one that will still be right in three years.

And what it gives back, beyond compliance

This is the question a business owner actually asks, and it has three measurable answers.

Google and AI engines read exactly what a screen reader reads. A correct heading hierarchy, real alternative text and tags that describe the content are the same work that serves a blind visitor and an engine trying to understand what the page is about. That matters more here than elsewhere, because the Israeli standard promoted heading structure to a binding requirement while internationally it is only a recommendation. In other words, what the law obliges you to do anyway is also what improves your odds of being quoted by an AI engine.

Mobile experience translates directly into enquiries. A visitor whose page slides sideways, or who tapped the wrong button because two were too close together, does not write to tell you the site is inaccessible. They just leave, and you see it as traffic that never became a call.

And what you do not add saves weight. The common way to “sort out accessibility” is to paste in a plugin that adds a floating button. It ships extra code to the browser, slows the site down, and does not fix the problems in the code itself. A site built correctly from the ground up does not need it, and it is faster for the same reason.

How do you know it was actually done

This is the part easiest to skip. An accessibility statement is text you can copy in a minute; a real test takes time. So when someone tells you the site was checked, ask to see the document: what was checked, with which tools, at which screen widths, what was found, what was fixed, and what is still open.

We did it on ourselves. We scanned this site against WCAG 2.2 AA at two screen widths, then went through it by keyboard. The automated scan came back clean, and the manual pass found four more things - among them a skip link that looked entirely correct but did not actually move focus. We fixed them, and wrote a document that also says what has not been checked yet. That sounds like an admission, and it is the opposite: a document that admits what is missing is the only kind worth anything.

In short

The law in Israel points at a document from 2008, and you could stop there. We build to the 2023 edition, because it covers the law anyway and adds exactly what a person holding a phone is missing. It is part of the work on every site we build, not a paid extra and not a widget pasted on at the end.

To be clear: everything here is general information, not legal advice.

Want to know what your site is built to today? Let’s talk ↗