Re: [orca-list] When pressing shortcuts outside of Orca, Orca announces the context again



Hey Alex.

Response inline.

On 02/28/2018 01:47 PM, Alex ARNAUD wrote:

Le 28/02/2018 à 12:31, Joanmarie Diggs a écrit :
What's happening is the window is getting deactivated and then
reactivated.

It's right but it's the same window that is activated and reactivated
why report it to the user?

I agree 100%. But imagine this scenario: You're in an accessible window.
Something causes an inaccessible window to suddenly become activated.
Orca doesn't present it because inaccessible windows don't emit
accessibility events. All Orca knows is that you're no longer in the
window you were in. You can't figure out what you're in either. But
clearly something isn't right because Orca is no longer talking.
Suspecting you landed in something inaccessible, you press Escape or
Alt+F4 or Alt+Tab. Because you're in an inaccessible window, Orca
doesn't know you pressed any keys. But your system knows you pressed
keys and gives focus back to the accessible window you were in a minute
ago. Orca is notified that you're back in that window. Should Orca
present it, letting you know that all is once again well?

If I understand what you're suggesting above, the answer would be "no"
because it's the same window that is activated and reactivated. Why
report it to the user?

Mind you, I hope that in the case like I describe above you would think
that Orca should present the window because otherwise the user wouldn't
know that they are back in familiar, accessible territory. The problem
is, we get accessibility events and have to make some guesses about why
we're getting those events. The cost of guessing wrong here means Orca
users might not be told when they enter a new window. The cost of not
trying to hack around this is that if a user zooms in or out with a
magnifier, Orca will be slightly chatty. Not presenting a newly focused
window seems like a big problem; occasional chattiness from zooming in
or out with a magnifier strikes me as a slight annoyance.

And do you see a way to grab keyboard events without emitting window
activate/deactivate events? It's a general issue on all events from Mate
to GNOME.

I'm not sure I follow you. But if you're suggesting Orca is causing
this, I don't believe that's the case. I believe you'd see something
similar if Accerciser was running and listening for events.

--joanie


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]