Word: browse mode, allow quicknav, e.g. h for heading, to for table, l for list

[nvaccessAuto]

Reported by kevinchao89 on 2011-11-26 19:29
Might it be possible to make it so that quicknav is possible within a formatted docx? e.g. h for heading, l for list, t for table, etc. Default for Word can be focus mode, but allow switching to browse mode. This will make it possible to quickly navigate around a well formatted document.
Blocked by #2975
Blocking #1307, #4189, #4485

[nvaccessAuto]

Comment 1 by mdcurran on 2011-11-27 07:16
Can't say its technically impossible, but its certainly would be a lot of internal work in NVDA. Currently the quicknav code is rather tighed just in to virtualBuffers. Definitely not going to be for 2012.1 at least.

[nvaccessAuto]

Comment 2 by briang1 on 2011-11-27 09:08
If you are being strict about not adding things the sighted do not get then I'd imagine this would not be a good move.

[nvaccessAuto]

Comment 4 by nikosdemetriou on 2012-02-02 15:07
Hi. I don't know if it is possible but perhaps instead of using quick keys navigation with in word documents maybe we could bring up the elements list with nvda+f7 and choose between links and headings. Heading navigation is useful for large documents such as the user's guide for plextalk ptp1 for example which is very bigg and it is not easy to jump to a chapter that interests us.

[nvaccessAuto]

Comment 5 by briang1 (in reply to comment 4) on 2012-02-03 09:46
Replying to nikosdemetriou:

Hi. I don't know if it is possible but perhaps instead of using quick keys navigation with in word documents maybe we could bring up the elements list with nvda+f7 and choose between links and headings. Heading navigation is useful for large documents such as the user's guide for plextalk ptp1 for example which is very bigg and it is not easy to jump to a chapter that interests us.

I'm not sure how this would work as we are talking about editable text here, not a web page.
Editable text is like focus mode and I've had trouble with other screenreaders that have keys that clash with some editors controls before which makes typing hard.

Is it really any faster to bring up a screenreader menu and select than using normal keys already defined in Word?

[nvaccessAuto]

Comment 6 by RobertSpangler on 2012-10-31 18:36
It would be nice to see this eventually but I understand how it could be tough to implement. Basically, there would just be a mode, like ctrl+z I think in JFW, that is activated to enable this feature. As far as it not being implemented because it isn't given to sighted people: it's because there is nothing equally equivalent. Sighted people can scan and jump through a document visually much faster than blind people can. So this would just add another tool to the blind person's ability to jump through a document faster.

[nvaccessAuto]

Comment 8 by dineshkaushal on 2014-08-28 10:07
I am working on this issue. Earlier I planned to implement virtual buffer for word and then realized that it would take a lot of effort. I am thinking if we could either provide list of elements or provide quick navigation by just blocking the typing keystrokes and then provide navigation without virtual buffer.

What could be the best strategy to block keystrokes for a document during quick navigation mode?

Could we use treeInterceptor for word document?

At the same time, I wonder do we really need to fix this issue? what if NVDA user guide could provide word keystrokes to do so?

If we want to navigate between headings, we could select headings in go to dialog (control + g) and then use control + page up or control + page down to navigate between headings. similar strategy could be used for other elements such as tables, graphics etc.

[nvaccessAuto]

Comment 9 by jteh (in reply to comment 8) on 2014-08-28 10:35
Replying to dineshkaushal:

I am working on this issue. Earlier I planned to implement virtual buffer for word and then realized that it would take a lot of effort. I am thinking if we could either provide list of elements or provide quick navigation by just blocking the typing keystrokes and then provide navigation without virtual buffer.

Mick and i have been discussing design plans for this recently. The current plan is as you suggest; i.e. not using a virtual buffer.

What could be the best strategy to block keystrokes for a document during quick navigation mode?

We discussed a few ideas, but I think a TreeInterceptor is simplest, even despite the fact that it's not quite the right thing strictly speaking because we're only dealing with one object.

If we want to navigate between headings, we could select headings in go to dialog (control + f5) and then use control + page up or control + page down to navigate between headings. similar strategy could be used for other elements such as tables, graphics etc.

I've argued this before too and this is why we haven't implemented it before now. I guess the problem is that it's somewhat inefficient to have to keep opening that dialog and changing the type each time you want to navigate to something different. It's also inconsistent with how navigation works in other complex documents.

[nvaccessAuto]

Comment 11 by blindbhavya on 2014-09-24 09:58
Hi.
Do you think the component of this ticket should be changed to Microsoft Office Support?
Also, its my opinion, the priority should be set to to Minor and not Trivial.
I completely agree with Comment 6
As far as it not being implemented because it isn't given to sighted people: it's because there is nothing equally equivalent. Sighted people can scan and jump through a document visually much faster than blind people can. So this would just add another tool to the blind person's ability to jump through a document faster.

Hopefully, this feature may be added soon in.

[nvaccessAuto]

Comment 13 by jteh on 2014-09-24 10:37
As noted in comment:9, there are already people looking into this. The work on #2975 is a prerequisite for this.

It's worth noting that you can already do this in Word by opening the Go to dialog (control+g), selecting the type of destination and then using control+pageUp/control+pageDown. This is a feature of Word itself.

[nvaccessAuto]

Comment 15 by blindbhavya on 2014-09-26 17:08
I am not sure how the blockedby field ticket is exactly the same as this one.
Anyways, you must have done it for some reasons. So, I just hope that this gets implemented at the soonest.
Good luck

[nvaccessAuto]

Comment 17 by jteh on 2014-11-05 03:55
Mick is doing this work in the branch for #2975.

[nvaccessAuto]

Comment 18 by bdorer on 2014-12-14 21:27
As #2975 is set to incubating may this ticket should set to incubating, too?

[nvaccessAuto]

Comment 19 by jteh on 2014-12-23 07:02
Done in #2975, which is now in master.
Changes:
Milestone changed from None to 2015.1
State: closed