Does the European Accessibility Act require or forbid JavaScript obfuscation?
Neither. The directive is written in terms of what a product or service must do for a user with a disability, and it says nothing at all about how the code that delivers it is written, minified, bundled or transformed. There is no clause you satisfy by protecting your bundle and none you breach by doing so. What the law reaches is the experience your interface produces, which means the relevant question is never whether you obfuscated but whether the rendered result still works for assistive technology. Two of the runtime defence options can change that rendered result, and those are the ones to review.
Which services does the accessibility regime actually cover?
The directive lists categories rather than industries, and the ones that involve a browser front end are the ones to check yourself against: electronic commerce, consumer banking services, electronic communications services, e-books and dedicated software, transport service websites and applications, access to audiovisual media services, and the software running self-service terminals such as payment, ticketing and check-in machines. Member states applied the measures from 28 June 2025 and enforce them through national market surveillance authorities, so the operative text is your member state's implementing law rather than the directive itself. Scope for your specific offering is a legal question, not an engineering one, and it is worth settling before you design around it.
What standard do the requirements get assessed against in practice?
For anything delivered through a browser, the harmonised European standard EN 301 549 is the reference, and its web content chapter adopts the Web Content Accessibility Guidelines at level AA. That is what turns an abstract legal duty into something a developer can test. It matters here because it gives you a concrete list to run a protected build against rather than a general worry: the same success criteria, the same automated checks, the same manual keyboard pass, just performed on the artifact you actually ship.
Do the code transformations themselves affect accessibility?
No, and the reason is structural rather than reassuring marketing. Renaming variables, moving string literals into a table, encoding literals, flattening control flow and reordering statements all operate on the program. Accessibility is a property of what the program produces: the elements in the document, their roles and names, the focus order, the contrast, the announced state changes. A transformation that preserves behaviour preserves all of that, because the same document is built by the same logic under different names. Accessible markup rendered by protected code is the same accessible markup.
Which option carries a genuine accessibility cost?
The developer-tools key blocking option, because of one line in what it emits. Alongside the function-key and modifier combinations it intercepts, it registers a global listener that calls preventDefault on every contextmenu event on the page. That is usually described as disabling right-click, which undersells it: the contextmenu event is also produced by the dedicated context-menu key on a keyboard and by Shift and F10 together. Suppressing it therefore removes a keyboard-reachable menu, not merely a mouse convenience, and the context menu is a route through which people reach browser reading, translation, spell-checking and text-selection features. If you are assessing against level AA, this is the option to review first and the easiest one to switch off.
Why did an accessibility overlay or extension stop working after we enabled runtime defence?
Almost certainly the anti-monkey-patching option, and the collision is inherent rather than accidental. That option takes a fingerprint of a list of built-in functions at startup and re-checks them on a heartbeat, treating replacement as tampering. Its default list includes the prototype method used to register event listeners, the timer functions, the network functions and the storage methods. Accessibility overlays, screen-reader helper extensions and assistive browser add-ons work by wrapping precisely those built-ins. The guard sees a legitimate assistive tool doing the same thing an attacker would do, and it cannot tell them apart.
How do we keep runtime defence without breaking assistive technology?
Use the two settings the option provides instead of abandoning the feature. There is an exclusion list that accepts the dotted paths you want left out of the integrity check, so a global that assistive tooling is known to wrap can be removed from the watch list while everything else stays covered. There is also a switch controlling the clean-realm comparison, which is the part that reads pristine copies of the built-ins out of a hidden frame. Turning the specific thing off is a supportable position; leaving a guard enabled that fires on a screen-reader user's own software is not.
Should we test accessibility against the protected build or against source?
Against the protected build, and this is the single most useful process change on this page. Teams habitually run automated accessibility checks in continuous integration against a development build, which is exactly the configuration in which the runtime defence options are inert, and then ship a production artifact where they are active. The two differ in precisely the area under discussion. Run the audit against the artifact that reaches users, and include a manual keyboard pass, because the context-menu behaviour described above is invisible to most automated scanners.
Does protecting our JavaScript affect the accessibility statement we have to publish?
It does not change what the statement has to say, because the statement describes how the service meets the requirements and what the known limitations are, not how the software was built. Nobody is entitled to an explanation of your build pipeline in that document. What would be relevant is a known limitation caused by a setting you chose, which is another reason to resolve the context-menu and integrity-guard questions before publication rather than describing them as limitations afterwards.
Can obfuscation make a service non-compliant on its own?
Only through its effects, never through its existence. If the protected build renders the same interface, exposes the same roles and names, keeps the same focus order and leaves keyboard interaction alone, then nothing about the transformation has any bearing on conformance. If a runtime defence option suppresses a keyboard-reachable menu or fights with assistive software, the resulting behaviour is assessable and the cause happens to sit in your protection settings. The transformation is not the risk; two specific options are, and both are configurable.
Are small companies exempt?
The directive contains an exemption for microenterprises providing services, defined by headcount and turnover thresholds, and it also allows for documented assessments where meeting a requirement would impose a disproportionate burden or would fundamentally alter the service. Both are narrower than they sound and both are evaluated against your national implementing law. Treat them as arguments your counsel may make with evidence you prepare, rather than a category you place yourself in unilaterally.
What is the shortest useful checklist for a team in this position?
Four items. Confirm with counsel whether your service falls inside the covered categories under your member state's law. Run your accessibility audit against the protected production artifact rather than a development build. Review the developer-tools key blocking option specifically for its context-menu suppression, and switch it off unless you have a reason that survives the keyboard argument. Test with at least one real assistive tool active if you use the integrity guard, and use its exclusion list rather than disabling the guard wholesale.