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

Raw minutes from 20 July 2000 UA Guidelines.

From: Ian Jacobs <ij@w3.org>
Date: Fri, 21 Jul 2000 17:25:12 -0400
Message-ID: <3978BFB8.C837FE9B@w3.org>
To: w3c-wai-ua@w3.org
20 July 2000 UA Guidelines Teleconference

 Jon Gunderson (Chair)
 Ian Jacobs (Scribe)
 Charles McCathieNevile
 Harvey Bingham
 Mickey Quenzer
 Tim Lacy
 Kitch Barnicle
 Eric Hansen
 David Poehlman
 Dick Brown
 Gregory Rosmaita

 Mark Novak
 Jim Allan

Next meeting: 27 July.
  Regrets for August: Jim Allan

Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0074.html

A. Announcements

Additional Telecon scheduled for Monday, 24 July at 2:00 EST USA for
90 minutes

Yes: KB, JG, IJ

B. Discussion

    1.Issue 289: Multimedia definitions.

   IJ: Mostly about definitions. Also may cause changes to some 

   IJ: Related issues:
    - Turn on/off
    - Audio as style
    - Definitions themselves (e.g., degenerate multimedia

   EH: Def of multimedia: at least one audio track and visual track
   that are complements; in order to get the full meaning of the
   you need both tracks.
   EH: In order to know whether content is accessible, the only thing
   that counts is in the end is what is presented to the user. In an
   ideal world, we could categorize presentations by their purpose
   and associations. We wouldn't care whether the component used to
   produce the presentation was a WAV or AVI file. Or text animated by
   a style sheet or for that matter it was a caption screen. But today
   we don't have the language support for dividing all those
   presentations into neat little packages as they appear to the user.
   So we drop back a layer and we end up being concerned with the
   components used to generate the presentation. When can we talk
   about the product independently of the mechanisms used to produce
   it, and when do we have to talk about the means used to produce it.
   In the Guidelines, because we don't have perfect support for
   capturing the end product presentations, we retreat to earlier
   which is why we run into problems with "multimedia". I have in mind 
   that this means something more than what can be presented by a
   movie file. We've agreed that in some cases, animations can be
   considered to have a visual track. But when one has a static page
   (or even a moving text page) that's automatically or manually
   scrolling with background audio, some of us balk at calling that a
   visual track.
   IJ: Can we eliminate normative references to "multimedia" in the
   document? (Refer to checkpoint 4.5; perhaps say "audio and visual

   - Try to remove normative references to "multimedia"  in the
   - Add a definition of "presentation".

   EH: In some places, we don't distinguish style and content, in
   others we do. We need to elaborate our definition of content.

   Action IJ and EH: Work on multimedia-related definitions and
   presentations and send to the list.

    2.Issue 257: Minimum requirement for Checkpoints 2.7: For 
      author-identified but unsupported natural languages, allow the 
      user to configure the user agent to
      identify those language changes in content. [Priority 3]


   EH: In some cases where you have a plain text text equivalent and
   you're supposed to mark up changes in languages.

   CMN: I made some comments on the list about my understanding.

   KB: You may have a problem with stating "this content may not
   disorient the user". We want to say that it could disorient the

   IJ: I agree that it could be rewritten so that the rationale is

   GR: Should the UA identify the unsupported language?

   CMN: I think that language information is useful information.   

   /* Discussion of having visual rendering being tuned to
      meet needs of some assistive technologies */

   IJ: I don't think that rendering language name in content is the
   best solution for giving access to content in an unsupported

   JG: We do require access to all content.

    - Accept Ian's proposed rewording of checkpoint with edits
      to be proposed by Kitch.

  3.Issue 257: Minimum requirement for Checkpoints 8.2 and 8.3: 
    Distinguishing link checkpoints

    IJ: The model I'd like to use for these and similar checkpoints:
     a) If color is used as a mechanism, at least one 
        mechanism in addition to color that is distinguishable from
        other types of information.
     b) Whatever mechanism is used, refer to pertinent checkpoints in
        document (color, fonts) for rendering requirement. 
        (We're talking about rendering.)
     c) Info has to be available programmatically as well.
    EH: Should a text-based option be required? Does this information
    require a text equivalent?
    JG: This could be an option for user agents (using

    JG: How do I know as a user agent that the author has specified
    boxes around links? 
    CMN: The UA does the rendering, so it knows.

    Resolved: Adopt three-pronged proposal.

    4.13: Allow the user to configure how the selection is 
          highlighted (e.g., foreground and background color).
    4.14: Allow the user to configure how the content focus is 
          highlighted (e.g., foreground and background color).

    JG: Boxes are easier to find for people with low vision.

    Resolved: Adopt same three-pronged proposal. However, focus and
    selection must be rendered as distinct.

/* Kitch starts minuting here, Ian goes to the airport */

    6.Issue 257: Minimum requirement for checkpoint 4.13: Allow the user
configure how the selection is highlighted (e.g., foreground and
      [Priority 1]

    7.Issue 257: Minimum requirement for checkpoint 4.14: Allow the user
configure how the content focus is highlighted (e.g., foreground and
      color). [Priority 1]

JG: Is everyone okay with one style?

EH: What if the whole block of text is underlined and you are relying on 
underlined text to show visited links.

JG: Rather see minimum color plus something else. Basically color is
is used now. I don't think color is used for focus changes.

Who thinks we should require color in addition to something else? With 
Ian's proposal a user agent could just use a box.

Yes: DP, GR, CMN
No: Kitch

GR: Min should include font families and something else.
TL: Shouldn't restrict it to one channel of information. ie, don't rely
any ONE means of conveying information. Should be allowed to configure .

IJ: I could live with color plus something else.

JG: What about font plus something else.

IJ: I believe we should in general go with current implementation.

GR: Color plus something is insufficient. If i'm using high
magnification i 
might not see box and text at the same time.  Offer user a range of font 

IJ: that is not the metaphor used today.

GR: with netscape 6 I can choose a font family for serif and sans

CMN: are you suggesting that instead of using color, select out of the 
range of presentation options, fonts, boxes etc.

IJ: I oppose this as being going overboard. It is a good idea but

GR: why should user have less configurability over active elements vs 
surrounding content.

IJ: I would agree to color plus something and include a note with
to other checkpoints.

CMN: I don't support "one other mechanism".  I support GR's "use full
of presentation" The requirement in the other checkpoint is for the text
a whole. No particular scope, it would set the font for the whole page.
doesn't give you a way of distinguishing headers for example. 
we are saying  provide a mechanism for things to stand out.

IJ: I would suggest the same set of elements suggested by another 
checkpoint - those marked important. Here is a specified set of


JG: Can people live with something other than color and font family as
min. req for those checkpoints and if we develop a list of important 
elements that these psuedo elements be included in that.

(visited links, thinks that involve a fee)


DB: so you are saying that you'll have to control the font of links, 
differently from the rest of the text.

JG: could be done through style sheets. This is a priority 2 checkpoint.

TL: When you get down to controlling all aspects of an object (color, 
font,...etc). I'm okay with it, in light of the style sheet comments.

JG: Proposal:

For 8.2 and 8.3  indicate to the user by at least one technique other
by distinguishing with color, font family, font size whether a to
that a link has been visited, involves a fee, selected text and the
with focus.

EH: Is there a priority 1 requirement that requires access to this 
information  auditorily, visually and in braille.

JG: yes through API.

IJ: proposal was to expand list of min techniques. was there a proposal
adjust 4.2... to adjust font family. Is there a proposal to control 
important elements independently of the rest of the text.

IJ: summary
1. expand font family size and color requirement to be on an element
not just a global setting
2. for check 8.2, 8.3 4.13. 4.14  cross reference those font and color 
checkpoint and indicate a) you are required and b) that would be a
3. for the case of HTML should we list what we consider to be important 
elements...we need to do that for 7.6. For the ones we know we can say 
these are the important elements.

