Re: [orca-list] Experimental focus versus browse mode committed to master

[Peter Vágner <pvdeejay gmail com>]

Hello,
Hacking it the way I've tryed is not likelly the final solution then. 
However when the code I've commented out is included then we are verry 
unlikelly to switch to browse mode. Forexample by going to google.com 
you will get the following:
- edit field will receive the focus and orca will switch to focus mode.
- Press the tab key you will focuss a button saying Google search. I am 
expecting to change into browse mode when tabbing into this because 
pressing the enter is the only action available for this control and 
when I am in browse mode  I can review this control using the arrow keys.
- The same goes for the I'm feeling ... button, other links and similar 
controls like this. Checkboxes and radio buttons also belong into this 
as they can be controlled from within the browse mode.
You were asking that if I would really like switching back and forth 
between focus and browse mode when filling a form. The answer to that 
question is yes. When I focus a link a button, a checkbox or similar 
simpler controls I want to get into browse mode automagically. I can 
arrow over the surounding text and when I have understood the text I can 
just press a tab key and continue filling remaining fields.

>          if not state.contains(pyatspi.STATE_FOCUSED) \
>             and not state.contains(pyatspi.STATE_SELECTED):

I think this prevents changing from browse mode to focus mode and is 
unlikelly to do something in focus mode if I understand it correctly. 
For example imagine I have opened up google.com, typed something into 
the search field, navigated to a google search button and switched 
manually to browse mode. Now I'll repeatedly press left arrow key. When 
cursor goes into the text I've just typed into the search field this bit 
of code kicks in. However what I'm trying to explain all the time this 
should become configurable in the final implementation.

I am afraid most likelly I am really acting on your nerves now. If you 
think it might be helpfull I can do some little demonstration using this 
and / or comparing it how the same scenario is performed with NVDA. If 
you like please choose a site or a form you like so it's something you 
know and can better comment on.

Most likelly I'll keep tinkering and experimenting so maybe I will post 
some more comments.

Thanks and greetings

Peter

On 10.08.2014 at 12:34 Joanmarie Diggs wrote:
> Hey Peter.
>
> On 08/10/2014 05:52 AM, Peter Vágner wrote:
> > I've just noticed another little thing. By looking at the orca master
> > head I can see now we are never changing from focus mode to browse mode
> > automatically. It's either a result of various hard to understand
> > suggestions or just a little left over from testing.
> It's not a little left over from testing. It's a deliberate change for
> the following situation: If you are in focus mode in a form and then Tab
> to something else like a checkbox, radio button, push button, or link,
> should Orca switch you back to browse mode? I personally don't think so.
> But if you do, then that should be discussed. And as a reminder (to
> others, more than to you): This change is just for automatic toggling
> back to browse mode; it doesn't prevent manual toggling.
>
> Getting back to automatic toggling and your hack for tinkering: Look
> immediately above the lines you comment out. There you'll find:
>
>          if not state.contains(pyatspi.STATE_FOCUSED) \
>             and not state.contains(pyatspi.STATE_SELECTED):
>              return False
>
> So if the object you move to is not focused or selected, Orca doesn't
> reach the code you commented out. Instead, it returns False to "use
> focus mode". In other words, the intent is not "never changing from
> focus mode to browse mode"; instead the intent is "don't automatically
> switch to browse mode unless you move to something which is not a widget
> or link." Having said that, there are undoubtedly bugs in the
> implementation. Having those reported (again concisely and with concrete
> steps to reproduce) would be helpful.
>
> Lastly, as you already pointed out, I'm headed to Toronto for the web
> accessibility development meetup at Mozilla. As a result, some of the
> immediate responsiveness you've witnessed from me the past few days will
> likely decrease a bit. But know that I'll catch up on the discussion and
> respond with questions, answers, and fixes each day.
>
> Thanks again for all the input!
> --joanie