alternate flow for software interface area

In the UA telecon last Wednesday I took an action to write up an alternate
structure or flow in the area currently addressed under guideline 7.2.  So
here goes:

[guideline] Provide compatibility with assistive technology through
software interfaces.

[checkpoint] Usable from third-party software. [P1]

[checkpoint.sub-requirement] All support required from the browser for
separate-program access shall be bundled in the standard product
distribution; the user should not need to download any special browser
module or patch to work with the AT.

[checkpoint.sub-requirement] AT vendor can make install of their product
perform all necessary setup for communication between the two programs
without undue programming effort on AT vendor part or high skill level on
part of end user.  [Ian, fix English if this gets approved.]

[checkpoint] Complete coverage of Web document information [P1]

All data which the browser receives via web communication and which can
reasonably be expected to represent information shall be accessible through
the implemented software interface.

[note] Non-informative data

There are limits to the obligation of the browser to pass along data which
it is reasonable to believe are non-informative. An example would be when
removal of some characters [not fitting the document type syntax] happens
to enable a signed document to validate, whereas the document with the
stray characters retained fails to match the signature.  There needs to be
some error-recovery discretion retained by the browser.

[note] Use standard schemata

The use of DOM methods and HTML/XML structure in the programmatic interface
is covered further down in two checkpoints dealing with following
conventional and standard practice.  These apply both to information access
and to access to browse actions.

[checkpoint] Complete coverage of browse process [P1]

All browse states reachable through the built-in user interface of the
browser shall be reachable by exercising commands exposed to AT through the
software interface.


[note] Device independence 

Saying that assistive technology can exercise browse functions through the
inter-program interface implies that these functions can be exercised from
a program without regard to the presence or use of any particular hardware
user interface device.

[note] Non-requirement for perfect match in detail

The priority 1 checkpoint does not require that each user interface action
have a direct equivalent in the programmatic interface, only that all
cumulative effect be feasible when acting through the programmatic
interface.  But see the following.

[checkpoint] Mirror full UI [P3]

Emulation of each individual user action supported by the built-in UI of
the browser shall be possible from the programmatic interface.  This
includes all browser enhancements and short-cuts.  

[note] This is particularly important in scenarios such as low vision where
the built-in [e.g. graphical] display is used but the assistive interface
is used to exercise control.

[note] Division of labor between browser and OS.

Some browser functions may be implemented by transparent access to
operating system functions.  The browser inter-program interface should be
implemented in such a way as to cooperate with AT access exported by the OS
or other generic service so accessed.  The assistive technology needs
access to complete control of the browse process, no matter what module is
performing the service in the baseline [shrink-wrapped] scenario.  [I
believe we need more work on how to say this.  The principles of how the
user interface is shared between a unit application and the environment
prior to that application probably vary from system to system so that it is
hard to create a neutral statement of how this collaboration should be set
up.]

[dependency]  User control of Web document actions.

[editorial note:  This is called a dependency in this writeup because it is
a requirement that belongs elsewhere in the document, but it is needed to
set up a programmatic interface requirement].

To the extent that a browser supports dynamic web documents, that is to say
actions are taken pursuant to instructions contained in a document received
by web communication, the browser shall provide the end user with effective
means to supervise such activity.  In particular, the user shall have at a
minimum the ability to disallow all document actions, to require case by
case confirmation of document actions, or to permit automatic execution of
document actions without review.  Further screening criteria may be
supported such as signature checking, or classification of impacts.  Not
that there are potential benefits for usability by people with disabilities
if actions are classified by the nature of their impacts, such as just
changing colors for example.

[checkpoint] Confirm or disallow document actions [P1]

The user's ability to permit, review, or disallow document actions shall be
able to be exercised through the inter-program interface.

[checkpoint] Conformance to common practice [P2]

Where there are conventions supported by the inter-program information and
control interfaces of other applications likely to appear on the same user
system as the browser, the interface required here shall be implemented in
conformance with those practices.  This includes conventions promulgated in
associated with operating systems and programming languages.

[checkpoint] Conformance to cross-platform and Web norms [P3]

Where there are W3C or other specifications which apply across operating
systems and languages for aspects of the inter-program
compatibility/extensibility interface, these shall be followed.  This
includes but is not limited to the W3C recommendation for DOM1 [link to
"support Web Standards" clause].

Note: this means that the content and attributes of all syntactically
correct HTML elements will be accessible using the DOM core methods [DOM
experts, please verify].

Received on Sunday, 4 April 1999 16:30:13 UTC