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

[Joanmarie Diggs <jdiggs igalia com>]

Hey Rastislav.

Thanks for the testing. I just changed the new feature to not switch
into browse mode in the scenario you described (I hope). Please pull
master and re-test.

Thanks also for the detailed examples! I'll take a look at those
tomorrow or Friday. I won't be defining site-specific behavior in Orca
because that will be a never-ending slog of doom. But if I can
ascertain a predictable pattern, I might be able to make things suck
less.

--joanie

On Wed, 2020-08-19 at 19:04 +0200, Rastislav Kish via orca-list wrote:
> 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
> _______________________________________________
> orca-list mailing list
> orca-list gnome org
> https://mail.gnome.org/mailman/listinfo/orca-list
> Orca wiki: https://wiki.gnome.org/Projects/Orca
> Orca documentation: https://help.gnome.org/users/orca/stable/
> GNOME Universal Access guide: 
> https://help.gnome.org/users/gnome-help/stable/a11y.html