The short answer
RubyMine's Find Action dialog (Ctrl+Shift+A) does not currently provide comprehensive screen-reader feedback, and that is a platform limitation rather than a misconfiguration on your side. The dialog is a custom Swing popup in the IntelliJ platform, and popups of this type have historically exposed an incomplete accessibility tree: the screen reader typically announces the search field but not the individual result items as you move through the list. Whether it should expose a dialog role, announce the focused action, and live-announce search updates — yes to all three under WCAG and ARIA authoring expectations — but those are fixes JetBrains must ship, not settings you can toggle.
Confirmed facts vs. likely explanation
Confirmed: JetBrains tracks accessibility defects publicly on YouTrack under the IDEA project, and screen-reader support for popups (including Search Everywhere and Find Action) has been improved incrementally across releases. JetBrains also ships a dedicated screen-reader mode (Settings | Appearance & Behavior | Appearance, or findable — ironically — via Find Action itself by typing "screen reader").
Likely, not confirmed for your build: the results list is a custom component whose accessible names are not fully populated, so assistive technology only hears the text field or a generic container. This matches the symptoms you describe — no focused-action announcement and an incomplete accessibility tree — but the exact behavior is version-sensitive, so treat it as a hypothesis until tested on your build.
What to do, in order
- Check your version. Help | About, then compare against JetBrains release notes and YouTrack accessibility issues for that build. Improvements landed across multiple releases, so upgrading may resolve part of the problem.
- Enable screen-reader support and restart. Settings | Appearance & Behavior | Appearance → "Support screen readers", then restart the IDE and retest Find Action. This changes UI behavior for assistive technology and is a prerequisite for a fair test.
- On Windows, verify Java Access Bridge. Swing apps require it for JAWS/NVDA to see the accessibility tree at all. Run
jabswitch -enable from the JRE's bin directory (or enable it via Ease of Access settings), then restart both the screen reader and the IDE. If the bridge is off, nothing in the IDE will be announced correctly and the dialog is not the culprit. - Isolate the limitation. Perform the same action via the main menu using keyboard mnemonics. If the menu path announces correctly but Find Action does not, the defect is specific to the popup — report it on YouTrack with your IDE version, OS, and screen reader.
Reliable workarounds
Until the dialog itself improves, the most dependable paths for screen-reader users are:
- Direct keymap bindings. For actions you use repeatedly, assign a dedicated shortcut in Settings | Keymap. This bypasses the dialog entirely and is the most robust option.
- Main menu keyboard navigation. The native menu structure generally exposes better accessibility than custom popups.
- Search Everywhere (double Shift). This dialog has received more accessibility attention in recent versions and may announce results more reliably — worth testing on your build.
On your three design questions
Exposing a dialog role (not alert — it is interactive, not a status message), announcing the focused result item during list navigation, and providing a live region or equivalent for result-count updates would all materially improve usability and align with standard accessibility guidance. These are appropriate content for a YouTrack issue rather than anything achievable through configuration.
One caveat: behavior differs between Windows (Java Access Bridge) and macOS (VoiceOver), so if you can test on only one platform, note that in any report — the fix scope may differ.
rubymine