Re: candidate AT technique: announce _internal_ links

The problem arrises with at in that often, we want to browse with
something that at is not wedded to or wedded to tightly.  For instance,
If I want to use netscape 4.75 with jaws right now, there is  alot that
is not available and not necessarily because the at doesn't make it
available.  Do we ask at to do much else in our document?  I want to be
able to use a future ua with an at such that the ua makes things
available to the at rather than the at coding for something for a
specific user agent.  "this page" links are good things for all to know
because they show that it need not be necessary to scroll a long way on
a page to get to a specific piece of content on a long page.  We often
see this in the form of a table of contents at the top of a page.


It seems difficult for at to code for more than one ua of a type without
having to do custom coding for each.  I would hope that our guidelines
would help to one day bring this to an end or at least nearly so.

----- Original Message -----
From: "Al Gilman" <asgilman@iamdigex.net>
To: "David Poehlman" <poehlman1@home.com>; <w3c-wai-ua@w3.org>
Sent: Monday, August 27, 2001 12:36 PM
Subject: 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 13:56:11 UTC