What WCAG 2.1 AA Actually Means for Matterport Tours

WCAG 2.1 AA is the standard that ADA, EN 301 549, Section 508, and Israeli Standard 5568 all point to. But what does it actually require when applied to a Matterport virtual tour? Here's the practical breakdown — criterion by criterion, with what each one means for your 3D experience.

WCAG in 30 Seconds

The Web Content Accessibility Guidelines (WCAG) are organized around four principles. All web content must be:

1. Perceivable — Users must be able to perceive the content through at least one of their senses.
2. Operable — Users must be able to interact with the interface.
3. Understandable — Users must be able to understand the content and how the interface works.
4. Robust — Content must work reliably across different technologies and assistive tools.

Level AA is the middle tier — not the bare minimum (Level A) and not the most demanding (Level AAA). It's what regulators worldwide have settled on as the reasonable standard for compliance. Every criterion below is a Level A or AA requirement.

Perceivable: Can Users See and Hear Your Content?

1.1.1 — Non-Text Content (Level A)

What it requires: Every non-text element needs a text alternative that serves the same purpose.

What it means for Matterport: The 3D environment itself is entirely visual. A standard Matterport tour provides no text descriptions of what the visitor is looking at. An accessibility overlay adds per-panorama captions that describe each space — "You are standing in the main locomotive hall, facing the 1920s steam engine" — so screen reader users and caption-reliant visitors know where they are and what surrounds them.

1.3.1 — Info and Relationships (Level A)

What it requires: Information and structural relationships conveyed visually must also be available programmatically.

What it means for Matterport: Hotspot buttons, the caption panel, language selectors, and accessibility controls all need proper semantic HTML and ARIA roles. A sighted user sees a button floating in 3D space; a screen reader user needs to hear "Info button: Locomotive Engine" with the correct role and label. This is implemented through role="button", aria-label, and structured HTML that mirrors the visual hierarchy.

1.4.3 — Contrast (Minimum) (Level AA)

What it requires: Text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) requires at least 3:1.

What it means for Matterport: Overlay elements — captions, hotspot labels, buttons, controls — sit on top of a dynamic 3D background that changes constantly as the visitor moves. You can't control the background colour. The solution is semi-transparent dark backdrops behind all text elements, ensuring the contrast ratio is met regardless of what's behind them. A high contrast toggle lets users switch to maximum-contrast mode for even better readability.

1.4.11 — Non-Text Contrast (Level AA)

What it requires: UI components and graphical objects need at least 3:1 contrast against adjacent colours.

What it means for Matterport: The hotspot buttons, the language selector, the accessibility panel toggles — every interactive element must be visually distinguishable from the 3D scene behind it. This means solid-colour button backgrounds, visible borders, and clear focus states that don't rely on the 3D scene for contrast.

1.4.4 — Resize Text (Level AA)

What it requires: Text can be resized up to 200% without loss of content or functionality.

What it means for Matterport: The overlay must provide font size controls. When a visitor increases the text size, captions, hotspot descriptions, and all UI labels must reflow properly without overflowing their containers or overlapping other elements. This is implemented through a persistent font size setting that applies across the entire overlay.

Operable: Can Users Navigate and Interact?

2.1.1 — Keyboard (Level A)

What it requires: All functionality must be operable through a keyboard interface.

What it means for Matterport: This is the biggest gap in a standard Matterport tour. The default viewer is entirely mouse/touch driven. An accessibility overlay adds full keyboard navigation: Tab through hotspots, Enter to open them, Escape to close panels, arrow keys or shortcuts to move between panoramas. Every interactive element in the overlay — language selector, font controls, high contrast toggle, audio player — must be keyboard-operable.

2.1.2 — No Keyboard Trap (Level A)

What it requires: If a user can navigate into a component via keyboard, they must be able to navigate out.

What it means for Matterport: When a visitor opens a hotspot panel or the accessibility settings, pressing Escape or Tab must reliably return focus to the main interface. No component can trap keyboard focus in a loop. This requires careful focus management — tracking where focus was before a panel opened and restoring it when the panel closes.

2.4.2 — Page Titled (Level A)

What it requires: Pages must have descriptive titles.

What it means for Matterport: The page <title> must describe the tour: "Israel Railways Museum — Accessible Virtual Tour" rather than "Matterport Showcase" or a generic title. When the visitor navigates to a new panorama, the title should update dynamically to reflect the current location.

2.4.3 — Focus Order (Level A)

