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

Raw minutes from 19 April UA teleconference.

From: Ian Jacobs <ij@w3.org>
Date: Wed, 19 Apr 2000 15:44:52 -0400
Message-ID: <38FE0CB4.389FB673@w3.org>
To: w3c-wai-ua@w3.org
WAI UA Teleconf
19 Apr 2000

 Jon Gunderson (Chair)
 Ian Jacobs (Scribe)
 Denis Anson
 Hans Riesebos
 Mark Novak
 Harvey Bingham
 Madeleine Rothberg
 Al Gilman
 Gregory Rosmaita


 Kitch Barnicle
 Rich Schwerdtfeger	


 David Poehlman
 Jim Allan
 Mickey Quenzer 
 Charles McCathieNevile

Next teleconference: 20 April

Agenda [1]
[1] http://www.w3.org/WAI/UA/2000/04/wai-ua-telecon-20000419.html

Open Action Items

1a) Completed

    2.IJ: Propose three terms to the list: 
          Document Source, Document Object and Rendered Content 
    3.IJ: The content/ui division in G1 needs to be fixed 
          IJ: Done locally.
    4.IJ: Resolutions from FTF meeting 
          IJ: All done, I believe.
    5.IJ: Adopt new wording of proposal for checkpoint 9.2 
          IJ: Done locally.
    7.CMN: Find out from I18N how to generalize the accessibility 
           provided by sans-serif fonts. 
   13.DP: Review techniques for Guidelines 1 and 2 
   19.JG: Identify the minimal requirement for each checkpoint. 
   20.HB: Take scoping issue of the current guidelines to the EO
          Working Group 
          HB: EO confirms that they are doing the FAQ.
   18.JG: Take conformance grandularity issue to the WAI CG. 
          JG: Sent as an agenda item.

1b) Continued

    1.IJ: Draft a preliminary executive summary/mini-FAQ for 
          developers. (No deadline.) 
    6.IJ: Propose split to the list. Identify why and issue of priority. 
    8.CMN: Propose a technique that explains how serialization 
           plus navigation would suffice for Checkpoint 8.1. 
    9.DA: Send name of new organization to list that was mentioned by 
          some person from the US Census Bureau 
   10.DA: Review techniques for Guidelines 7 and 8 
   11.DB: Get Tim Lacy to review G+ 
   12.DB: Review techniques for Guidelines 3, 4, and 11 
   14.GR: Look into which checkpoints would benefit from 
          audio examples in the techniques document. 
   15.GR: Review techniques for Sections 3.7 and 3.8 
   16.GR: Send to list screen shot of JFW Window list. 
   17.JG: Write email to the list asking for information about which 
          user groups require the ability to slow down
          presentations othewise access it impossible. 
   21.MQ: Review techniques for Guidelines 9 and 10 
   22.RS: Take notification of focus and view changes to PF as
          possible DOM 3 requirement. 
2) Announcements
   1. April 27th, WCAG Telecon will be discussing 
      markup to provide navigation information to user agents 

   2. Notice of Proposed Rulemaking: Electronic and Information 
      Technology Accessibility Standardsby the United
     Comments will be accepted until May 30th

