I'm posting this message on the behalf on one of my patient as I'm working with during visual rehab
Hello and thank you for your work on iBus.
Environment:
- Debian 13
- GNOME 48.7
- Wayland session
- Orca 48.1
- iBus 1.5.32
- iBus with Mozc (Japanese input)
- Chinese input via intelligent Pinyin (iBus)
Issue:
When typing Japanese using Mozc, the candidate window appears visually, but Orca does not properly announce the candidate list or the currently selected candidate.
The same issue also applies when typing Chinese using intelligent Pinyin via iBus: the candidate list is visible on screen, but not correctly exposed to Orca.
As a result, CJK input must be performed “blindly” without reliable feedback about which candidate is currently selected.
Expected behavior:
The candidate list should be exposed via AT-SPI with proper accessible roles (e.g. list, list items, selected state), and selection change events should be emitted so that Orca can announce:
- The number of candidates
- The currently selected candidate
- Navigation between candidates
Detailed context example (Japanese):
A very common and problematic example is when typing “かみ” (kami).
Mozc typically proposes multiple candidates such as:
- 紙 (paper)
- 神 (god)
- 髪 (hair)
All three are extremely common words in daily Japanese, and they are pronounced identically (kami). Without proper speech feedback announcing the selected candidate, it is impossible to know which kanji is currently highlighted before confirming the conversion.
Another frequent example is “はし” (hashi), which may correspond to:
- 橋 (bridge)
- 箸 (chopsticks)
- 端 (edge)
These are very common words with identical pronunciation but completely different meanings. Without contextual audio feedback announcing the exact candidate, the user cannot safely commit text.
At minimum, Orca should be able to announce the currently selected candidate (e.g. “橋 selected, 1 of 3”). Ideally, contextual reading information (reading and/or short distinction) would also be available if exposed by the IME.
Detailed context example (Chinese Pinyin):
A similar issue occurs with intelligent Pinyin input. For example, typing “shi” may produce candidates such as:
- 是 (to be)
- 时 (time)
- 市 (city/market)
- 事 (matter)
All are extremely common characters with identical pronunciation in pinyin. Without speech feedback announcing the currently selected candidate, it is impossible to know which character is about to be committed.
This contextual feedback is essential to know precisely which kanji or hanzi is being committed in both Japanese and Chinese input workflows.
Important testing note:
By default, Orca uses espeak-ng, which does not properly support Japanese. Developers will not be able to properly test this issue unless they install a suitable speech backend.
On Debian 13, Japanese speech support for Orca can be enabled with:
sudo apt install open-jtalk open-jtalk-mecab-naist-jdic mecab mecab-ipadic-utf8 hts-voice-nitech-jp-atr503-m001 speech-dispatcher-openjtalk
Without this, Japanese output will not be spoken correctly.
For reference, I personally use Voxin voices (commercial, not redistributable), but both Voxin and OpenJTalk work correctly for testing Japanese speech output. The issue described here is independent of the speech engine itself; it appears to be related to how the candidate window is exposed via AT-SPI.
Additional note:
It is possible that this worked under X11 in the past, where the candidate window may have been exposed as a regular GTK window. Under Wayland, it does not seem to be properly exposed via AT-SPI.
If this issue does not belong in iBus, would it be possible to advise whether it should be reported against GNOME Shell or Orca instead? I would greatly appreciate help forwarding it if necessary, as GitHub and GitLab can be somewhat complex to navigate using a screen reader.
Thank you very much for your work and for any guidance you can provide.
I'm posting this message on the behalf on one of my patient as I'm working with during visual rehab
Hello and thank you for your work on iBus.
Environment:
Issue:
When typing Japanese using Mozc, the candidate window appears visually, but Orca does not properly announce the candidate list or the currently selected candidate.
The same issue also applies when typing Chinese using intelligent Pinyin via iBus: the candidate list is visible on screen, but not correctly exposed to Orca.
As a result, CJK input must be performed “blindly” without reliable feedback about which candidate is currently selected.
Expected behavior:
The candidate list should be exposed via AT-SPI with proper accessible roles (e.g. list, list items, selected state), and selection change events should be emitted so that Orca can announce:
Detailed context example (Japanese):
A very common and problematic example is when typing “かみ” (kami).
Mozc typically proposes multiple candidates such as:
All three are extremely common words in daily Japanese, and they are pronounced identically (kami). Without proper speech feedback announcing the selected candidate, it is impossible to know which kanji is currently highlighted before confirming the conversion.
Another frequent example is “はし” (hashi), which may correspond to:
These are very common words with identical pronunciation but completely different meanings. Without contextual audio feedback announcing the exact candidate, the user cannot safely commit text.
At minimum, Orca should be able to announce the currently selected candidate (e.g. “橋 selected, 1 of 3”). Ideally, contextual reading information (reading and/or short distinction) would also be available if exposed by the IME.
Detailed context example (Chinese Pinyin):
A similar issue occurs with intelligent Pinyin input. For example, typing “shi” may produce candidates such as:
All are extremely common characters with identical pronunciation in pinyin. Without speech feedback announcing the currently selected candidate, it is impossible to know which character is about to be committed.
This contextual feedback is essential to know precisely which kanji or hanzi is being committed in both Japanese and Chinese input workflows.
Important testing note:
By default, Orca uses espeak-ng, which does not properly support Japanese. Developers will not be able to properly test this issue unless they install a suitable speech backend.
On Debian 13, Japanese speech support for Orca can be enabled with:
sudo apt install open-jtalk open-jtalk-mecab-naist-jdic mecab mecab-ipadic-utf8 hts-voice-nitech-jp-atr503-m001 speech-dispatcher-openjtalk
Without this, Japanese output will not be spoken correctly.
For reference, I personally use Voxin voices (commercial, not redistributable), but both Voxin and OpenJTalk work correctly for testing Japanese speech output. The issue described here is independent of the speech engine itself; it appears to be related to how the candidate window is exposed via AT-SPI.
Additional note:
It is possible that this worked under X11 in the past, where the candidate window may have been exposed as a regular GTK window. Under Wayland, it does not seem to be properly exposed via AT-SPI.
If this issue does not belong in iBus, would it be possible to advise whether it should be reported against GNOME Shell or Orca instead? I would greatly appreciate help forwarding it if necessary, as GitHub and GitLab can be somewhat complex to navigate using a screen reader.
Thank you very much for your work and for any guidance you can provide.