Accessibility statement

1. Our commitment

SaveSmart exists to save anyone money, so it has to work for someone using a screen reader, typing without a mouse, enlarging text, or sensitive to motion on screen.

We treat accessibility as part of building rather than something added at the end: the adjustments are covered by the same automated tests that run the rest of the product.

2. The standard we build to

The service is built to Israeli Standard 5568, which adopts the WCAG 2.0 Level AA guidelines, and for some requirements we meet the stricter WCAG 2.1 levels as well.

It is tested in current Chrome, Safari and Firefox, in Hebrew (right-to-left) and in English.

3. What is already accessible

Full keyboard navigation, including a "skip to main content" link that is the first item on every page and lets you bypass the header and navigation.

Visible focus: every keyboard-reachable control carries a clear focus ring rather than relying on colour alone.

Semantic structure: headings in a hierarchy, landmark regions, and tables with row and column headers — so a screen reader can navigate by structure rather than only read a sequence.

Status messages are announced: adding an item, an error, or a quantity change are reported in a live region rather than only as a visual change.

Tap targets of at least 44 pixels, so the service is usable without precise finger control.

The "reduce motion" system preference is honoured: if you have set it on your device, animations do not play. Nothing on a page depends on JavaScript in order to be readable.

Fluid text sizes that respond to the browser's font setting, and colour contrast checked against the standard's requirement.

All text in the service is real text, never an image of text.

4. What is not yet accessible enough

We would rather state precisely what is unfinished than claim full conformance:

Barcode scanning needs a camera and is unavailable without camera permission. There is a complete alternative — typing the barcode, or picking the product from search — and no part of adding an item depends on the camera.

Receipt photography relies on automatic text recognition, which does not read handwriting. We say so on the screen itself, and the alternatives are pasting a list or typing it.

Our performance and motion checks have so far been run in a simulated desktop browser rather than on a real mobile device. On-device testing has not been done and is an open task for us.

The internal admin pages have not been reviewed for accessibility as rigorously as the public pages, as they are not open to the public.

The service has not yet had a full manual screen-reader review by an external tester. We intend to commission one.

5. Reporting an accessibility problem

If something is blocking you we want to know, and it will be dealt with.

Email: accessibility@kliksave.ai

So we can reproduce it, it helps to know which page it happened on, which browser and device, and if you were using a screen reader or other assistive software — which one.

We reply as promptly as we can. If our answer is not satisfactory, you can contact the Commission for Equal Rights of Persons with Disabilities at the Ministry of Justice.