Accessibility Statement

Conformance level

This site and the product behind it were built to conform to the Israeli standard IS 5568 at level AA, which is based on the W3C's WCAG 2.0 guidelines, and to the Israeli Equal Rights for Persons with Disabilities (Accessibility Adjustments to a Service) Regulations, 2013.

Accessibility is implemented in the code itself — semantics, structure and navigation — not through a third-party accessibility overlay. That is a deliberate choice: an overlay widget layers itself on top of a site that is not accessible, whereas accessibility built into the source works with whatever assistive technology the visitor already uses.

What has been made accessible

• Full keyboard navigation — every action on the site and in the product can be completed with a keyboard alone, with no focus traps.
• Visible focus — the focused element is clearly indicated on every interactive control.
• Semantic structure — a correct heading hierarchy, landmark regions, and a skip link to the main content.
• Accessible forms — every field has an associated label, and error messages are tied to their field and announced to screen readers.
• Colour contrast — contrast ratios that meet level AA for both text and user-interface components.
• Alternative text — provided for meaningful images; decorative images are hidden from screen readers.
• Hebrew and RTL — the interface is fully right-to-left, with correct language marking on English passages.
• Text resizing — the layout stays readable and usable at up to 200% zoom.
• No flashing — the site contains no flashing content or forced animation that could put photosensitive visitors at risk.

How it was tested

Accessibility is verified three ways on every code change, rather than as a one-off exercise: automated checks with the axe engine against the WCAG 2.0 level A and AA rules; direct calculation of contrast ratios against the design system's own colour values; and structural checks through the accessibility tree — the same tree a screen reader reads the page from. Alongside those, we do a manual keyboard pass and check the layout on desktop and mobile.

Known limitations

• Guest-uploaded content — photos and videos guests upload to an event album arrive without alternative text, and we cannot compel the uploader to supply it. The album interface around them is accessible.
• The seating-chart editor — it is built on a graphical canvas. Alongside it there is a complete list-based alternative that works with a keyboard and a screen reader.
• Invitation design — event owners can change the colours and text of the guest invitation page. The defaults we ship meet the contrast requirements; a change that departs from them may not, and the editor warns about it.
• Third-party services — WhatsApp messages are displayed inside Meta's app, which is governed by its own accessibility policy and is outside our control.

We work through these limitations continuously. If you hit a barrier that is not listed here, please tell us — a report like that enters the fix queue, not a quiet inbox.

Other accessibility arrangements

Weddigo is an online-only service. We operate no physical premises that receive visitors, so the built-environment accessibility regulations do not apply to our activity. The service, our support and every way of reaching us are available through digital channels.

Found an accessibility problem?

If you encounter something that is not accessible, we would like to know. So we can act quickly, please include the page address, what you were trying to do, and which browser and assistive technology you were using. We aim to reply within 5 business days and to fix the issue as soon as possible after that.