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
Comments
Comment 1 by jteh on 2008-07-23 23:32 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. |
Comment 2 by norrumar on 2011-02-12 12:44 |
Comment 4 by jteh on 2011-02-12 23:05 |
Comment 5 by jteh on 2011-02-12 23:14 |
Comment 6 by norrumar on 2011-02-15 07:46 IThanks. |
Attachment linkTypes.py added by norrumar on 2011-04-17 11:55 Edit: |
Comment 7 by norrumar (in reply to comment description) on 2011-04-17 12:44
|
Comment 8 by jteh (in reply to comment 6) on 2013-02-13 07:47
I don't see why a screen reader should read anything that isn't available to any other user, sighted or otherwise.
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.
I don't quite follow how this is related. If it's a separate page, it's not a same page 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.
That's also true for screen reader users: the text indicates what the link will do. |
Comment 10 by mohammed on 2014-08-30 13:56 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. |
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. |
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 |
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 ***@***.***> 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
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AD-TS-YbTX7Lzz3vgUP_m6TsejwdAiaBks5rB0xpgaJpZM4JJ4dk>
.
|
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 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?). |
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
<#141 (comment)>,
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
|
@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! |
@feerrenrut or @jcsteh, could you dig up the attachment from trac and attach it here? |
I have updated #141 (comment) with the file |
@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. |
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. |
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.
You can see full details here: alphagov/govuk-design-system#902 |
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 |
Thank you @NickColley for the wonderful bug report in your link. Easy to follow and very helpful!
@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 |
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. |
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. |
@lukaszgo1 wrote:
Please see PR #9792 for a proposed solution to this issue. |
I'd rather see firefox expose this as an IA2 attribute. @jcsteh, thoughts? |
Firefox already exposes the target URL of a link (and the URL of a document) via IAccessible::accValue. |
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
<#141?email_source=notifications&email_token=ADZAPRWWH3KTDOINWYV3XMTQTKCQTA5CNFSM4CJHQ5SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZ2UYQ#issuecomment-552839778>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADZAPRVIEA26UVGX3FN74S3QTKCQTANCNFSM4CJHQ5SA>.
|
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. :) |
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. |
@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 |
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. |
@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. |
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 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:
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:
|
@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. |
+1 on this issue. Would be great to have this implemented. |
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
The text was updated successfully, but these errors were encountered: