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

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

Regrets:
 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

No: CMN, TL, EH, DB
Yes: KB, JG, IJ

B. Discussion

    1.Issue 289: Multimedia definitions.
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0517.html
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0520.html
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0503.html

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

   IJ: Related issues:
    - Turn on/off
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#290
    - Audio as style
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#297
    - Definitions themselves (e.g., degenerate multimedia
      presentations).

   EH: Def of multimedia: at least one audio track and visual track
   that are complements; in order to get the full meaning of the
presentation
   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
layers,
   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
   track").

   Resolved:
   - Try to remove normative references to "multimedia"  in the
guidelines.
   - 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]

     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html

   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.
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0084.html

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

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

   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
language.

   JG: We do require access to all content.

   Resolved:
    - Accept Ian's proposed rewording of checkpoint with edits
      to be proposed by Kitch.
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0080.html

  3.Issue 257: Minimum requirement for Checkpoints 8.2 and 8.3: 
    Distinguishing link checkpoints
    http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html

    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
this
        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
    pseudo-elements).

    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).
      http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0035.htm
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0036.html

    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
to 
configure how the selection is highlighted (e.g., foreground and
background 
color).
      [Priority 1]
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0036.html

    7.Issue 257: Minimum requirement for checkpoint 4.14: Allow the user
to 
configure how the content focus is highlighted (e.g., foreground and
background
      color). [Priority 1]
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0035.html

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
what 
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
on 
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 
characteristics.

IJ: that is not the metaphor used today.

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

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
reference 
to other checkpoints.

CMN: I don't support "one other mechanism".  I support GR's "use full
range 
of presentation" The requirement in the other checkpoint is for the text
as 
a whole. No particular scope, it would set the font for the whole page.
It 
doesn't give you a way of distinguishing headers for example. 
Specifically 
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
important 
elements.

CMN:

JG: Can people live with something other than color and font family as
the 
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)

YES: CMN,

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
than 
by distinguishing with color, font family, font size whether a to
indicate 
that a link has been visited, involves a fee, selected text and the
element 
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
to 
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
basis 
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
solution.
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
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0034.html

Current wording
2.3 If content available in a viewport has equivalent alternatives,
provide 
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
have 
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
or 
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
checkpoint 
10.8
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0032.html

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
proposals)
           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
do 
that with one stroke.

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

JG: most require a modifier

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

Still open.

Completed Action Items

    3.IJ: Send counter proposal to identify unsupported language
      changes
     http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0080.html

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
for 
consideration by the group

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

    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