The European Accessibility Act and your 3D tour: where the risk actually lives

A compliance newsletter lands in a developer's inbox in the summer of 2025, subject line about a new EU law and the fines attached to it, and it gets forwarded to two people. The principal skims it and files it as a cookie-banner problem for someone else's marketing team. The evaluator who has to vet the 3D-tour vendor reads the same email and reaches the opposite conclusion: interactive 3D is a canvas full of accessibility failures, so buying a tour means buying a liability.

Both reactions are common, and both are wrong in the same way. Each one treats "accessible" as a fixed property of the rendering technology. It isn't. The risk lives in two different places, and which one you are exposed to depends on how the tour is built and on what gets authored around it.

First, whether the Act even reaches your tour

Start with scope, because the answer is not a blanket yes. The European Accessibility Act, Directive (EU) 2019/882, became enforceable on 28 June 2025, and it binds any business serving EU consumers regardless of where the company is registered (EUR-Lex, Directive (EU) 2019/882). What it covers is narrower than the fear-sell suggests. The obligation that reaches a website runs through the definition of e-commerce services in Article 3(30): services provided at a distance, by electronic means, at the individual request of a consumer "with a view to concluding a consumer contract."

That last clause is the wedge. A marketing microsite that only captures leads, a contact form, a brochure download, arguably concludes no consumer contract electronically. The moment the same site lets a buyer reserve a unit, pay a deposit, or sign a reservation online, the case for coverage gets much stronger. That line depends on the facts and the jurisdiction, so it belongs with your counsel.

Two exemptions: microenterprise and disproportionate burden

Two exemptions are worth knowing, and each is narrower than it first sounds. Neither is a self-serve escape you can assume applies to you.

The accessibility risk splits along the render path

Here is the point the sales-pitch posts and the fear-pieces both miss. The accessibility risk in a 3D tour is not one thing in one place. It splits along the render path.

The first half is decided by architecture. The dominant way to ship an interactive tour is a client-side embed that renders the 3D in the browser, a WebGL or point-cloud canvas running on the visitor's own device. That pattern has a well-documented failure mode: keyboard focus enters the canvas and cannot get back out. That is a direct failure of 2.1.2 No keyboard trap, and because most screen-reader users navigate by keyboard, it usually breaks 2.1.1 Keyboard and screen-reader access along with it (W3C, WCAG 2.2). If your tour is built this way, that trap is live by default, and no amount of alt text fixes it. In our experience the client-side canvas is simply the wrong default for a page that has to clear WCAG: it converts a solved architectural problem back into one you fight the browser to fix on every project.

The second half is never decided by architecture. A text alternative for the floor plan (1.1.1 Non-text content), captions on a tour video (1.2.2), an audio description of what the camera is showing (1.2.5): these get authored, per project, by a person, no matter how the pixels reach the screen (W3C, WCAG 2.2). The technical standard behind EU law, EN 301 549, pulls in the WCAG 2.1 A and AA criteria for web content, so the practical bar is WCAG 2.1 AA plus the standard's extra rules for things like video players (European Commission, accessibility standard). That division is what the rest of this piece turns on. The architectural half is settled the moment you pick a delivery method. The authoring half stays open on every project, which is where most of the work, and most of the exposure, actually sits.

What a streamed architecture changes, and what it doesn't

This is exactly where a vendor would overclaim, so I want to be careful. Vinode renders its 3D ahead of time and streams it to the browser as video rather than computing it on the device. One consequence is architectural and real: there is no live client-side WebGL canvas sitting in the page, so the on-device keyboard trap described above has nothing to trap. Delivery closes that gap on its own, as a property of how the tour is served.

That is the whole of the claim, and it is worth saying what it does not include. Delivering the tour this way brings its own obligations. A prerecorded tour with audio needs captions (1.2.2); a tour whose meaning is visual needs an audio description or a media alternative (1.2.5). Those still have to be authored. Streaming it as video is not automatic WCAG conformance, and there is no Vinode accessibility audit that says otherwise. One clarification while we are here: pixel-streaming approaches also avoid the local canvas, so what separates the two streaming methods is load time and cost rather than accessibility, a comparison we worked through in pixel streaming vs pre-rendered 3D.

When the Act misses you, and when streaming isn't enough

A few readers can stop here. If you are a genuine microenterprise selling a service, under ten staff and under the turnover line, the Act may not reach you, and the architecture question is moot for compliance purposes. If your site never lets a buyer conclude anything electronically, and never will, your scope exposure is thin enough to sit below your lawyer's other worries. If you operate wholly outside the EU with no EU buyers, this is the wrong statute for you; keep the split as a way of thinking and swap in your local rule.

The argument also fails in the other direction, and that failure is more common. A streamed architecture buys you nothing if you never author the captions, never write the text alternative, and ship player controls a keyboard user cannot operate. Closing the keyboard trap while ignoring the other three requirements just leaves you with a smaller gap. The reason to name the split is to push you through both halves.

A text alternative that stays in sync

1.1.1 is the criterion people satisfy worst, because the usual advice, "add alt text," produces a hand-typed string that goes stale the day the price changes. The floor plan is the hard case: a spatial graphic a screen-reader user gets nothing from unless the layout and the numbers also exist as real text.

There is a more durable place to put that. Vinode's Back Panel already holds each unit as structured data, dimensions, price, orientation, features, translations, and the per-unit brochure is generated from that same record. So the text equivalent of a floor plan can be bound to the data that already drives the page, and it moves when availability and pricing move, instead of being a caption someone forgets to update. One boundary, stated plainly: I can tell you the structured data exists and backs the brochure. I cannot tell you the generated PDF is itself a tagged, screen-reader-friendly document, because that has not been verified. Confirm it before you rely on it.

Four questions to ask any 3D-tour vendor

The practical upgrade is to stop asking the question every vendor can answer. "Is your tour accessible?" costs a salesperson nothing to say yes to. Replace it with four that have checkable answers, and ask them of everyone, Vinode included. It is the same discipline we brought to the broader interactive 3D vendor checklist.

1. Keyboard: can I operate every control and then leave? Tab into the tour, use it, and tab back out to the rest of the page with no trap (2.1.1 / 2.1.2). Run that yourself in the live demo before you believe it.
2. Is there a real text or data alternative for the floor plan? You want an equivalent that carries the layout and the numbers in a form a screen reader can read (1.1.1). Ask where it lives and how it stays current when a unit sells or a price changes.
3. Are the prerecorded tour videos captioned and described? Captions alone still leave out the screen-reader user who needs the described track (1.2.2 / 1.2.5). Ask to see one finished clip with both, not a promise that the player supports them.
4. Will you put accessibility in the contract? A written commitment, not a reassuring sentence in a sales call. Name the target (WCAG 2.1 AA, EN 301 549) and ask who owns the authored work, you or them.

The fourth question is the one that tests whether the first three are real. A vendor willing to write the first three into the agreement has told you something a demo never can. One who won't put them in writing has told you the answer just as clearly.