What it requires: Focusable components must receive focus in an order that preserves meaning and operability.

What it means for Matterport: Tab order must follow logical spatial order: accessibility controls first, then the language selector, then hotspot buttons in a meaningful sequence, then navigation controls. When a hotspot panel opens, focus moves into it. When it closes, focus returns to the button that opened it.

2.4.7 — Focus Visible (Level AA)

What it requires: Keyboard focus must be visible.

What it means for Matterport: Every focusable element needs a clear, visible focus ring. For hotspot buttons floating in 3D space, this means a high-contrast outline that's visible against any background. The default browser outline is often insufficient in a 3D context — custom focus styles with sufficient contrast and size are required.

Understandable: Can Users Follow What's Happening?

3.1.1 — Language of Page (Level A)

What it requires: The default language of the page must be programmatically identified.

What it means for Matterport: The HTML lang attribute must be set correctly: lang="en" for English, lang="he" for Hebrew, etc. When a visitor switches languages in the overlay, the lang attribute must update to match, and for RTL languages like Hebrew and Arabic, the dir attribute must switch to rtl.

3.1.2 — Language of Parts (Level AA)

What it requires: When content includes text in a different language from the page default, that text must be identified programmatically.

What it means for Matterport: If a Hebrew-language tour includes an English-language exhibit title, that title needs a lang="en" attribute. In a multi-language tour, each caption block and hotspot content region must carry the correct language identifier so screen readers switch pronunciation engines appropriately.

3.2.1 — On Focus (Level A)

What it requires: Moving focus to a component must not automatically trigger a change of context.

What it means for Matterport: Tabbing to a hotspot button must not automatically open the hotspot panel. Focusing the language selector must not automatically switch languages. The user must explicitly activate (Enter/Space) to trigger changes. This sounds obvious, but it's a common mistake in interactive 3D interfaces.

Robust: Does It Work with Assistive Technology?

4.1.2 — Name, Role, Value (Level A)

What it requires: For all UI components, the name, role, and state must be programmatically determinable.

What it means for Matterport: Every custom widget in the overlay — hotspot buttons, the audio player, the font size slider, the contrast toggle — needs appropriate ARIA attributes. A hotspot button needs role="button" and aria-label="Info: Locomotive Engine". The audio player needs role="region" and aria-label="Audio narration". The contrast toggle needs aria-pressed="true/false". Without these, assistive technology can't communicate what the controls are or what state they're in.

4.1.3 — Status Messages (Level AA)

What it requires: Status messages must be programmatically determinable through role or properties so they can be presented by assistive technology without receiving focus.

What it means for Matterport: When the visitor moves to a new panorama and the caption updates, that change must be announced to screen readers without stealing focus. This is implemented with an aria-live="polite" region that wraps the caption content. When the caption text changes, the screen reader announces the new panorama description automatically. Same for status messages like "Language changed to Arabic" or "High contrast enabled."

What a Standard Matterport Tour Fails

To put this in perspective, here's a scorecard of where a default Matterport tour stands against the criteria above:

A default Matterport tour fails or partially fails 14 out of 14 applicable WCAG 2.1 AA criteria. That's not a compliance gap — it's a compliance void.

The Standards That Reference WCAG

WCAG 2.1 AA isn't just a guideline — it's the technical standard that major regulations point to:

• ADA (United States) — Courts use WCAG 2.1 AA as the benchmark for digital accessibility under the Americans with Disabilities Act.
• EN 301 549 (Europe) — The harmonized European ICT accessibility standard directly incorporates WCAG 2.1 AA requirements.
• Section 508 (U.S. Federal) — Revised standards incorporate WCAG 2.0 AA, with agencies increasingly adopting 2.1 AA for new content.
• Israeli Standard 5568 — Aligns with WCAG 2.0 AA with additional provisions for Hebrew and Arabic language support.

Meeting WCAG 2.1 AA means you're compliant — or very close to compliant — with all four of these regulatory frameworks simultaneously.

You Don't Have to Build This Yourself

Implementing all of these requirements on top of a Matterport tour requires deep knowledge of the Matterport SDK, WCAG compliance, ARIA patterns, multi-language layout (including RTL), and 3D interaction design. It's a specialized intersection of skills that most development teams don't have in-house.

That's what Geemaps Accessibility does. We've already solved every one of these requirements in production — 42+ hotspots, 4 languages, full WCAG 2.1 AA compliance — for the Israel Railways Museum. We apply the same proven overlay to your tour.