Most sites in Israel that announce they're "accessible" have installed one accessibility widget and called it a day. A widget helps, but it's not a standard, and it's not a substitute for testing against real users.
This article cuts through the marketing and explains what to actually check before kicking off an accessibility project — and where most budgets get wasted.
What "accessible" really means
The standard we work against is WCAG 2.1 AA, mirrored in Israel by IS 5568. In practice that's a long list of requirements around contrast, heading structure, keyboard navigation, form labels, and handling of dynamic content.
An accessibility widget gives the user controls (font size, contrast, spacing) — but doesn't fix the underlying structure. If the code is broken, the widget just hides it.
Three corners everyone forgets
1. Forms: Plenty of sites still skip a real label per input. A screen reader asks "what am I filling here?" and gets no answer.
2. Dynamic content: Banners, toasts, AJAX updates that never tell assistive tech the screen has changed.
3. Mobile menus: Hamburger menus that don't close on ESC, or don't return focus to a sensible place after closing.
Where to start
Start with an audit: automated scan (axe / Lighthouse), manual checks on key pages, and a screen-reader pass. Then build a remediation list sorted by cost vs. value — not chronologically.
The output: a short report with 5–10 items that fix 80% of the issues. Everything else gets documented honestly in the accessibility statement.