Re: Simpler Point of Regard?

to follow up on what Paul Adelson said:

>  For one-dimensional displays such as audio or braille, it's
> not actually clear to me whether the above should refer to the
> word(s) last spoken or the point just past the word(s) last
> spoken. Perhaps the latter, since that would be the 'virtual
> cursor' position.

A very small point of caution, here.  pwWebSpeak chunks the text
into page elements which are phrases, longer than words, by some
rules unkown to me but by usage known to work.  We should not act
like we have a better vocal flow model than that.

For a given speech production engine, is is probably possible to
define a restart point defined for any interrupt time -- some
point in the text which is earlier and nearby.  So far as we can
determine at the moment, this may vary from language to language
and speech engine to speech engine.

If we perhaps get this debate off the slippery term "point of
regard" and deal with the actual screen and session elements
which are part of requirements for "precise positioning in document
on jump or restart" we can maybe move ahead.

> > |Guideline 5.6: Allow the user to search for information on the page
> > |   When a search matches, the point of regard is moved
> > |   to the matched location.
> >
> > Does this mean that the viewport moves to expose the matched search
> > text? Or does it mean that the selection is moved to the matched
> > search text? Or both?
> >
> 
> Gut reaction: both.

The found text wants to be selected.  It may not be something
which can receive focus.  In the case that it can't receive
focus, we have issues about where the focus should be [at old
place or at tab stop just before of after selected/found text]
and positioning of the found stuff in the window and viewport.

There is also an issue of how to synchronize the viewport and AT
cursors with the found or restart point in the document.
Currently there are modes to slave the system caret to what has
focus.  Can this be done for selection?  This relates to things
we have talked about, such as possible problems if the visitor
moves to an Hx element in a new frame which is a named anchor but
not an href-bearing i.e. focusable element.

Al

Received on Wednesday, 2 December 1998 15:18:08 UTC