Ren'Py Accessibility Mode: Exposing Default Text to Screen Readers

Direct answers

1. Should Ren'Py expose the default text displayable's content to screen readers when Accessibility Mode is active? Yes in principle. The current implementation enables self-voicing TTS but leaves external screen readers unable to read dialogue, UI or history text because renpy.text.Text renders as bitmap textures with no accessible tree.

2. Is it feasible to add a configuration flag that switches the default displayable between bitmap and accessible text rendering? Technically feasible but not trivial. It would require modifying Text's render path to conditionally construct platform accessibility objects alongside or instead of the bitmap cache. No such flag exists in released versions through 8.2.x, and no accepted PR or design document proposes one.

3. What performance trade-offs would result from rendering default text as accessible content in large, complex scenes? Measurable frame-time increases on lower-end hardware. Bitmap rendering is GPU-friendly and constant-time per frame. Accessible text layers require per-displayable platform object creation, text layout, caret navigation and event handling. Costs scale with visible text volume and complexity such as ruby, inline images, transforms, slow text and ATL animations.

Confirmed facts

• config.accessibility = True enables self-voicing TTS only; it does not expose text to OS screen readers.
• The default renpy.text.Text displayable renders via render_text_solid/render_text_shaded to bitmap surfaces. No accessibility tree is built.
• No public config flag, API or focus-management mechanism exists to switch rendering modes or set screen-reader focus on a text block.
• The limitation is documented in the Ren'Py GitHub issue tracker as a known issue.

Likely explanation

The self-voicing system already extracts plain-text strings for TTS. Exposing those strings to platform accessibility APIs via a parallel accessible tree is architecturally sound, but every text feature must be mapped to platform primitives. Windows UIA expects TextRange trees, macOS uses NSAccessibility, Linux uses AT-SPI/ATK. A cross-platform abstraction layer would be required, and focus management is not currently exposed to script authors.

Verification steps

1. Check version with renpy --version or renpy.version in-game. Behavior applies to 7.4 to 8.2.x.
2. Enable accessibility mode by setting config.accessibility = True in options.rpy and verify self-voicing speaks dialogue.
3. Test screen reader exposure with NVDA on Windows or VoiceOver on macOS. Navigate to dialogue text and observe that no text is announced via virtual cursor or browse mode.
4. Inspect renpy/text/text.py and renpy/display/core.py for Text.render to confirm bitmap surface creation and absence of accessibility tree construction.
5. Search GitHub repo:renpy/renpy accessibility text screen reader for current status.

Workarounds

• Duplicate critical text in hidden renpy.web.WebView or custom displayables wrapping platform text widgets. This breaks styling consistency and increases maintenance.
• Rely solely on self-voicing TTS for blind players and accept that external screen readers cannot navigate the game.

Missing diagnostic detail

What is your target platform matrix and minimum hardware spec. Performance impact of accessible text layers varies significantly by OS accessibility API overhead and CPU/GPU balance, which determines viability as default-on versus opt-in.