Samuel Thibault (2023/09/04 21:01 +0200): > Ok, I see. > > So the behavior you expect is not actually implemented by Orca, it's the > a2 screen driver that takes precedence in the text fields
Well I am unsure about what you mean by text field here because, for the little of GUI I am using (Firefox essentially), I have observed this behaviour or not being able to use braille window navigation and routing keys in a very constant way. Is any place in a web page really a text-filed? I did'nt see this widget as that generic and thought it was basically used for text _input_ fileds but I may be wrong on that. Also, if the a2 screen driver "just" takes precedence, shouldn't things still work when it's not there? I was about to use that things used to work but now I am unsure because perhaps brltty-x11 has always been installed on my system so perhaps this is here unnoticed since several years. > knows it brings better support in that case (the cursor routing you get > is achieved by the brltty core itself, not the a2 driver which is only > the "messenger"). But that is not what is supposed to happen when you click (use cursor routing keys) on links in Firefox, right? It is this behaviour, for instance, which does not work without brltty-x11 and does work with it. > So it's not really Orca that "depends" on brltty-x11, it's just that > brltty-x11 is an interesting complement to Orca, to improve screen > reading. I don't think it's fair to put things this way frankly. Currently, you simply can't read the screen in braille without brltty-x11... And you can't activate links with the cursor routing keys, so you are forced to use tab to give them the focus so that you can thenpress Enter. This workflow is really less efficient than being able to activate links throughthe routing keys. Sébastien.