It is currently the prevalent practice that assitive technologies announce
hyperlinks. Before reading link text, they say 'link' or give some other
pro forma cue that what is about to be said constitutes a link. For
example, in authoring one advises against making the alt text for an image
link start with "link to" because it is so likely that the assistive
technology will already have identified the link by saying 'link.'
There is confusion quite frequently in browsing with screen readers when
one follows an internal link, a link to a destination in the same page one
is coming from. This is a minority occurrence; that is to say most often
links load an new page. In this case, the page you wind up on is the same
page you came from, and scrolling, top of page, etc. commands will get you
there and back as well as hyperlink following.
The candidate technique is that the assistive technologies should make this
distinction, and announce "internal link" or some equivalent phrase such as
"local link" for links where the value of the HREF attribute begins with
the hash symbol '#' indicating an internal link.
Please see
http://lists.w3.org/Archives/Public/wai-tech-comments/2001Aug/0004.html
for a recent example of users mention the confusion that arrises under the
common practice of having internal links that lead to a place where the
link text is identical to where they came from.
Confusion on following internal links is a recurring report; this is by no
means the first time I have heard this.
I don't think we can cure this in the authoring, and the fix is
straightforward in the User Agent. Even when the link text is not repeated
verbatim, the 'visited links' information makes internal links and links
directed to specific points in the page confusing in speech if this
distinction is not made.
Note how in the list-of-links auxiliary view, Lynx handles links with
#fragment clauses on them differently from references that take you to the
page root.
Al