Re: candidate AT technique: announce _internal_ links

At 11:19 AM 2001-08-27 , David Poehlman wrote:
>jaws for windows already allows for this.  you can have "same page"
>links announced from within the html options of the configuration for
>the way jaws verbalizes information.
>
>A problem though is that often, for some reason, when the page is
>repositioned, we are placed at the top of the page rather than nearby
>the information targeted by the link.
>
AG::

Yes, but this is under the control of, and should be the responsibility of the
browser proper.  

For following hyperlinks that have a URI-reference containing a #fragment in
them, this should be considered required by Checkpoint 2.1 where it says

     * [39]Checkpoint 2.1 Render content according to specification.
       (P1)
         1. Render content according to format specification (e.g., for a
            markup language or style sheet).

However, is there anything that says the browser should establish and expose
programatically a view variable with is a location in the document which
the AT
will understand to be where to start reading after following one of these
links?

I believe that by only keying on focus, we have obscured or under-represented
this valid requirement, which is a cross-media feature of The Web (albeit the
details are format dependent).  The location indicated by the #fragment in a
hyperlink, on following that hyperlink, is where the referring page said to
go;
it is something that should absolutely be within the visual viewport, as we
have said for the current selection or focus.  It should actually be
positioned
in the viewport near the beginning and consistently positioned from case to
case.  Not dragged into the top of bottom of the viewport whichever is closer.

Likewise, there should be as I said above a marker for this location such at
reading can begin there, or just before there.

How is this addressed in the Techniques?

>Rather than target this exclusively at assistive technologies, it would
>be a good idea for all uas to provide this information in some fashion.

If we don't make clear the allocation of functions where there is a logical
allocation, we get bad results when both try to do something or neither.

Yes, the clean way to describe this is what constitutes maintenance of the DOM
and what constitutes optimization of the view.  And how multiple layers of
software can share in optimizing the view.  But that is a research and
development topic.  It helps to have hints as to who is the most likely
suspect
to do what.

Whether you distinguish same page links from general links is part of
optimizing the view, where the most common preference in visual view will be
not to distinguish and the most common preference in speech only will be
not to
distinguish.  The URI-reference itself in the hyperlink makes the distinction
available.  The Assistive Technology should at least have the capability, as
Jaws has, because their customers will want to turn this on and most of the
host browser's customers won't.  Coordinating the situation where both offer
the option means putting the rendered stuff in the DOM and this hangs on a
'views' module we don't have available to count on at this time.  So letting
the AT take the initiative, configurable by the user as opposed to
automagically coordinated under the sheets, is about the best plan we can ask
for.

What do you think?

PS:  Tell Rick Roderick about that Jaws adjustment.

Al

>----- Original Message -----
>From: "Al Gilman" <asgilman@iamdigex.net>
>To: <w3c-wai-ua@w3.org>
>Sent: Monday, August 27, 2001 11:17 AM
>Subject: candidate AT technique: announce _internal_ links
>
>
>
>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>htt
p://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
>

Received on Monday, 27 August 2001 12:15:55 UTC