Accessibility: improve Codex support for NVGT/BGT workflows used by blind audio-game developers

Summary

Codex currently has a broader accessibility gap for developers who work with NVGT and BGT projects, especially blind or low-vision developers building audio games on Windows with screen readers such as NVDA.

This is not only a request for syntax highlighting or language recognition. The issue is that Codex does not yet provide a reliable end-to-end workflow for these ecosystems: identifying the project type, understanding common build/run commands, interpreting compiler/runtime errors, and presenting changes/output in a way that remains usable with screen readers.

Why this matters

NVGT and BGT are used in accessible-game and audio-game development communities. These projects are often created by and for blind users. When Codex does not understand these workflows well, the accessibility impact is higher than for a typical unsupported language because the affected developers are often relying heavily on keyboard-only and screen-reader-based interaction.

Improving this area would make Codex more useful to a group of developers who are already deeply aligned with accessibility-focused software creation.

Current behavior

When working with NVGT/BGT-style projects, Codex may be able to edit files as plain text, but it does not consistently:

• Recognize .nvgt or .bgt projects as a known development workflow.
• Infer likely build/run/test commands from project structure.
• Explain compiler or runtime diagnostics in a useful way.
• Suggest idiomatic fixes for common NVGT/BGT patterns.
• Provide project-aware help for audio-game scripting workflows.
• Keep terminal output, diffs, and iterative edits comfortable for screen-reader users.

Expected behavior

Codex should provide first-class or at least explicitly supported behavior for these workflows:

• Detect NVGT/BGT projects from file extensions and common project files.
• Offer sensible build/run commands when the relevant runtime/compiler is installed.
• Parse and summarize compiler/runtime errors in a way that is actionable.
• Understand common patterns used in accessible/audio-game development.
• Avoid assuming visual UI output is the primary feedback channel.
• Ensure the edit/review loop remains usable with NVDA and other screen readers.
• Consider adding small sample projects or documented guidance for NVGT/BGT users.

Accessibility impact

This affects blind developers and audio-game developers who depend on screen readers and keyboard workflows. Without better support, using Codex with these projects requires extra manual work to explain the language, project layout, build commands, and diagnostics repeatedly.

Environment

• Codex CLI: 0.154.0
• Local repo reference tested/inspected: openai/codex at 9e22e74e8d
• OS: Windows
• Screen reader context: NVDA / screen-reader-oriented workflows
• Relevant languages/tools: NVGT and BGT

Suggested next steps

A good first step may be to add recognition and guidance for these project types, even before full language intelligence exists:

1. Detect .nvgt and .bgt files/projects.
2. Document how Codex users should configure build/run commands for these tools.
3. Add a small fixture or example project that can be used for future regression testing.
4. Improve terminal/diff output paths that are already known to affect screen-reader users.
5. Gather feedback from blind developers who actively use NVGT/BGT.

I can provide small example projects and more specific reproduction cases if that would help.

Start with the Codex CLI workflow in the Windows environment described, using .nvgt and .bgt projects with NVDA as the initial reproduction context. Compare project detection, build/run guidance, diagnostics, terminal output, and edit/review behavior against the expected workflow; done requires a scoped, testable improvement rather than the full set of requested capabilities.