Re: candidate AT technique: announce _internal_ links

At 01:56 PM 2001-08-27 , David Poehlman wrote:
>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.
>

AG::

Agreed.  Everybody wants that, the mainstream technology people, the assitive
technology people, the WAI, the W3C and so forth.  And there is progress
happening.  But the progress is not all done, by any means.

>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.

This set of guidelines will help.  There is more to do yet, as well.  The W3C
and others are as we speak currently scratching their heads trying to figure
out the best way to move ahead on this front.

Al

>
>----- 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>
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 15:39:20 UTC