Blog Guides

Build for Meta VR Glasses on the web: eyes and hands first

Meta VR Glasses ship without controllers and use gaze to aim and a pinch to select, in a narrower view than Quest 3. What that means for a WebXR app, how to try it in an emulator today, and what to change in a scene built for controllers.

Michal Takáč 5 min read

View as Markdown

At Meta Connect 2026, Meta showed its VR Glasses: about 100 grams, shipping in spring 2027, running the same operating system, store and SDKs as Meta Quest. Two things make them different for anyone building a WebXR app. They ship without controllers, so eyes and hands are the primary input. And the view is narrower: Meta quotes 70 by 66 degrees against Quest 3's 110 by 96. This guide is about what a WebXR app has to do differently, and how to test it before the hardware exists.

The input model: look, then pinch

On the glasses you aim with your eyes and act with your hands. A pinch is the click. Meta's guidance for the web is to design around gaze-to-target and pinch-to-select first, then add controllers as an option for the people who buy them.

For a WebXR app this is close to something that already exists. On Apple Vision Pro, Safari exposes the same idea as a transient-pointer input source: an input that appears when you pinch, with a ray from where you were looking. Meta's Immersive Web SDK maps gaze and pinch onto its ordinary ray-pointer interaction, so objects that react to a controller's ray react to a gaze-and-pinch too, without gaze-specific code. The practical rule is the same either way: make every interaction work through a ray and a single select action, and never require a button that only a controller has.

The parts that are new:

  • Targets must be big enough to hit with the eyes. Gaze is precise in the middle of the view and less so near the edges. Meta's guide says targeting "becomes less precise near the edge of the visible area". Put the things people must hit near the centre, and make them larger than you would for a controller.
  • Hover is a gaze. Whatever you highlight on hover is now highlighted by looking. Keep hover feedback quiet; a scene where everything lights up as the eyes pass over it is tiring.
  • Mappings for controller habits. Meta's own table for porting: a controller ray becomes an eye or hand ray; trigger and grip become pinch, poke or a palm grab; a thumbstick scroll becomes a swipe or a pinch-and-drag.

The field of view

With a narrower view, anything placed where a Quest user would glance sideways is simply not visible. Meta recommends checking scene coverage against the glasses' view, and its emulator can mask the view to the glasses' angular bounds. Keep the things that matter inside the middle of the view, and put panels and menus where the head naturally rests rather than at the edges.

Trying it without the hardware

Meta's Immersive Web Emulation Runtime (IWER) is the library that emulates a headset inside a desktop browser. From version 2.5.0 it has a Meta VR Glasses profile: the view mask with the glasses' angular bounds, gaze emulation, and a "Gaze + Hands" input mode. In code it is one line:

import { XRDevice, metaVRGlasses } from 'iwer'

const device = new XRDevice(metaVRGlasses)
device.installRuntime()

With the device installed, a page that asks for an immersive session gets the glasses: gaze as the targeting ray, a pinch as the select, and the narrower view. The emulator's panel lets you move the gaze with the mouse and pinch with a key. It is an approximation of the angular coverage, not of the lens edges, and it is not the real display; but it is enough to find a button that sits outside the view, or an interaction that needs a trigger.

If you build with Meta's Immersive Web SDK rather than plain WebXR, its project config asks for the same things:

{
  "world": {
    "xr": { "features": { "handTracking": { "required": true }, "gazeTracking": true } },
    "features": { "fieldOfViewMask": true }
  }
}

gazeTracking: true requests gaze as optional; when the runtime does not provide it, IWSDK falls back to head pointing, which is the right behaviour for a Quest 3 user opening the same page.

What to change in a scene built for controllers

Go through the scene with these questions:

  1. Does anything need a button other than select? A grip, a thumbstick, an A or B button. Each of those needs a pinch, a poke or an in-scene button instead.
  2. Can everything that must be hit be hit by looking? Targets small enough to need a controller's precision need to grow, or move towards the centre.
  3. Is the important part of the scene inside 70 by 66 degrees from where the person starts? Load the glasses profile and look.
  4. Does the app still work with controllers? It should: the glasses support Touch Plus controllers, sold separately, and Quest users have them.

Doing this in Graspable

Every Graspable template already emulates a headset in the preview, through IWER. Since Graspable 0.9.46 the preview toolbar has a headset selector: Quest 3 or Meta VR Glasses. Choose the glasses and the preview reloads with the narrower view, gaze and pinch; record a session and it is saved as a fixture that the completion gate replays after every change, so a scene that stops working for eyes and hands fails the run.

The agent's own check does the same: ask it to verify the app on the glasses and it opens the project with that profile, enters XR and sends back what it sees.

Sources