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 · 23 comments

Comments

Projects
None yet
10 participants
@nvaccessAuto
Copy link

commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2011

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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2011

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

This comment has been minimized.

Copy link
Author

commented Feb 12, 2011

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

This comment has been minimized.

Copy link
Author

commented Feb 15, 2011

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Author

commented Apr 17, 2011

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

This comment has been minimized.

Copy link
Author

commented Feb 13, 2013

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

This comment has been minimized.

Copy link
Author

commented Aug 30, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2016

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

This comment has been minimized.

Copy link

commented Nov 25, 2016

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 comment has been minimized.

Copy link
Contributor

commented Nov 25, 2016

@feerrenrut

This comment has been minimized.

Copy link
Contributor

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 closed this Nov 27, 2016

@feerrenrut feerrenrut reopened this Nov 27, 2016

@feerrenrut feerrenrut added the p3 label Nov 27, 2016

@derekriemer

This comment has been minimized.

Copy link
Collaborator

commented Nov 27, 2016

@feerrenrut

This comment has been minimized.

Copy link
Contributor

commented Nov 28, 2016

@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

This comment has been minimized.

Copy link
Collaborator

commented Aug 7, 2017

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

@feerrenrut

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2017

I have updated #141 (comment) with the file

@Adriani90

This comment has been minimized.

Copy link
Collaborator

commented Sep 28, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented Nov 26, 2018

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

This comment has been minimized.

Copy link

commented Jun 18, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.