Re: [orca] Re: Braille navigation issues with Orca 44.1
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.
Reply to: