Turning on the website widget

The website widget is the one channel with no registration step — it's live the moment you embed a line of HTML, because the Studio already knows everything it needs to know from the widget key alone.

1. The embed line never changes

<script async
  src="https://kav.example.gov.il/widget/w.js"
  data-kav-widget
  data-key="wk_your_org_web"></script>

Paste this once, before your page's closing tag, and you're done touching your own site's HTML. Which language it shows, which colors, which corner of the screen — all of that is decided server-side from the key, not from anything on the page. A branding change, a new module, a new language: published from the Studio, live immediately, with nobody who owns the website needing a ticket.

2. Set your branding, with a live preview

In City → Branding, you're choosing colors, a font from a fixed allow-list, uploaded logo and favicon assets, and the origins allowed to embed your widget key at all — which is what stops a leaked key rendering your branding on someone else's domain.

Every field here has a guardrail built in rather than left to review:

• Colors are literals — a value that doesn't parse is flagged on the field itself and blocks publishing; the preview substitutes a platform default rather than silently rendering something broken.
• Fonts come from a <select>, never a free-text family name.
• Images are uploaded to your organization's own storage and referenced by a key, not pasted in as a URL. SVG is refused, with the reason stated.

3. Contrast is checked before you can publish, not after

Because Israeli public bodies are legally obligated to procure accessible tooling (IS 5568, WCAG 2.2 AA), a color pair that fails contrast on your login page isn't a style suggestion — it's an error, and the publish button stays disabled until it's fixed. A pair that only just clears the bar is shown as a warning, since the next small nudge to that color could push it under.