3) PR#224: Checkpoint 4.16: Minimal conformance requirement unclear

   JG: The only thing not covered is inheritance by viewports.

   IJ: Does the presence of several viewports cause an accessibility
   DA: Some users with CD can only process a certain amount of visual
       information. One user could play card games, e.g., as long as
       there were no more than four cards in his hand. If you have too
       many viewports, you may exceed the threshhold above which 
       processing becomes impossible.

   IJ: For me, the requirement becomes the ability to close, not the
       ability to prevent opening.

   DA: If you have to close with looking, then it's still a problem.

   GR: I don't want to have to do this by hand: I want to 
       configure the UA. Also, I want to ensure that configurations
       are inherited and that focus is constant when a viewport is

   JG: Sounds like minimal requirement is allowing the user to 
       turn off any viewport that opens automatically.

   IJ: Propose issues of opening in 4.15 and issues of number in 4.16.
       "Not opening" is a technique for controlling the number.
   DA: You might also want a technique to limit the number.

   IJ: Would being prompted cause you confusion? So is the technique
       we're suggestion appropriate for the users whose needs we're 
       trying to address.

   DA: Prompting might confuse, yes.

   AG, JG: The proposed remedy would meet 4.16 as stated today.
   DA: One technique: ignore "target=_new".

   DA: Too much information is also a disorientation problem.
       But the cause of disorientation is different.

   IJ: 4.16: Allow the user to configure the number of viewports      
       open at one time.

   DA: Techniques will be similar.

   AG: I have a residual unhappiness - you're creating more
       requirements. I realize that the problems aren't
       the same, but if the minimal requirements are the same,
       why not merge the checkpoints.

   IJ: Minimal requirement for 4.15 is to prevent the focus
       from moving (and let the user change it by hand, by
       navigating to another viewport). 
       For 4.16, it's don't open new windows and don't ask.

   AG: "Just say no" is not sufficient. You also need prompting
       and "just do it normally". So three pieces to minimal 

   AG: I think that number of viewports is an issue for blind
       users, even if it's a lower priority for them.

   Action IJ: Propose new 4.15 and 4.16 to list.

4) PR#244: Checkpoint 4.5: Change to P2 since no reference

   MR: Refer to my email:

   MR: Part of the difficulty is to avoid distorting pitch.

   JG: Variable-speed tape recorders have been doing this since the

   AG: Yes, there are techniques for doing this, although I don't
       think that this has been done commercially as long as that.

   JG: What's the range for slowing down? Half-speed?
   HB: George Kerscher argued that below 80%, the audio becomes
       almost unusual. 

   DA: Most of the technology I'm aware of is about speeding up.

   GR: Although many blind users speed up rendering, some users who
   are newly blind, or who have other disabilities, will need to slow
   down as well.

   GR: I don't think slowing down needs to be symmetric with speeding
   IJ: We can't pick numbers out of a hat. For any of these ranges,
       we need to do research.

   JG: Note that 4.5 does not talk about speeding up since you still
       have access to content. Slower than you wish, perhaps, but
       you still have access.

   HB: Then it's a P2 or P3 to speed up.

   JG: You may not have to do pitch adjustment at 80% speed.

   JG: What about for animations and video?

   HB: Will you get "beating" phenomena in the visual field?

   AG: I think it makes sense to split video and animation due
       to feasibility.

   JG: We're not talking about compressing. We're talking about
       extending the time a frame is visible.

   AG: You could do dithering.

   MR: I'm not aware of data on these needs.

   DA: I would guess that for video or animation, half-speed would

   MR: If there is audio that goes with the video, then those
       two need to be synchronized. The user needs to know that if
       they slow down the video more than 80%, that the audio
       may not be rendered.

   JG: It would be acceptable to cut out the sound below 80%.

   DA: Yes, a user could view the video without audio first ,
       then replay faster with audio to get more information.

    - For video / animated: slow to at least 50%
    - For audio: slow to at least 80%
    - When synchronized: down to 80%, must synchronized, after that,
      audio can drop out.

   HB: We don't need to specify a continuous range down to 50% or 80%.

   Consider resolved for now (unless information contradicts our best

   1) Leave 4.5 a P1. (We have a reference implementation).
   2) Specify minimal requirements for synchronization as stated above.

   Action DA: Get confirmation that these numbers make sense.
   Action MR: Send URI to MS's implementation to the list.

5) PR#262: Checkpoint 5.9: Change Priority since non-standard 
           approaches may be better.

  Resolved: Keep same priority. Use wording below:

   5.9 Follow operating system conventions that affect 
       accessibility. In particular, follow
       conventions for user interface design, 
       keyboard configuration, product installation, and
       documentation. [Priority 2] 
                    Note. Operating system conventions that 
                    affect accessibility are those described in
                    this document and in platform-specific 
                    accessibility guidelines. Some of these
                    conventions (e.g., sticky keys, mouse keys, 
                    show sounds, etc.) are discussed in the
                    Techniques document [UAAG10-TECHS].

