Roughly one in five people lives with some form of disability — visual, auditory, motor, or cognitive. When your website or app is not accessible, you are turning away a meaningful share of your potential customers, and in a growing number of jurisdictions you are also breaking the law. Accessibility is one of the few areas where user experience, organic search, and legal compliance all improve from exactly the same work — yet in most businesses it sits at the bottom of the backlog until a demand letter arrives.
The legal picture: Israel and now the EU
In Israel, the Equal Rights for Persons with Disabilities Law and its service-accessibility regulations require any website providing a public service — an online store, a booking system, even a marketing site with a contact form — to be accessible. The technical bar is Israeli Standard 5568, which adopts the international WCAG guidelines at level AA. The law also requires a published accessibility statement, and it allows statutory damages without proof of harm — which is why accessibility litigation has become a steady industry, with small and mid-sized businesses as its favorite target.
Since June 2025, the European Accessibility Act adds a second layer: e-commerce, banking services, e-books, and other digital services sold to consumers in the EU must be accessible — and that applies to companies selling into Europe from outside it. If you run a store with German customers or a SaaS product with French users, EU accessibility requirements reach you without your ever opening an office there. For a country that exports software, that quietly turned accessibility from a local checkbox into a market-access requirement.
Why an overlay widget doesn't save you
The tempting shortcut is to install a floating accessibility widget — the familiar blue icon in the corner — and call it done. The problem: an overlay changes how the page is displayed, not how it is built. If images have no alternative text, if form fields have no labels, if the menu cannot be reached from a keyboard, a screen reader still gets stuck — and the site still fails the standard. Regulators and courts in multiple countries have made clear that a widget alone is not compliance. Real accessibility lives in the code: a correct heading structure, semantic components, proper focus management, and testing with the actual assistive technology people use.
Apps are covered too — and usually further behind
Websites get most of the attention, but service-accessibility rules apply to mobile apps as well, and the gap there is typically wider. The platforms provide excellent infrastructure — VoiceOver and Dynamic Type on iOS, TalkBack on Android — but it only works if developers use it: labeling elements properly, keeping a logical reading order, sizing touch targets generously, and making sure layouts survive enlarged text without falling apart. Bilingual apps add a twist: an interface mixing Hebrew and English is bidirectional, and it needs careful screen-reader testing in both languages and both text directions. Fifteen years of building Hebrew-first mobile apps have taught us where those corners hide.
Audit, fix, maintain — the process that actually works
Compliance work breaks into three stages. First, an audit: automated scanning across every page or screen, paired with manual testing using a screen reader and keyboard-only navigation. Automated tools catch only part of the problems — the rest surface only in real use. The output is a findings list ranked by severity and by effort to fix.
Second, remediation: start with critical blockers — anything that prevents a user from completing a task, like a form that cannot be submitted without a mouse or a button a screen reader cannot identify — then work through the experience-level issues. In most sites, the large majority of critical blockers concentrate in a handful of shared templates and components, so fixing them moves faster than the findings list suggests.
Third, maintenance: accessibility is not a one-time project. Every content update, new component, or campaign page can break it. The durable answer is wiring automated accessibility checks into the development pipeline, so a new violation is caught before it ships — and keeping the accessibility statement in sync with reality rather than aspiration.
A five-minute self-check
Want a rough read on where you stand before commissioning an audit? Try this now: put the mouse aside and move through your site with the Tab key alone — can you reach every link, button, and form field? Can you always see where the focus is? Then turn on a screen reader — VoiceOver on Mac and iPhone, the free NVDA on Windows — and try to complete your site's single most important action: submitting an inquiry, adding a product to the cart, booking an appointment. If you got stuck at any of those steps, so do your customers — and that is exactly where the legal exposure begins. A quick check like this is no substitute for a full audit against the standard, but it almost always surfaces the biggest blockers within minutes.
Accessibility is also just good business
Beyond the legal exposure, an accessible site is simply a better site. Proper heading structure and alternative text are exactly what search engines read, so accessibility work compounds into SEO. Sufficient contrast and clear forms lift conversion for every user, not only those with disabilities. And the market itself is large — the spending power of people with disabilities and their families is measured in billions. The door you open for compliance also lets customers in.
At MSApps, accessibility runs through our design, development, and QA work — from auditing an existing website or app, through remediation in the code itself, to embedding ongoing checks that keep you compliant as the product evolves. We hold ourselves to the same bar on our own site. If accessibility has been sitting in your backlog, talk to us — a structured audit is the right first step.