Re: [orca-list] Option to turn off auto-focus mode for native navigation (was Re: Tips and tricks for Orca and Firefox)

[Rastislav Kish <rastislav kish gmail com>]

Hello Joanie,

thanks much for the update, I've just installed it and it works great!

There is just one small problem, and that is automatic switching back 
from focus mode to browse mode.

When I'm filling out a form, for example the login form on 
messenger.com, when I turn on focus mode on the field for e-mail 
address, it would be great if it staied like that until I switch it 
back. Currently when I press tab to move to the next field, a password 
field in this concrete case, Orca switches back to browse mode and thus 
I must activate focus mode again.

But otherwise the function works on places I've tried so far, so i no 
longer have to be affraid of what a webpage does with my browsing mode. :)


As for correctnes of automatic focus mode, this heavily depends on how 
do we define the expected behavior. I didn't analyse Orca's code yet, 
but from what I've seen, I assume that it tracks focus change events of 
websites triggered by JavaScript and when the target is an edit field, 
it focuses it.

but now, the automatic focus mode depends on the concrete website and 
its manipulation with focus. Some programmers are aware of it and use 
it, some may be don't even know that something like focus even exists 
and some may be know, but don't care.

Thus, two websites with a very similar structure:

https://messenger.com/

https://discord.com/login

Can yield completely different behavior. Both of these websites have a 
login form and nothing more (from interesting elements), but while the 
firstone leaves focus on the top, the secondone moves it to e-mail field 
and Orca activates focus mode.


youtube.com and google.com is a similar pair, with the same behavior and 
differences, there is just not a login field, but a search field.


I'm affraid there is no way to fix this universally. There are just two 
possible approaches I can see here:

* Define each problematic website in Orca explicitly. This could work 
for the most used websites, but a deeper mapping is of course out of 
question, due to amount of websites on the net.

* Let the user define fields for automatic focusing himself. This may 
sound scary at first, but it's a quite interesting approach imo. There 
is an enormous amount of websites that all people use, but not that 
many, if you focus just on one person. Thus if you give people a way to 
configure the focusing, everyone would cover his favourite websites in a 
way that he / she prefers the most, and thus automatic focusing would be 
very predictable, as the user configured it himself.


This configuration, if I was developing it, would need to meet 3 conditions:

* There should be a really easy way to do it. My development motto is 
"Unpractical technology is almost like no technology at all", and I 
would stick with it here too. I would make one shortcut for explicit url 
mapping i.e. after pressing for example orca+f on the search field on 
google.com, orca would set this edit field as target for google.com. Url 
patterns could be configurable with a different shortcut, which would 
show an input dialog allowing user to set the pattern. I wouldn't bother 
with an interface in settings, I hate creating guis, so I would most 
likely store all url mappings in a yaml file, which anyone could easily 
edit with Pluma or another editor of their choice.

* Automatic focusing should only happen if there is a mapped pattern for 
it. This is a good thing not just for predictability, but also taking in 
the fact, that allowing user to prevent a particular field from being 
automatically focused, like the login field on:

https://qcsalon.net/

which is probably the most annoying login field I've ever seen, would 
require an additional notation and shortcuts, which would be unnecessary 
when there is a way to avoid them.

* There should be an easy way for deleting a url mapping. This should be 
simple to do, even without an additional shortcut. When user presses a 
shortcut for url mapping, if focus points to a edit field, the mapping 
is created, otherwise deleted (if it exists of course).


I don't know how exactly accessibility and web navigation on Linux 
works, but if Orca has at least possibilities like JavaScript on average 
website, this should be doable quite easily.

It would require a bit reconstruction of the current system of course, 
but on the other side, it would solve the problem with unreliable 
automatic focusing once and for all, without dropping the idea.


I don't know about any other screenreader having something similar, so I 
would appreciate also opinions of other blind folks, whether they see 
this in the same way that I do.


But I can speak for myself at least, that if automatic focusing worked 
like this, I would definitely use it.


Best regards


Rastislav


Dňa 19. 8. 2020 o 12:26 Joanmarie Diggs napísal(a):
> Hey Rastislav and all.
>
> Comments inline below.
>
> On Sat, 2020-08-15 at 16:48 +0200, Rastislav Kish via orca-list wrote:
>
> > As for the disabling of autofocus, I would like to disable this
> > functionality completely, so Orca doesn't switch between modes under
> > any
> > circumstances, even after page load or refresh.
> "Any circumstances" is hard. But I just added a new option to Orca
> master which will attempts to do this for "native" navigation which
> right now means "anything which is not caret navigation or structural
> navigation" (so Tab, page load, etc.). Hopefully it will make things
> better.
>
> >   The problem with
> > automatic focusing is, that it's quite unpredictable, in all
> > screenreaders. On some sites it works, on some not, and because many
> > times I don't even want to write anything, I often find myself in
> > fight
> > with switching of modes before I'm able to do what I want. As I
> > said,
> > this is not just problem of Orca, but also Jaws, NVDA and other
> > screenreaders, that's the reason why I usually turn auto focusing
> > completely off.
> For those instances where Orca does something unpredictable it would be
> helpful to know. It could be the browser and/or author doing something
> bad. Then again, it could be an Orca bug. Then again, it could be an
> Orca feature that is not working the way you want. If the issue is on
> the side of Orca, and we all agree what the desired behavior is, I can
> of course fix/change Orca -- as long as I know about the issue and can
> experience it myself. :)
>
> Thanks for the answers and feedback, and please let me know how the new
> feature works for you.
>
> --joanie