W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 1999

review of section 6

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 23 Feb 1999 19:11:38 -0500 (EST)
To: WAI AU Guidelines <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.04.9902231908410.10835-100000@tux.w3.org>
I have interspersed my comments between (often lengthy) chunks of the
document (look for CMN:). Where I don't see any problems, I have left out
the relevant excerpt (look for SNIP)

  6.1 Provide information about the document view
          
   Users that are viewing documents through linear channels of perception
like speech (since speech is temporal in nature) and tactile displays
(current tactile technology is limited in the amount of information that
can be displayed) have difficultly maintaining a sense of their relative
position in a document. The meaning of "relative position" depends on the
situation. It may mean the distance from the beginning of the document to
the point of regard (how much of the document has been read), it may mean
the cell currently being examined in a table, or the position of the
current document in a set of documents.

   For people with visual impairments, it is important that the point of
regard remain as stable as possible. For instance, when returning to a
document previously viewed, the user's previous point of regard on the
document should be restored. The user agent should not disturb the user's
point of regard by shifting focus to a different frame or window when an
event occurs without notifying the user of the change. Disturbing the
user's point of regard may cause problems for users who have movement
impairments, who are blind, who have visual impairments, who have certain
types of learning disabilities, or for any user who cannot or has chosen
not to view the authors representation of information.

CMN: This paragraph (above) could be significantly trimmed without losing
any content.
     
SNIP

   6.1.9 [Priority 2]
          When a document is loaded or when requested by the user, make
available document summary information. 

CMN: This is too vague. What information is required?
  
   6.1.11 [Priority 3]
          Provide the user with information about document loading status
(e.g., whether loading has stalled, whether enough of the page has loaded
to begin navigating, whether following a link involves a fee, etc.)

CMN: This is also very vague. Perhaps this should be combined with 6.1.9,
and made explicit as to what tyes of information are required.

  6.2 Provide information about document structure
 
   Hierarchical navigation (through the document tree) is useful for
efficiently navigating the major topics and sub-topics of a document.
     
   6.2.1 [Priority 2]
          Allow the user to view a document outline constructed from its
structural elements (e.g., from header and list elements).

   6.2.2 [Priority 2]
          Allow the user to navigate the document tree.
   
   6.2.3 [Priority 2]
          Allow the user to navigate sequentially among headers.

   6.2.4 [Priority 2]
          Allow the user to navigate sequentially among block elements
(e.g., paragraphs, lists and list items, etc.)
   
   6.2.5 [Priority 2]
          Allow the user to search for an element in the current document
based on its text content. In case of a match, the selection should be
moved to the element.

CMN: This section could be structured much better.

The checkpoints are, so far as I can see, as follows:

1. Allow the user to navigate the document's structural tree [p2]

2. Allow the user to generate and navigate a tree based on teh semantics
of a DTD [p3]

Technique: For an HTML document, construct a tree where headers are
considered children of preceding headers with greater priority, and
block-level elements are considered children of headers. Amaya does
something like this in its 'outline' view.

3. Allow the user to search for content. In case of a match, move the
selection to the content [p2]

4. Allow the user to search for an element, by specifying text content or
the content of descriptive attributes (eg TITLE, ALT). In case of a match,
move te selection to the element [p3]
    
  6.3 Provide information about events
          
   It is important to alert users, in an output device-independent
fashion, when important events occur during a browsing session. To avoid
confusion that the effects of scripts may cause, users should be notified
when scripts are executed (or be able to disable scripts entirely). This
is also important for security reasons; users should be able to decide
whether to allow scripts to execute on their machines.
          
   6.3.1 [Priority 1]
          Allow the user to navigate among elements with associated event handlers.

CMN: Is this relevant to UAs which do not handle the events? I suspect
not. Should it apply to navigating the children of an element which
handles bubbled events? I suspect so. All Children? Harder to say.

   6.3.2 [Priority 2]
          Alert the user when scripts or applets are executed.
          
   6.3.3 [Priority 3]
          Provide information about document changes resulting from the
execution of a script.

CMN: I suggest that 6.3.2 and 6.3.3 be rewritten as follows:

1. Provide notification of content and structure changes to the Document
Object Model. [p1]

2. Provide notification of style changes to the Document Object Model.
[p2]

3. Provide information about content and structure changes to the Document
Object Model. [p2]

4. Provide information about style changes to the Document Object Model.
[p3]

Charles McCN
--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://purl.oclc.org/net/charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
Received on Tuesday, 23 February 1999 19:11:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:54 GMT