GNOME.org
 

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

Hello Joanie,
I have pulled the current Orca master and the problem with forms seems to be fixed! Thanks much for this feature, it works perfectly! :)
As for what we mean under auto-focusing, yes, as you write it, it's very likely that we're really talking about two different things here.
That's in fact the reason, why I wrote before, that the correctness of auto-focusing depends on how do we define the expected behavior.
If it is solely the fact, that after triggering a focus change event by website Orca turns on focus mode, if the target is an edit field, then yes, auto-focus works really reliably and predictably in this manner.
What I was talking about with unpredictability was, that after visiting a webpage, Youtube for example, I can't predict, whether I will end up in browsing or focus mode and neither can I fix the default behavior if it's unwanted.
Of course now I can say, that Orca with auto-focusing on will anyway end up in browsing mode on Youtube, because i've checked it out while writing my previous e-mail and I still remember it. But After few weeks or months of not-visiting the page, I wouldn't be able to recall anymore, and thus for me as a human, the resulting mode would be unpredictable again.
Thus my approach would instead let the user say, whether focusing an element on a webpage is desired and which element should be the one focused.
On the other side, I understand your position as an accessibility developer, that you probably want the screenreader to follow native behavior of things as closely as possible.
Thus I'm thinking about realizing my idea as an Orca addon, which could anyone optionally use, if He / she likes the approach. I just have to figure out how to create a command for Orca, which would appear in the keyboard shortcuts settings, how to subscribe to webpage load event and finally a way to access dom of the currently active website somehow. :)
But anyway, thank you again for all your work on this issue, and on Orca in general! :) 


Best regards


Rastislav


Dňa 20. 8. 2020 o 15:31 Joanmarie Diggs napísal(a):

Hi again Rastislav.

So it seems like we might be talking about two different things and
calling both "auto focus". So I'd like to make a distinction just to be
sure we're on the same page (no pun intended).

Orca has a focus mode feature, and the ability to configure whether or
not Orca's focus mode feature gets automatically toggled on/off. This
is the thing I was talking about when I asked you about things Orca was
doing that was unpredictable/bad. And this is the thing I want to fix.

Then there's the behavior you point out, namely that some pages (e.g.
discord.com/login) assume that the user (all users) should be placed in
the login field. As a screen reader, I think Orca's job is not to
override the author provided interaction, but to present exactly what's
going on. Thus I don't think Orca should ignore the fact that focus is
in the login field and keep you at the top of the page. But from
reading your message, I'm starting to think this is the thing you want
me to fix. Is that indeed the case?

--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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]