NVDA doesn't know a difference between Links and Same Page Links

[nvaccessAuto]

Reported by hkatic on 2008-07-23 09:11 In virtual buffers, NVDA doesn't know a difference between external and same page links. So for example, any user including myself may be confuzed whyle viewing a Web page in FireFox for example where lots of links exist, because he or she may not know is this link going to another page or to any other place on the same page. So, it is required to make NVDA speaking "same page link" before any link which moves to a different part of the same page e.g. "same page link system requirements". The same applyes to FTP links and Send Mail links. Blocking #3434, #5190

[nvdaes]

OK. I had thought about testing with _normalizeControlField and adding a new state in controlTypes, and about comparing the link value with documentConstantIdentifier. But I didn't think about cases where documentConstantIdentifier is not enough, and I don't have experience working with C++. Hope someone takes care of this.

[nvdaes]

In case it's helpful, I'll start a draft pull request adding new states like: LINK_TYPE_INTERNAL, LINK_TYPE_EMAIL, LINK_TYPE_FTP, and adding these states in IA2web deppending on link values and link treeInterceptor.documentConstantIdentifier. I won't finish all the work since, as mentioned, I don't have experience with C++. I'll do it tomorrow and in the next days, unless someone sais that it's better that a unique person works on this.

[jcsteh]

i would suggest that we keep the scope of this issue confined to same page links rather than trying to extend it to email and whatever else. This is already subject to some controversy as it is, so overscoping only decreases the chance of making progress.

[nvdaes]

Thanks @jcsteh . I've opened a draft pull request just addressing links to the same page. I haven't added the changelog since it can be added later, when we know the authors of this pull request.

[nvdaes]

I comment here, in addition to comments on the PR oriented to developers. since comments here will be read by a larger number of people. I'm working on this, and after a pull request created by @LeonarddeR working in the gecko_ia2 virtual buffer backend an additional work from my side, same page links, at least in cases tested by me, are reported now, though the pull request is a draft. My comment is to point out that, as suggested by @jcsteh in a previous comment, my intention is to create a combo box that could be seen when the checkbox to report links is enabled in document formatting, to configure if same page links should be reported. This would be disabled by default.

[amirsol81]

@nvdaes Thanks for your efforts. Just one question: why do you intend to keep it disabled in the combo box? I think it should be enabled by default as it'll help more users or those who are familiar with JAWS and VoiceOver.

[XLTechie]

@nvdaes

As with other issues, given how many people have wanted this, I point out that disabling it by default seems self-defeating.

We should be proud of our new features, not make them have to be discovered.

If users don't like the change in behavior, they can ask how to turn it off, or look it up. Far more people don't read the changes file or the user guide, and don't go through all possible settings screens after each update, than the number that do.

[nvdaes]

Hi @amirsol81: Though I'm in favour of implementing this feature as an option:

• Sometimes we know that links are to the same page seeing the context, for example in tables of contents, like it happens in the NVDA user guide, or reading the label, for example when it is something like: "Up to the start of this page". In these cases announcing same page is verbose.
• Old users of NVDA may prefer to keep the classic option. I remember, when I used JAWS years ago, that reporting of "same page" not always seemed accurate to me, though I use NVDA since 2010 and I don't know about JAWS and VoiceOver on Mac. So we shouldn't assume that this feature will always be perceived as an advantage.
• I don't like the idea of making something just looking at other screen readers. The fact that something has been or is usual in certain screen readers is not a good argument for me, since I don't assume that they work better with these features.

[nvdaes]

Anyway, I think that we can add an unassigned gesture to change this quickly.

[nvdaes]

Sincerely, in these kind of things, I'm open and I understand the different points of views. If many people prefer to have this by default, I'll suggest to do like that, though I'd vote for having this disabled by default. After 14 years using NVDA, now I'm used to the classic behavior, and old users should also be considered.

[XLTechie]

I don't object to an unassigned gesture necessarily, but I don't think that is an answer to a question of whether NVDA should promote the new feature by turning it on by default.

It could be argued that unassigned gestures, are an expert user feature, and the majority shouldn't be assumed to be aware of them.

More on topic, however, I would say that most new features should default to on, as they likely would have if we had them from the beginning.

"Old users" are most well placed to easily and quickly find out how to turn something off, or to be able to guess that it probably can be turned off. So I don't worry about long experienced users much. It's the less skilled, and new users I think about, and those coming in from other screen readers, whose'' first impressions do matter.

Most other software products out there that I can think of, recognize that users don't think to try and change something small that has been one way for a long time. So when a new feature is introduced that effects that thing, they turn it on by default, as a marketing method, if nothing else. It raises awareness.

When Windows or Office adds a new feature, they either turn it on for you and make you turn it off, or they ask if you want it on in a prompt you can't ignore. Web browsers often do the same thing, especially Chrome. Firefox tends to pop up a page telling about their new features, and asking what you want to do or telling you how to manage them.

I'm not saying that we should do the "We've added this feature, do you want it on?" thing. However since we don't, non-risky features should be turned on when added, at least until a lot of user feedback comes in saying they wish it wasn't.

I personally don't care to hear "in-page link" announced for all such links. But enough users do, that other screen readers have had this as default for decades, and don't even make it possible to turn off (VoiceOver, for example).

Okay, those are my opinions on new feature enablement. I'll shut up now.

[amirsol81]

@XLTechie Agree with you whole-heartedly! You eloquently outlined what I was about to write. I also think this, and most new NVDA features, should be enabled by default.

[nvdaes]

Enabling this by default is been controversial. I'll ask also in the spanish community. I expect to commit changes related to this before my two weeks of hollidays (next Monday).

[CyrilleB79]

I am not personally expecting this feature and maybe I would disable it for myself. But the reason exposed by @XLTechie seems completely valid to me.

So unless someone expose a strong reason with evidences why this feature should be disabled, I'd vote to enable it. We may also enable it in alpha and disable it next according to first reactions.

[nvdaes]

@seanbudd suggestedthat this should be enabled by default, as other booleans. This is done in the PR. Thanks for your opinions.

[XLTechie]

Congratulations @nvdaes, on solving a three digit issue! :) 14 years old!

[nvdaes]

Thanks @XLTechie . I'm not sure if we should work on reporting also same page links, for example, for local files like the user guide. This works for http. If so, we can discuss this in a different issue.

[amirsol81]

@nvdaes Please accept my congrats! I also think same page links should be announced in local files like, say, NVDA manual or CHM files.

[nvdaes]

Thanks @amirsol81. For people interested, I've opened issue #17127 Please add other feedback there since this issue is closed.