W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 1999

Minutes from 30 June UAGL teleconference

From: Ian Jacobs <ij@w3.org>
Date: Wed, 30 Jun 1999 13:39:05 -0400
Message-ID: <377A5639.4C3B77DC@w3.org>
To: w3c-wai-ua@w3.org
Minutes 30 June UAGL Teleconference

 Ian Jacobs (Chair/Scribe)
 Charles McCathieNevile  
 Harvey Bingham
 Marja Koivunen
 Glen Gordon
 Gregory Rosmaita
 Jim Allan

Regrets:

 Rich Schwertdfeger
 Jon Gunderson
 Mark Novak

 1) Action CMN: Send URI on default keyboard bindings to list. Ian
                  will then include in Techniques document.

   Status: Done.
     http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0263.html

   Charles has an update on this (and will send to the list).

   CMN: In "modern" systems (e.g., Gnome, etc.), you can build your
        own bindings at will. The "default" configuration
        is less apparent. The problem is more complex than just
        advising people not to overwrite certain bindings.

   HB: IE has about 30-40 bindings. There's some redundancy in
       bindings. 
 

 2) Action CMN: Send request to blinux users for info about
                orientation.
 
   Status: Not done.

 3) Action IJ: Send similar request to IG.

   Status: Not done.

 4) Action GG: Send ideas on dependent tool point of regard to list.

   Status: Dropped on GG's request.

 5) Action Editors:
      - Add checkpoint about turning on/off author-supplied
        keyboard bindings.

   Status: Done in internal source files.

Agenda 
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0259.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0262.html

1) CMN proposes allowing the user to configure the arrangement of
   user interface controls (visually) as a P3.
   (http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0241.html)

   CMN: Tabbing order as much as visual layout. Grouping of controls
        and how you get to them. You can do in MS Word and it's very
        handy.
   
   IJ: Why do you need to control tabbing order if you have direct
       access through keyboard commands?

   GG: Novices don't have to memorize keyboard bindings.

   GR: One problem with adaptive tech is that unless you have
       a toolbar turned on, it won't echo certain formatting
       changes. Don't want to have to rely on display of controls
       for access to their functionality.
   
   CMN: I'm interested in grouping controls. E.g., with low vision,
        want few controls with lots of separation.

   IJ: Default is to follow system conventions. But users can
       override.

   MK: Are we talking about moving around only or being able
       to add and delete controls?

   CMN: Yes, variety in implementations.

   No objections and some support for Priority 3 Checkpoint.
   Resolved: Add this checkpoint.
   Action: Editors to add to next draft.

2) Checkpoints for guideline 3, about documentation, should be P1.
   having to guess these things makes it effectively impossible.
   (http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0241.html)

  CMN: If you have to guess, your lost. Hidden and secret is not
       acceptable.

  IJ: But "3.2" is about grouping.

  CMN: All features of the product must be documented.

  IJ: What's the accessibility about documenting all functionalities?

  IJ: Are you suggesting "User agent functionalities
      described by checkpoints in these guidelines must be documented." 

  CMN: Yes. Priority 1.

  Resolved: No objections to adding this checkpoint.

  HB: I'd also like a starting point from the software (readily
available)
      that lets me find keyboard bindings.

  CMN: For 3.3 - communication of the information is as important
       as being able to do it.

  Resolved: No objections to changing 3.3 and 3.4 to Priority 1.

  GR: Technique for 3.4 - put default keyboard config in README file
      at a minimum.

  Action editors: Add these checkpoints, make these changes.

3) Proposal on changes to navigation checkpoints
(http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-table.html#66)

  IJ: What does it mean to navigate the document tree?

  CMN: Prefer to use the term "structure" instead to allow
      ambiguity: real (parsed) source tree or a remap of the DTD
      (e.g., headings are nested in HTML). More about navigating
      what the structure "should be". 

  CMN: I want a technique that lets people "pass over" information,
       but better than just by scanning the entire
       document. Sequential gives you context.

  MK: It might be that people generally navigate what's rendered
      (could be default). Informed users might want to navigate
      the tags or through CSS things.

  GG: You do need to be able to move backwards and forwards.
      
  IJ: What's the step size?

  GG: Have a point of regard that you can navigate by line, word,
      sentence, paragraph.

  CMN: Move the point of regard, whatever the size of the zone.
       And allow configurability.

  GG: We are moving from looking only at rendered text to looking
      at the document source. This is much richer than just
      manipulating rendered info.

  CMN: For sequential navigation - fundamental navigation is being
       able to read through document in point-of-regard size chunks.
       (e.g., line-by-line in braille display).

  IJ: I do page down in NN. How do dependent UAs work?

  GG: Similar behavior for rendering to speech. 

  GG: Proposes - allow sequential navigation suitable to device being
      used. 

  IJ: The viewport in short.

  CMN: Three ways to navigate the document - 
      a) Continuous feed (optionally being able to start/stop).
         This one is fundamental. 
         IJ: We have a checkpoint for this: access to all content.

      b) Divide the document into structural components (without
          specifying how that structure is built exactly - not
          necessarily the DTD).
     
         CMN: Jon has argued that this is really important and I
              agree. Tree navigation is one technique.

         GG: A lot of structure is unimportant to many users: DIV and 
             OBJECT elements. Navigating the tree is less useful 
             than navigating some commonly used terms - paragraphs,
             headers, etc.

         CMN: Yes, strict tree navigation is clunky, but minimally
              satisfies the need. 

         IJ (summarizing): 
               - Allow navigation of document structure.

               - Techniques explain how:
                  a) DOM is minimal (tree nav)
                  b) Mix of rendered/source
                  c) Use commonly understood document models
                     (based on DTD, but may not match exactly).
                  d) Simplify view of structure for user.
                  e) Allow the user to control level of detail/
                     view of structure.

         Resolved: Add a checkpoint about (Pri 4) navigating the
                   document in a structured manner. For all
                   user agents. Delete 7.8 (doc tree navigation).
                   Add a (Pri 3) checkpoint to allow configuration of
                   the structured navigation mechanism.

      c) direct access to an identified point.
         IJ: We have a checkpoint for this: search text.

4) Notification of document changes due to scripting events
(http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-table.html#54)
(http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0197.html)

   CMN: First requirement is that all changes must be available
        to AT and user. Probably too much information, so better
        implementations will do better.

   Jim: Depends on what the purpose of the change is. On my site
        for low-vision users, when you move around, the font
        size increases. This would annoy screen-reader users.
        Information that people want available can vary greatly.

   CMN: Given that you can't tell a priori, you must make it
        available. I think Pri 1 for desktop to AT and AT to user   
        as well.

   MK: Need some useful default filtering so that user is not
       overwhelmed.

   Jim (to GG): Can you set up Jaws so that users are informed
         of font changes?

   GG: We're moving towards being able to do this (and make notification
       optional).
   
   NOTE: There's a mix of user needs and author's intentions in using
         style that means you can't predict a priori which style info
         to communicate. 

   GR: E.g., drop down menus with links in them (e.g., MS site).

   CMN: User agent can tell you that the document (tree) has changed.

   GR: MS calls this "active scripting".  Happens at a lot of
       commercial sites.

   Resolved: Generalize 9.2 (drop part about scripts) to talk about
             changes to the document. Not just user-caused. For
             all user agents. Priority 1.

   CMN: Configuration is a higher priority checkpoint in this case
        (at least P2).

   GR: Priority 1 (my own selfish reasons).

   GG: IE 4/5 communicates this info through o.s. conventions today.
Received on Wednesday, 30 June 1999 13:37:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:48:57 GMT