Re: Proposal to make checkpoint 9.1 for graphical / text viewports only

At 10:12 PM 2000-09-15 -0400, you wrote:
>Hello, 
>
>Checkpoint 9.1 in the 1 September draft [1] reads:
>
>   9.1 Ensure that when the selection or content focus changes, 
>       it is in a viewport after the change. [Priority 2] 
>
>I propose that this checkpoint be for text or graphical renderings
>only. I have trouble making sense of this requirement for audio
>viewports. (What does "in" mean in that context?).
>

AG::

You are correct that the checkpoint as written does not apply to pure-audio
interfaces.  The proposed remedy misses the mark a bit, because there is a
logical requirement that then goes un-covered.  The problem lies in the
statement of the parent guideline:

Guideline 9. Notify the user of content and viewport changes.

    Alert users, in an output device independent fashion, of changes to
content
    or viewports.

The actual requirement is something more like:

   [Guideline 9]  Orient the user after discontinuous changes in the dialog
state.

Changes to the dialog state include changes to the document and changes in
the state of the user's relationship to the document.  The latter include
transient properties  such as selection and focus.

   [Checkpoint 9.1]  Display the selected or focused content.

Audio display does not provide a persistent display.  Tactile and visual
devices do.  If a persistent display is available, ensure that the the
newly-selected or newly-focused content is actually displayed following a
change in selection or focus.  If the entire selection or focus content
does not fit within the limits of the display region:


a) if the region actually displayed prior to the change was within the
selection or focus, do not move.

b) if the region actually displayed prior to the change was not within the
newly selected or focused content, move to display [at least the initial
fragment of] such content.

If a persistent display is not in use, place a mark at the point
immediately before the newly-statused content.  This is a mark from which
the user may elect to, or the system may by default, depending on the
current step or smooth reading mode, start reading.

The root problem is in describing the interaction state as "changes in the
viewport" where "viewport" is not a device-independent concept.  The
viewport presumes a display medium which is persistent as viewed by the
user agent and random-access as viewed by the user.  Audio does not provide
such.

In a pure audio environment, the whole persistent context is in the mind of
the user.  In a GUI there is a large shared buffer of dialog information in
the display.  In audio there is no such sensible patch of interaction that
is maintained by the computer and accessed ad lib by the user.  The audio
display of content requires the elapse of time and time becomes a scarce
resource and the flowing of content through the display has to be managed
more carefully, which means that in accessing content which was edited at
the source for GUI use, it generally has to be managed actively.  

This need to manage content flow in the user agent is graphically
illustrated in the situation with repetitive page header contents.  As Kynn
Bartlett has explained lucidly in <
http://lists.w3.org/Archives/Public/w3c-wai-ig/2000JulSep/0356.html>, the
visual reading order of page contents is not the same as the order in the
hypertext coding.  In the hypertext encoding the content starts at the
upper left.  In visual reading, the user starts at the lead headline or
central layout block.


Note the term "discontinuous" changes in the state of the user's connection
with the document.  In at least one highly effective audio interface, when
cruising through the text, the technique is to announce "link" before
reading the content of a link.  It is not appropriate to shift to "announce
that this link has obtained focus" mode at this point because the "link" is
a bad enough break in the continuity of the text reading.  The author's
concept of the link is most clearly perceived by embedding the link text in
its context.  The conventions of the interface are that link activations go
to the most recently read link within some timeout window.  Activation
readiness goes with reading for the 'link' class of objects in this user
interface.  This is according to standard pattern, and does not constitute
an innovation, a discontinuity or introduction of anything new beyond the
fact that "what I am reading next is a hyperlink."

Another way to restate Guideline 9 would be to say that the user must be
briefed on jumps in context.  Anything that invalidates what the user might
otherwise be inclined to assume is still valid from their recent
experience.  Understanding the context in which the system will interpret
user actions is particularly critical.  And selection and focus are key
factors in that context.  So tracking selection and focus is required to
keep the system response predictable, by allowing the user to have in
memory the context which the system perceives for user actions.

Al

   For people with visual disabilities or certain types of learning
   disabilities, it is important that the [431]point of regard remain as
   stable as possible. Unexpected changes may cause users to lose track
   of how many [432]viewports are open, which is the current viewport,
   etc. User agents should notify the user of content and viewport
   changes caused by scripts, or allow users to turn off scripts entirely
   (refer to [433]checkpoint 3.6).

   Refer to [434]checkpoint 5.5 for requirements about notification of
   user interface changes through an API.

   Checkpoints for user interface accessibility:

   9.1 Ensure that when the [435]selection or [436]content focus changes,
          it is in a [437]viewport after the change. [Priority 2]
          Note: For example, if users navigating links move to a portion
          of the document outside the viewport, the viewport should
          scroll to include the new location of the focus.

> - Ian
>
>[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000901/
>-- 
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783
>

Received on Monday, 18 September 2000 10:39:20 UTC