6) PR#264: Checkpoint 3.9: Raise priority since may cause CD problems.

   IJ: I've sent email to reviewer, no reply. But it sounds, based on
       discussion today, that users with CD are affected.

   JG: I sent email too:

   DA: Yes, too much visual information can cause problems.

   GR: Isn't there also an issue about spatial relationships between
       images and text?

   DA: Yes, that's a possibility. With people barely able to
       take in the information, the switch between modalities
       (text/image) can be difficult. If you want to talk about
       learning theory, you're dealing with different types of
       information. Research shows that transitions between modalities
       can be a very difficult task. I would suggest that this
       be moved to a P2. 
   AG: Yes, flopping back and forth between modes. The lower challenge
       may be pure text or pure image. Images aren't bad, but
       complexity can be bad.

   IJ: A change in priority would be a substantial change to the
       document. This is not a mere clarification to the document.
       Therefore, this change (and others of this class), may
       cause us to cycle back.

   AG: I think that it's at the Director's discretion to be able
       to make the call. The Chair should get consensus and take
       "the call" to the Director.

   /* More discussion on the W3C process and how changes have
      an impact on moving to Recommendation */

   DA: I don't think we should sacrifice accessibility for 

   Resolved: Make 3.9 a P2 (due to impact on users with CD).

7) DOM 2 issue

   /* IJ presents issue of DOM WG dealing with namespace
      issues and it being uncertain when they will move to 
      Proposed Recommendation */

   IJ: Options
      - Wait for them.
      - Drop to DOM 1. We lose namespace support and CSS module.
   HR: What about open-ended requirement for DOM?

   JG: We closed it off to make the spec tighter.

   HB: I don't believe that any MS product conforms to DOM 1.

   JG: MS people believe that they do.

   IJ: Philippe has told me that IE's DOM is a superset of
       of W3C DOM Level 1, but has not confirmed that yet.

   IJ: NN 6 claims full support for the DOM.

   JG: How many people consider DOM 2 critical?

   GR: I am leaning towards that position. I think 5.4
       (CSS module) is important.

   IJ: Please be prepared to wait at least 3 extra months.

   GR: We might have to wait anyway if we recycle.

   IJ: We should change our strategy if we recycle so that
       we can drop to DOM 1 by default if DOM 2 not a PR
       after a certain point.

   HR: I think DOM Level 2 important as well. The CSS module
       is useful (as is the events module).

   DA: I think that going for accessibility would require going
       to DOM 2.

   MR: I'm not informed enough about the DOM.

   AG: I still believe that we should put in an explicit
       implementation time out: say that you have to comply
       within 6 months (for example) of the document becoming
       a Rec. This is the ugly proposal.

   HB: I would hate for our spec to have to wait 6 months. I'd
       rather put in words about DOM 1, and do what AG says.

   IJ: I think we should move to DOM 1. You would get more 
       accessibility sooner, then publish another UAAG later
       and not break conformance to UAAG 1.0.

   JG: So it sounds like:

     - The WG should resolve the other issues first and get
       a sense of the sum of changes.

     - If we choose to recycle, we could try for DOM2.
     - If we choose not to recycle, we might try DOM1 then
       produce a new REC with even more of DOM2 work later on.

   JG: Would anyone object to going ahead with DOM1 and creating
       a new UA Rec when DOM2 becomes a Recommendation?

   HR: I still prefer the solution of giving user agents a six-month
       lead time.

   IJ: I think that an open-ended dependency on a document that
       doesn't yet exist or at least might change in unexpected ways,
       is dangerous.

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Wednesday, 19 April 2000 15:45:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:26 UTC