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?). |
feerrenrut
added
the
p4
|
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 [email protected] <mailto:[email protected]>
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. |
|
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:
|
|
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 |
|
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: ***@***.***>
|
|
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. |
|
OK. I had thought about testing with _normalizeControlField and adding a new state in controlTypes, and about comparing the link value with documentConstantIdentifier. |
|
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 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. |
|
Thanks @jcsteh . |
|
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. |
|
@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. |
|
@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.
|
|
Hi @amirsol81: Though I'm in favour of implementing this feature as an option:
|
|
Anyway, I think that we can add an unassigned gesture to change this quickly. |
|
Sincerely, in these kind of things, I'm open and I understand the different points of views. |
|
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.
|
|
@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. |
|
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). |
|
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. |
|
@seanbudd suggestedthat this should be enabled by default, as other booleans. This is done in the PR. |
|
Congratulations @nvdaes, on solving a three digit issue! :) 14 years old!
|
|
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. |
|
@nvdaes Please accept my congrats! I also think same page links should be announced in local files like, say, NVDA manual or CHM files. |
|
Thanks @amirsol81. |
and others
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: