Scene2D actors and platform accessibility services: where should widget roles, labels, and focus order live in a libgdx game?

Question

I'm designing the UI layer of a libgdx game built on Scene2D (labels, text buttons, sliders, and a few custom actors rendered with textures). I want the user-facing workflow to be usable with screen readers and keyboard/controller focus navigation across Android, iOS, desktop, and GWT backends.

My understanding is that libgdx has no unified, backend-neutral accessibility API for Scene2D: Android exposes a mature accessibility model, desktop and iOS differ, and GWT renders to canvas, which the browser cannot interpret semantically on its own. So any accessible name, role, state, or focus order has to be modeled on my side and translated per backend.

The unresolved design decision is where that metadata should live. Option A: attach role/label/state data to Scene2D actors and write per-backend adapters that publish it to the OS. Option B: keep Scene2D purely visual and maintain a parallel accessibility tree at the application layer that mirrors the scene graph and forwards focus and change events.

Questions:

Which of the two approaches is more maintainable when custom actors render their own visuals and do not inherit standard widget semantics?
Is it realistic to prototype accessible focus order with libgdx's existing keyboard/controller input handling first, and only then wire platform announcements such as TalkBack?
For GWT, is mirroring the UI into hidden DOM elements the accepted way to make canvas-rendered Scene2D content visible to assistive technology?

Tasadduq Burney · Answer

AnswerKeep role, label, state, and focus-order metadata on the Scene2D actors themselves (Option A), and write thin per-backend adapters that read that metadata and publish it to each platform's accessibility API. Your premise is correct: libgdx has no backend-neutral accessibility layer, so the model must live in your code regardless — the question is only whether it shadows the scene graph or rides inside it.Why actor-attached metadata wins for custom actorsCustom actors that draw their own textures have no inherited widget semantics, so the descriptor is the only place their meaning exists. Storing it on the actor means the meaning travels with the element when it is re-parented, hidden, pooled, or replaced.A parallel tree (Option B) forces you to mirror every structural change — additions, removals, z-order changes, visibility toggles — in two places. With runtime-generated UI and custom hit-testing, drift between the trees becomes the dominant bug source.Option A still keeps rendering untouched: the descriptor is inert data (a field on an Actor subclass, or setUserObject()) that only adapters read.Option B is only worth considering if you need an accessibility representation that deliberately diverges from the scene graph (e.g., grouping several visual actors into one logical control). Even then, a hybrid — descriptors on actors plus a small override layer — is usually simpler than a full mirror.Prototyping focus order firstYes — this is the right sequencing. Implement logical navigation with libgdx's existing input handling (InputProcessor, Stage#setKeyboardFocus, gamepad polling) and verify tab/arrow/D-pad order purely in-game. Only after that order is stable should you wire platform announcements (TalkBack, VoiceOver, NVDA). Focus order is testable without any screen reader, and debugging announcement timing on top of a broken focus model is miserable.GWT and the hidden DOM mirrorYes, mirroring into DOM is the standard approach for canvas-rendered UI: browsers expose semantics through the DOM accessibility tree, and a canvas is an opaque bitmap without it. The mirror elements carry role, aria-label, and state attributes, are visually concealed (off-screen positioning rather than display:none, which removes them from the accessibility tree), and are updated whenever actor state changes. Manage focus on the mirror elements so keyboard and screen-reader navigation stay aligned with your in-game focus model.Keeping it in syncThe real maintenance cost of Option A is synchronization: whenever text, enabled state, or visibility changes, the descriptor and the adapter must be notified. Route updates through a single change listener or a dirty-flag pass in act() rather than scattering update calls.VerificationAndroid: enable TalkBack, swipe-navigate, confirm spoken label/role/state per actor.iOS: VoiceOver with touch exploration and rotor; check custom actors announce correctly.Desktop: NVDA (Windows) or Orca (Linux) against your adapter's bridge — note desktop Java accessibility support is the weakest link and may need a custom bridge.GWT: Chrome DevTools → Accessibility pane; confirm the mirror tree matches the Scene2D hierarchy.Assumption: this reflects long-standing platform behavior (TalkBack, UIAccessibility, ARIA); adapter API details should be checked against your libgdx version.

Scene2D actors and platform accessibility services: where should widget roles, labels, and focus order live in a libgdx game?

1 answer

Answer

Why actor-attached metadata wins for custom actors

Prototyping focus order first

GWT and the hidden DOM mirror

Keeping it in sync

Verification

Your perspective belongs here.

0 question comments