Question
NW.js packaged app accessibility tree exposure and screen reader configuration
Ash Sage
0 reputation · 22 Feb 2024, 10:27 UTC
23.9K views1
Loading…
0 reputation · 22 Feb 2024, 10:27 UTC
A packaged NW.js application relies on the bundled Chromium accessibility tree to expose DOM roles, labels and states to native assistive technologies. The user-facing workflow needs predictable screen reader compatibility across platforms, but there is no documented NW.js configuration that explicitly controls or tests that mapping.
Accessibility support is determined by the Chromium version and host OS rather than NW.js-specific APIs, and the relationship between package manifest window settings and accessibility tree exposure is not clearly defined. The permission boundary between renderer content and native accessibility is also unspecified, and behavior is version-sensitive.
What documented manifest or runtime option exists to enforce consistent accessibility tree exposure for packaged windows? How is accessibility tree mapping expected to behave for windows created via window.open relative to the main window? Is there a supported method to verify screen reader compatibility within the NW.js user-facing workflow?
34775 reputation · 22 Feb 2024, 20:10 UTC
NW.js bundles Chromium's accessibility module, so the packaged executable exposes the standard accessibility API that screen readers such as NVDA, JAWS, VoiceOver, and Orca can query without additional code. No special manifest entry is required to turn this on.
The accessibility tree is present by default, but on some platforms you may need to launch the app with the --enable-accessibility flag or ensure the environment variable NWJS_DISABLE_ACCESSIBILITY is not set to 1. This flag forces Chromium to populate the accessibility tree for all windows, including those opened with window.open. Windows created via window.open inherit the same accessibility settings as the main window; there is no separate manifest option for them.
nwjs --enable-accessibility path/to/your/app.nwor set
nodewebkitNWJS_DISABLE_ACCESSIBILITY=0 in the environment.To confirm whether the flag is necessary for your setup, please specify the operating system and screen reader you are testing with, as certain OS‑reader pairs may require the flag or additional updates.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 22 Feb 2024, 20:25 UTC
When window.open is used inside an NW.js app, Chromium creates a new renderer for the child window. The accessibility module is initialized in that renderer with the same global flags that were set for the main process (e.g., --enable-accessibility or the NWJS_DISABLE_ACCESSIBILITY environment variable). Therefore the child window’s tree is a copy of the parent’s configuration, not a separate manifest setting.
NWJS_DISABLE_ACCESSIBILITY.window.open.Ctrl+Shift+I (or Cmd+Opt+I on macOS) to open DevTools, then switch to the Accessibility panel.UIAInspect.exe; on macOS, use the VoiceOver Utility. Verify that the accessible objects for both windows appear in the hierarchy.Because NW.js does not expose a dedicated manifest key for this, the only reliable way to enforce consistency is to control Chromium’s accessibility flags at launch and perform the above inspection on each window type.