What we built to meet Israeli Standard 5568 — and where we chose not to

Accessibility arrives at most websites as a widget. You install a script, a round button appears in the corner, and somebody ticks a box. We built this site differently, and this is the account of what that took — including the one place this site does not meet the standard, and why that is written down in the open.

The site was built to Israeli Standard 5568 at level AA, the Israeli adoption of WCAG 2.0, and the standard the service accessibility regulations point at. It carries one deliberate, documented exception, set out later in this guide. This is a description of how the site was built, not a certification and not an external audit.

The accessibility statement is not the accessibility

Regulation 35ה requires a statement setting out the state of accessibility and how to get in touch about it, naming a coordinator and their contact details. That is the easy part, and it is also the part most sites do without.

It is worth being clear about what the statement is: a document describing the situation. It does not make a site accessible and it is not a certificate. Its value is that it forces you to write down what you actually did, which is hard to do if you did not.

What actually made the difference

Three things contributed more than everything else, and none of them is visible on screen:

• A skip link that appears to a keyboard user and jumps past the navigation. Every page marks its content region as the target, so the jump lands somewhere real rather than at the top of the page.
• One focus ring, defined in one place. That sounds trivial and is not: component frameworks define focus rings of their own per component, so the global definition has to explicitly outrank them. Otherwise every button behaves differently and some show no focus at all.
• Honouring the user's reduced-motion preference in every layer. This is where it got surprising: the animation library we use is JavaScript-driven and never sees the CSS rule that disables animation. The preference has to be handed to it explicitly, or the site keeps moving for someone who asked it not to.

Those last two are the best illustration of how accessibility breaks: not because anyone ignored a requirement, but because it was enforced in one layer and not the next.

Why not a widget

We built our own accessibility menu (text scaling, high contrast, link highlighting, stop animations, a readable font) instead of installing a third-party widget. Two reasons.

The first: a widget adds a layer on top of the site, and it does not fix what is underneath. It does not turn an image with no alternative text into one that has it, it does not correct a heading hierarchy, and it does not make a control reachable by keyboard that was not. Ticking a box is not compliance.

The second is security. An accessibility widget is a third-party script with full access to everything on the page, forms included. That is a trade that needs justifying, and "so we would not have to build a menu" is not a justification.

Colour is the easiest part to get wrong

The brand's orange works beautifully as a surface and badly as text. So the site has two oranges: one for fills, and a darker one at a 7:1 contrast ratio on white for any orange that has to be read. The rule is simple: if you can read it, it is not the orange the buttons use.

Where this site does not meet the standard

White on the call-to-action orange gives a contrast ratio of 2.13:1. Level AA requires 4.5:1. That is a failure, and it is deliberate.

We showed the owner the alternatives that do meet the requirement, and he chose to keep the orange — it is the brand's call-to-action colour. What we did instead of hiding it: the limitation is written into the accessibility statement as a known limitation, and the menu's high-contrast mode swaps that orange for a darker version, so a visitor who needs the ratio can have it.

We are writing this here because it is the most useful part of the guide. Sites do not fail accessibility because nobody knew — they fail because somebody decided something and did not write it down. A documented decision with an alternative route is a completely different thing from a silent failure.

What to check before shipping a screen

Three things, every time: move through the screen with the keyboard alone and confirm you can reach everything and see where the focus is; check the contrast of every piece of text against the defined colours; and confirm one top-level heading per page with no skipped levels.

Right-to-left Hebrew is another layer of the same work — we wrote about it in RTL is not direction: rtl.

How we build sites with accessibility as part of them