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

[nvaccessAuto]

Attachment linkTypes.py added by norrumar on 2011-04-17 11:55 Description: Global plugin for knowing the type of the focused link, in Spanish. It contains a script that can be activated pressing control+shift+a, and reads: Link with anchor (or to a part of the same page), mail link, FTP link or external destination. Messages and documentation in Spanish. Tested on Firefox.

Edit: Attached file from old trac server. Please rename to linkTypes.py linkTypes.py.txt

[nvaccessAuto]

Comment 1 by jteh on 2008-07-23 23:32 This will not be done for 0.6p2.

Currently, announcement of same page links is quite difficult to implement because Firefox does not provide an easy way for us to do this.

Also, consider the fact that most users who do not use a screen reader actually can't differentiate between different types of links without looking at the URL, unless the site marks them in some way. If a site uses a graphic to denote external links, this should be obvious to a screen reader user also. As far as I know, same page links, mailto links, etc. do not look any different to any other link unless they are styled differently. Changes: Milestone changed from 0.6p2 to None

[nvaccessAuto]

Comment 2 by norrumar on 2011-02-12 12:44 I have used JAWS before NVDA, and JAWS announces different types of links: links on the same page, transfer files (ftp://), etc. I don't know how NVDA source code is built. But if the value of href attribute, in element, could be used, NVDA may announce, for instance, "Link on the same page" when href value begins: "#". I think that this enhancement would be useful.

Comment 4 by jteh on 2011-02-12 23:05 As noted in comment:1, I don't see why a screen reader should inform the user of this. Links don't look any different unless the site marks them differently (in which case this should be indicated in an alternative way for accessibility); they are just links. If this does get implemented, I certainly think it should be configurable and disabled by default.

[nvaccessAuto]

Comment 5 by jteh on 2011-02-12 23:14 @norrumar: Did you actually mean to accept this ticket or was that an error?

[nvaccessAuto]

Comment 6 by norrumar on 2011-02-15 07:46 I don¡t know the meaning of accepting a ticket, excuse me. About the option for wnowing the types of links, I think that implementing it as a configurable option is a good idea. I thing also that a screen reader, sometimes, sould implement task or options, although they ar not provided using accesibility or visual properties, for example ARIA or css. Links that points to the same page can be often created due to accesibility (or usability), because they get an easier navigation. Hotkeys (accesskey) perhaps are not visible on web pages, and so some web sites include an accesibility page, where these keys are represented on a table. Furthermore, if you can see the screen, I think that knowing the type of a link is easier: if it's a link to the same page, you can see the content that is pointed by the link, and the link text can be a reference for knowing its type. Excuse me for my bad English. Here is a link to a WCAG 2.0 document, because I can't explain you better what want to say: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skip

IThanks.

[nvaccessAuto]

Comment 7 by norrumar (in reply to comment description) on 2011-04-17 12:44 Replying to hkatic: I think that it would be useful that NVDA can read the type of link in virtual buffers without plugins, if possible. I have attached a plugin for this requirement, but You have to press control+shift+a, and when a link is focused, NVDA reads the type. I have developed the plugin in Spanish. If you are reading another element, not a link, and you press control+shift+a, NVDA could announce the type of the previous link, if it is focused although the cursor is not over that link. I have included five possible messages (in Spanish):

• Anchor: If the destination is a part of the same or another document, usually the same.
• Link to the same document.
• Mail link.
• FTP link.
• External link: For links to external resources. Furthermore, this script can:
• Announce the link URI, for instance: http://www.example.com#somewhere: Pressing control+shift+a two times.
• Copy the URI to clipboard: Pressing control+shift+a three times. I have tested this plugin on Firefox, Internet Explorer 8 and Chrome. The script doesn't work on Chrome.

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.

[nvaccessAuto]

Comment 8 by jteh (in reply to comment 6) on 2013-02-13 07:47 Replying to norrumar:

I thing also that a screen reader, sometimes, sould implement task or options, although they ar not provided using accesibility or visual properties

I don't see why a screen reader should read anything that isn't available to any other user, sighted or otherwise.

Links that points to the same page can be often created due to accesibility (or usability), because they get an easier navigation.

True, but these always say "Skip to content", "Return to top" or whatever, so what they do is obvious from the text. Saying "same page link" is just unnecessary verbosity.

Hotkeys (accesskey) perhaps are not visible on web pages, and so some web sites include an accesibility page, where these keys are represented on a table.

I don't quite follow how this is related. If it's a separate page, it's not a same page link.

Furthermore, if you can see the screen, I think that knowing the type of a link is easier: if it's a link to the same page, you can see the content that is pointed by the link

You can't if the content isn't on the screen (i.e. you have to scroll), which is the primary use of same page links.

and the link text can be a reference for knowing its type.

That's also true for screen reader users: the text indicates what the link will do.

[nvaccessAuto]

Comment 10 by mohammed on 2014-08-30 13:56 in page links (anchors) are almost always styled differently. Sighted developers or followers can correct me.

it's one part of NVDA that I couldn't get used to yet. I think differentiating between normal and in page links can make our lives easier. so consider this just a vote for implimenting this. if you're worried for verbosity we can probably wait until NVDA implements audio themes.

[mohammad-suliman]

I am adding my voice for this to be included in NVDA... This will give users more consistent experience when switching from the mobile to the desktop and vise versa. Voiceover includes this functionality. Thanks

[michelhebert]

I agree, this should be part of NVDA (even by default..I can't see a user not wanting to know the context of clicking a link). The main benefit of this enhancement, is to avoid confusing the user when the context changes. Clicking a link without context will definitely cause confusion/frustration for the user since it could open a new window/tab, open a mail client, download a file, jump to a section in the page etc..

It would definitely help with meeting WCAG 2.0 guideline 2.4 - Navigable

[jcsteh]

This applies to sighted users as much as screen reader users. In that case, the author has to explicitly choose to indicate this, in which case they should be doing so in an accessible way. If the author chose not to indicate this, that means a screen reader user will get an equivalent experience.

On Sat, 26 Nov 2016 at 7:00 am, michelhebert notifications@github.com wrote:

I agree, this should be part of NVDA (even by default..I can't see a user not wanting to know the context of clicking a link). The main benefit of this enhancement, is to avoid confusing the user when the context changes. Clicking a link without context will definitely cause confusion/frustration for the user since it could open a new window/tab, open a mail client, download a file, jump to a section in the page etc..

It would definitely help with meeting WCAG 2.0 guideline 2.4 - Navigable https://www.w3.org/WAI/WCAG20/quickref/#navigation-mechanisms

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/141#issuecomment-263021987, or mute the thread https://github.com/notifications/unsubscribe-auth/AD-TS-YbTX7Lzz3vgUP_m6TsejwdAiaBks5rB0xpgaJpZM4JJ4dk .

[feerrenrut]

As a sighted person I find often there is no easy way to differentiate in page links from regular links. I tend to hover the mouse on the link, and look at the link in the status bar. If its a #identifier I know. This probably does not apply to a more general population however.

I'm going to set the priority on this to priority 3. Since there is an add-on that provides this functionality already developed (However I'm not sure about the state of translations for this?).

[derekriemer]

Is there an addon for this?

If so, we might want to look at finding the author and adding it to the addons site.

On 11/26/2016 10:09 PM, Reef Turner wrote:

As a sighted person I find often there is no easy way to differentiate in page links from regular links. I tend to hover the mouse on the link, and look at the link in the status bar. If its a |#identifier| I know. This probably does not apply to a more general population however.

I'm going to set the priority on this to priority 3. Since there is an add-on that provides this functionality already

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/141#issuecomment-263102797, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivT-THR3NgjEPtYRTREaMqlUX4UXWks5rCRB5gaJpZM4JJ4dk.

--

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites: Honors portfolio http://derekriemer.com Awesome little hand built weather app! http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu Phone: (303) 906-2194

[feerrenrut]

@derekriemer I think so but I didn't actually look into it at all. One of the earlier comments (norrumar via trac) mentioned that they attached a plugin to do this.

@jcsteh could you dig up this attachment from trac and attach it here? Thanks!

[ehollig]

@feerrenrut or @jcsteh, could you dig up the attachment from trac and attach it here?

[feerrenrut]

I have updated https://github.com/nvaccess/nvda/issues/141#issuecomment-155278060 with the file

[Adriani90]

@feerrenrut unfortunately I cannot find the file. Can you please update this? I think the addon is only in spanish and is kind of proof of concept. @jcsteh this functionality might give a blind person another feeling when navigating a website than a sighted person has. But we have to bare in mind that sighted people do find much easier and much faster content on the same page than a blind user. Especially on complex websites. They can simply scroll down the page. If not announcing same page links, then at least someone should be able to assign a quicknavigation key in browse mode for same page links. This makes it easier to find relevant contents on complex pages. And in fact, it should not be very hard to do it since same page links are clearly defined in the source code of the websites.

[derekriemer]

it should not be very hard to do it since same page links are clearly defined in the source code of the websites.

Actually, NVDA doesn't have access to the source code of websites in modern browsers (ff, chrome, edge). We use the accessibility tree, and various accessibility API's to get this info. Whether a link is same page or not may not be even given to our view of the world.

[NickColley]

Hello :)

We've also run into this too, when testing our service a NVDA user found it difficult to know the difference between links and in-page links.

“While navigating through the header of the page I discovered that multiple skip links were present to move my focus further down the page, for example ‘Building your own layout.’ NVDA does not support the announcing of skip links meaning the links announced as standard links. I found it highly challenging to understand which links were standard links and which would move my focus down the page as both were located within the header. It would assist me if information such as ‘Jump to’ or ‘Move to’ could be included at the beginning of the skip links text to ensure it is made clear to users that the features are different. Please note the issue did not occur using JAWS but was consistent for VoiceOver for iPhone and Mac.”

You can see full details here: https://github.com/alphagov/govuk-design-system/issues/902

[JulienCochuyt]

As a sighted person I find often there is no easy way to differentiate in page links from regular links. I tend to hover the mouse on the link, and look at the link in the status bar. If its a #identifier I know. This probably does not apply to a more general population however.

NVDA users can do the same in the same situation that is, move the mouse pointer to the current review location then read the status bar, but location info are too often broken and then none of those two steps can be reliably performed.

Thus, I would advocate for a command to announce the href and eventual target attributes of the currently focused link, providing no more and no less functionality than sighted users get, yet working around the recurring issues we have with location info in this scenario.

[feerrenrut]

You can see full details here: alphagov/govuk-design-system#902

Thank you @nickcolley for the wonderful bug report in your link. Easy to follow and very helpful!

I would advocate for a command to announce the href and eventual target attributes of the currently focused link

@JulienCochuyt Yes, I think this is a good start. I think we could probably go further and see if we can use a heuristic to announce "in-page" when the href ends with #blah but otherwise matches the current document URL .

[JulienCochuyt]

@JulienCochuyt Yes, I think this is a good start. I think we could probably go further and see if we can use a heuristic to announce "in-page" when the href ends with #blah but otherwise matches the current document URL .

You are right, that would be icing on the cake, but if we find the slightest difficulty in having it reliable, I think it should by no mean stop the implementation of the basic needed feature.

[lukaszgo1]

In Firefox at least when link has focus its URL is present in the status bar. The problem is that Firefox's status bar cannot be easily accessed without using object navigation, but if it would be we would have the same functionality as sighted people without adding new gestures. I believe there is an issue discussing reading Firefox status bar.

[JulienCochuyt]

@lukaszgo1 wrote:

The problem is that Firefox's status bar cannot be easily accessed without using object navigation

Please see PR #9792 for a proposed solution to this issue.

[LeonarddeR]

I'd rather see firefox expose this as an IA2 attribute. @jcsteh, thoughts?

[jcsteh]

Firefox already exposes the target URL of a link (and the URL of a document) via IAccessible::accValue.

[ruifontes]

The Mozilla Apps Enhancements add-on, by Javi Dominguez, already allows the reading of status bar...

Maybe in 2020.1, NVDA should take care of status bar reading in all, or at least most applications...

Rui Fontes

Às 10:46 de 12/11/2019, Łukasz Golonka escreveu:

In Firefox at least when link has focus its URL is present in the status bar. The problem is that Firefox's status bar cannot be easily accessed without using object navigation, but if it would be we would have the same functionality as sighted people without adding new gestures. I believe there is an issue discussing reading Firefox status bar.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/141?email_source=notifications&email_token=ADZAPRWWH3KTDOINWYV3XMTQTKCQTA5CNFSM4CJHQ5SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZ2UYQ#issuecomment-552839778, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADZAPRVIEA26UVGX3FN74S3QTKCQTANCNFSM4CJHQ5SA.

[rkingett]

I would love if this could be added, in the form of an option, an add on, or a toggle, for the people who want this badly without imposing it on everybody else. Anything to make my web browsing a little less time consuming. I get it that sighted people don't have this kind of information, but I also don't understand the detriment to web navigation skills for VI people if we allow this in the form of an option. Also, if it's not possible, how can JAWS and VoiceOver do this?

If there's an English add on, give me the link. :)

[NiranjanGVala]

I was also looking for a similar functionality. I thought why not first look at the github issue if one exist? And I found this one. This issue is over a decade old. Still as with many valuable feature requests, This is not getting proper attention by NVAccess even there are a lot of comments on this issue. JAWS, Voiceover etc are giving this useful feature and NVDA is not. This is quite a saddened thing.

[amirsol81]

@seanbudd @jcsteh @Qchristensen @michaelDCurran @lukaszgo1 Any chance of implementing this long-requested feature? Apart from JAWS, VoiceOver on iOS also does that on iOS, and it would be a great addition. For a good example, please check the following page: https://brltty.app/download.html The list after the Download heading contains 8 in-page or same-page links, but - unlike JAWS and Voiceover - NVDA simply says, "link," as they are encountered.

[seanbudd]

Before acting on this, a tidy up or summary of this issue would be helpful. It is more challenging to act and follow these old issues with long conversations and no issue template.

[amirsol81]

@seanbudd As I'm not the original author, I can't edit the major portion of the issue - I can simply comment here. However, if this gets closed, I can open another one with more details, a summary and actual examples.

[Qchristensen]

Ok I've read the whole thread and here is my summary (not counting that many comments are simply "me to" arguing in favour of the feature):

This comment from 2011 contains a link to a Global plugin for knowing the type of the focused link, in Spanish.

There was an argument that implementing this would help (us? others?) meet WCAG 2.4.1 "Bypass Blocks" (I'm not sure on that - if the functionality is there, it's there, regardless of how we announce the link).

There is a link to a well written up UK gov issue for the same thing:

And finally, as to how his is communicated to sighted users: Sighted users are given a balloon with the link (where the status bar would be) which presents as "https://www.url.com/page.html#SamePageLink". A sighted user can look from this to the address bar and see that the address is the same up to the #. So, not necessarily immediately obvious, but doable easier than for a screen reader user.

Just to throw another observation of my own in:

• Is is arguably also useful to know that even if the URL is different, that you are going to an anchor on the page, because then you know you are not at the top of the page (which is conveyed to a sighted user via the position of the scrollbar on the right.

I'm in favour of implementing a solution to the original proposal. It could even be argued that IDEALLY the following could be conveyed in one way or another:

• When a link is a same page link
• When a link is to a different page
• When a link is to a different domain (an external link)
• When a link is an anchor on a different page

[amirsol81]

@Qchristensen Great summary. I really hope @seanbudd gives this a high priority as, apart from its usefulness, virtually all screen readers already offer it other than NVDA.

[dennischenfeng]

+1 on this issue. Would be great to have this implemented.

[bleeksstacy]

NVDA should identify samepage links just like VoiceOver on IOS and JAWS for Windows oon Desktops. this key information helps visually impaired screen reader users in terms of "expected behaviour". If the link is identified as "same page link" then the screen reader user will know that the focus will move down the page to the expected location within the same page. For "mailto" links, the user expectation is for a new email to open. With a standard link, the expectation is for a whole new web page to load. Therefore, since NVDA does not currently announce/identify same page links, it is very confusing when a same page link is activated but a new page doesn't load and focus moves to an unexpected location.

I too believe this issue must be resolved.

[ghost]

Is it going to take 100 years for you @nvaccess lyer people money/donation/whatever it called hunter to fix this? Enough is enough, no more bug reporting by me and probably @amirsol81. We have our own living and stresses and can take our business elsewhere at anytime. @amirsol81 always try to complain from JAWS to me and I always remind him about these only 2 issues causing me to not use and promote NVDA. Enough is enough, both @nvaccess and @amirsol81.

[seanbudd]

@armosouk80 - Your comment here and https://github.com/nvaccess/nvda/issues/11073#issuecomment-2273468328 is inappropriate and not inline with our code of conduct.

You do not have to participate in this repository if you do not wish to and it is stressing you out, nobody is forcing you. In fact, please take this warning as encouragement to take a step back.

[nvdaes]

I'm still interested in having this feature in NVDA. I've tried to create a new state added to all links for testing, named INTERNAL with a display string of _("internal"), but seems very complex to make NVDA to report this automatically, for example, in a continuous reading. It's reported when speaking the current object. Also, states are spoken before links, for example, "visited link", and if several states are spoken, may not be comfortable. An alternative that I consider perhaps easy to implement is to provide this in parentheses after the link text, as part of the link name. If you agree with this approach, I may try to create a PR for this. cc: @seanbudd @jcsteh

[nvdaes]

I'm thinking about creating an add-on as a proof of concept for this, to be deprecated if this is fixed in NVDA core in a better way. Perhaps, instead of adding more info to the link name, using the description attribute. If finally I create this add-on, I'll publish it on the store and will inform here.

[jcsteh]

As I noted in https://github.com/nvaccess/nvda/issues/141#issuecomment-263025684, I don't really agree with this. However, I've already explained why, so I'm not going to get into that again.

If I were going to do this, I would probably do it as a state, or if a state is problematic for some reason, as a new property. I firmly believe it should not be done as part of the label or description, since that conflates two things into one. It also means it can't be semantically differentiated, which impacts its ability to be abbreviated in braille, mapped to an audio cue, etc. in future.

[amirsol81]

@jcsteh So sorry to say this, but I really don't get your point about not implementing such a feature especially when almost all major screen readers out there provide such a functionality. I understand that there are more pressing bugs to fix and new features to implemented, but this is a highly requested feature, and, regardless of the arguments presented, I've heard from many JAWS users that both this issue and

11073 prevent them from a full switch to NVDA.

[nvdaes]

φor me, the last explanation of jamie is reasonable; anyway, pressing ŋvda k we can know the url, so maybe enough

[josephsl]

Hi,

What Jamie was looking at is not the viability (success) of this feature request, but implementation detail. Comments here provide justifications for this feature, and it was noted that web browsers can expose this information via accessibility API's.

I also agree with Jamie's comment: what if the label and/or the description for a link changes from "link (description)" to "link (description) (description)" e.g. "link (same page)" to "link (same page) (same page)" in the future? Wouldn't that confuse users who thought the link was an anchor in prior revisions of a web document? This is the similar state we found ourselves in when we tried using wxPython 4.0.4 a while back, one of the confusing cases of conflating labels with accessibility properties/states. Also, providing anchor state as part of link label/description is not a really good use of braille display real estate (I think).

Here's what I propose for implementation:

1. If not done so, define either a control type role or a state for anchor links (same page links).
2. Create speech and braille representations of the new anchor control.
3. Edit virtual buffers/web documents support modules and look for anchors using IA2 or other means.
4. Edit other support modules (such as UIA) for controls where we know (and you think) anchors are encountered.

Remember: when reading comments, think about: who the comment is from, their position and role in the community (including past status; Jamie is a good case as he was one of the original NVDA developers and now works for Mozilla), read the overall context of the issue, and differentiate between overall issue comment or implementation.

Thanks.

[josephsl]

Hi,

Actually, pressing NVDA+K may not be enough - if I read the issue correctly, what users want is exposure of anchor state/property as part of the virtual buffers/web navigation text/routine/view, similar to how unvisited/visited link property/state is announced. I think what makes this a bit complicated is both the detection and announcement of anchors, along with the "flat" (or close to flat) representation of a complex tree of objects called a web document.

Thanks.

[jcsteh]

As I said, I'm not diving into this argument. Pragmatically, a lot of users seem to want this, so I'm happy to provide guidance on how to implement it. I only re-stated my viewpoint because i do not want my willingness to help here to be seen as personal endorsement of the feature. But I don't have to endorse something to pragmatically acknowledge user demand.

This is going to require changes in the following places:

1. In controlTypes, where we need to add a new state.
2. In NVDAObjects.IAccessible.ia2Web.Ia2Web._get_states, where we need to get the accValue for the link, get the accValue for the document, compare them and set the new state if they're on the same page.
3. In the gecko_ia2 virtual buffer backend (in C++), where we need to expose the accValue for links.
4. In virtualBuffers.gecko_ia2.Gecko_ia2_TextInfo._normalizeControlField, where we need to do the same as 3), but use the accValue from the buffer. We should possibly have a common utility function in ia2Web to avoid as much code duplication as we can.

[jcsteh]

One potential snag is that we need to get the document URL. Right now, I think the only cross-browser way to do this is to walk the ancestry to find the document, which is potentially slow. Firefox does provide a way to get the top level document, but that's not going to work for iframes, since same page is relative to the nearest ancestor document, not the top level document. And regardless, Chromium doesn't support that. I could fix that fairly easily in Firefox, but you'd need to convince Chromium to do the same.

Actually, even that isn't going to work for the virtual buffer. In the non-iframe case, you can use documentConstantIdentifier, which is cached for the core cycle. But that won't work for the iframe case. I guess we could include accValue for all documents in the buffer, but I don't think _normalizeControlField can get ancestor control fields.

[amirsol81]

Apart from the extra time it takes to use NVDA+K for that, unfortunately NVDA+K itself is broken for many link types - see #14779 for instance.Message ID: @.***>

[rkingett]

What about distinguishing mailto links for now? I remember someone mentioning that above. I'm thinking we could do email links far easier than this for the moment because we could just pinpoint all mailto links? Or is that a ticket somewhere? I tried looking but was unable to find it.