Resolved: @@No resolution indicated@@

    4.Issue 257: Clearer definition of the term "Easy access" in
checkpoint 2.3

Current wording
2.3 If content available in a viewport has equivalent alternatives,
easy access in context to the alternatives. [Priority 1]

IJ: I would rephrase to say provide direct access e.g. through a link or 
context menu. That is, it is either there or one more away. It doesn't
to be a link to another page. Basically, providing one step access to 
alternative equipment. It basically means direct access.

IJ: editorially, it has to be written careful that you have to do A or B
C . You have to do 1 of 3.

No objections to modification of Jon's proposal for modification 2.3

RESOLVED.- accept new proposal with modifications

    5.Issue 257: Clearer definition of the term "Easy access" in

New proposal. one step activation for frequently used

DP: one step defined

IJ: We do need to define one step, basically direct access.

JG: list for 10.5 could also be our list of frequently used commands

   27.Issue 257: Other minimal requirements part of issue PR#257 (No
           Checkpoint 10.4: Input configuration
           Checkpoint 9.3: Configuration of notification.

JG: allow one, two, or three step operations to be accomplished with one 
step ??(changing the font size in IE.)

GR: want to bind the font size increment to keystroke

IJ: what if i want to change my language to French. Should I be able to
that with one stroke.

IJ: what are the types of multikey sequences that we have? do they
a modifier?

JG: most require a modifier

NOTE: one command does not include a modifier but one step can require a 

Still open.

Completed Action Items

    3.IJ: Send counter proposal to identify unsupported language

Open Action Items

    1.IJ: Draft a preliminary executive summary/mini-FAQ for developers. 
(No deadline.)

    2.IJ: Add to note on checkpoint 8.1 the important cases that this 
checkpoint must provide information through the user interface

    4.IJ: Update document with resolutions from 7/13/00 telecon

    5.EH: Send comments on definitions of "primary content" to the list
consideration by the group

    6.GR: Re-examine the orientation checkpoints and see whether they
be clarified to account for control of rendering of audio (and possibly 
other content) on

    7.HB: Review note for checkpoint 8.1

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Friday, 21 July 2000 17:25:20 GMT

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