pan, zoom, rotate user's viewport

Note: this is not necessary a specific suggestion as to what the
UA guidelines should say.  I am going to make some comments based
on the draft summary and other things that are happening besides
publishing a guidelines document.

to follow up on what James Allan said:

> 2. The UA renders information in an accessible form:
> 2.1 UA provides multiple user customizable modes of output (information
> rendering) to meet their needs.
> 2.2 Provides access to and selection of all alternate representations of
> information within a web page.
> 2.3 Allow users to override author/UA presentation modes.
> 2.4 Allow redundant (multiple) methods of document navigation. At a minimum,
> provide navigation through keyboard at all times.
> 2.5 Provide web page orientation information (overview-# of links, # of
> images, etc.) so the user can quickly grasp content and context.(this one
> may be too specific, can't find the "general way" to say it.)

The XML working group has recently reorganized and spawned
several new working groups.  The WAI-PF is preparing to make
inputs to their requirements definition process.

There are requirements that you have been discussing in terms of
what the user need for an accessible dialog.  It will take some
dialog with the DOM, XML, and RDF workers in the W3C working
groups to figure out how these requirements are reflected in
requirements for the various component technologies of the web.

But let's start with the user dialog.

*** Methods for a robust or accessible user interface

What I would have said as a summary would be more descriptive of
what methods the user needs, that is to say more descriptive than
"several different" presentation modes.  I would say that we are
looking for some independent capability at the client to "pan,
zoom and rotate" the user's logical view into the information web
that the WWW offers.


This is to move from one view to a parallel view  of the same
general kind, but with a different starting point or location.

** Web capabilities to pan over the information include:

Good:  follow hyperlinks

Better: step through clickables, page-up or page-down and go-to-page.

Best: navigate in terms of table cells and document sections.

** Web capabilities to zoom the user's viewport:

read contents of clickable element (anchor or form field).

read contents of clickable in context (add label or TH abbreviation 
to the readout method).

page overview.

read table cell.

read table cell cell in logical context.

zoom to fit peephole: zoom browser presentation so an element
such as a table, cell or image just fits the current screen
magnifier visible region

** Web capabilities to rotate the user's viewport
	this can include emphasis or de-emphasis based on either
	physical control and display dimensions or cognitive 
	content dimensions.

substitute ALT text for image

control display/non-display of various media classes as in 
	caption control for SMIL

expand acronyms

substitute phonetic text for standard spelling when TTS is in effect.

re-flow table to list structure.

control use-TH vs. use-ABBR in table cell readout.

*** How this affects requirements for Web technology.

Note: all the examples I discussed above affect display.  There is a
whole parallel development of how the control device needs to be
substitutable to something that the user can manipulate.

One key concept is what I have here called "zoom" control or
what at other times we have talked about as "chunking."  The
point is that the author's chunking of the content is not
sufficient for all users.  Users need the capability to 
override the chunking of the information into "documents" and
be able to deal with a dialog which has a client-side-controlled
horizon for how much of the document is considered as the
immediate neighborhood of here and now.

For example, if you pick an H3 as the root of the current
neighborhood, then the table of contents of the document down to
the H3 level could become part of the logical navigation bar or
"nearby" vicinity.

In the past, the definers of Web formats have tended to assume
that the author's chunking is OK as a one-size-fits-all permanent
decision.  In talking about what the future might do better,
I would be inclined to raise this as an area where they should
try harder.

I hope that this fits with your understanding, that chunking on
more levels than just the HTML or XML document is in general
needed to meet the needs of people with disabilities.


Received on Wednesday, 16 September 1998 15:28:18 UTC