Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
nvaccessAuto opened this issue Jan 1, 2010 · 36 comments
Open
Labels
enhancement feature/browse-mode p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.

Comments

@nvaccessAuto
Copy link

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
Copy link
Author

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
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

nvaccessAuto commented Apr 17, 2011

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

jcsteh commented Nov 25, 2016 via email

@feerrenrut
Copy link
Contributor

feerrenrut commented Nov 27, 2016

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?).

@feerrenrut feerrenrut reopened this Nov 27, 2016
@feerrenrut feerrenrut added the p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Nov 27, 2016
@derekriemer
Copy link
Collaborator

derekriemer commented Nov 27, 2016 via email

@feerrenrut
Copy link
Contributor

@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
Copy link
Collaborator

ehollig commented Aug 7, 2017

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

@feerrenrut
Copy link
Contributor

I have updated #141 (comment) with the file

@Adriani90
Copy link
Collaborator

@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
Copy link
Collaborator

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
Copy link

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: alphagov/govuk-design-system#902

@JulienCochuyt
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

@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
Copy link
Contributor

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
Copy link
Collaborator

@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
Copy link
Collaborator

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

@jcsteh
Copy link
Contributor

jcsteh commented Nov 12, 2019

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

@ruifontes
Copy link
Contributor

ruifontes commented Nov 12, 2019 via email

@rkingett
Copy link

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
Copy link

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
Copy link

@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
Copy link
Member

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
Copy link

@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
Copy link
Member

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
Copy link

@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.

@seanbudd seanbudd added the triaged Has been triaged, issue is waiting for implementation. label Jul 11, 2023
@dennischenfeng
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement feature/browse-mode p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
Development

No branches or pull requests