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

Raw minutes from 26 October UA teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 26 Oct 2000 15:41:51 -0400
Message-ID: <39F888FE.B017C05E@w3.org>
To: w3c-wai-ua@w3.org
26 October 2000 UA Guidelines Teleconference

 Harvey Bingham, Tim Lacy, Mickey Quenzer, Eric Hansen,
 Jon Gunderson, David Poehlman, Jim Allan, Ian Jacobs, 
 Al Gilman

 Kitch Barnicle, Gregory Rosmaita

Absent: Rich Schwerdtfeger, Charles McCathieNevile

Next meeting: 2 November

Minutes of previous meeting 10 October:


    1. Congratulations on publication of the last call draft.

      - Reviewers should use the public review list, and
        Advisory Committee review should be earlier rather
        than later (at PR).

      - IJ doing a Project Review for the Team on 2 November.
        I will bring back to the WG any issues raised in that

    2. User Agent FTF meeting update and call for participation

      IJ: Registered so far: IJ, JG, JA, GR, HB
      Refer to meeting page: 
      Registration form:


 1.Last call update

   IJ: No comments so far from reviewers.
       We will need to ping reviewers in about a week.

   AG: We had a meeting with the SYMM WG yesterday. Aaron Cohen
       (Chair of the SYMM WG) promised to take back a message to
       implementers that they need to review the document. 
   EH: Process question related to the SMIL spec and our own:
       we had talked about having our list moderated to avoid spam.
       Is that list moderated? I've sent email to that list that
       didn't get through.

   IJ: Two points:
    - Master list should prevent most problems
    - I'll be the moderator
    - Systems team not done this for us yet.

   AG: Write listmaster@w3.org if you have a problem,
       and copy the WG Chair to alert them of the problem.

   EH: I did this and it still took a few days to get posted.

   Action EH: Forward information to IJ to follow up with
      with systems folks.

 2. Common glossary to WAI Guidelines.

    JG: Discussion in WAI CG about producing a glossary. 
    AG: There is value in what Harvey has initiated.
     HB's unified glossary:
    EH: I'm interested in working on a glossary.
    IJ: Me too.

3.Implementation report

IJ: Reminder that we may be able to skip CR if we can show
    implementation of each requirement.

Action IJ: Publish an updated implementation report
           with evident holes in it.

JG: New takers to submit implementation information/

Action JA: Submit implementation information for G4.

4. Support documents for on or around Recommendation:

IJ: One of several interesting documents for later:

 - Impact matrix
 - Assumptions leading to current scope.
 - Obstacles we've made it past.
 - Working Group's experience in getting to Rec.

4.Product evaluations

IJ: Two issues:
 - Documenting support for checkpoints.
 - Long term commitment to product evaluations. What are
   implications? What are techniques for evaluating software
   (refer to ATAG Techniques for evaluation).

4.On the Techniques document

AG: Wendy started a thread in PF about using the XML accessibility
guidelines to evaluate voice applications. There are requirements
that move from browser to server, and this affects this WG. The
legacy this WG leaves out of this cycle needs to be useful for
work that has to be done either in this WG or in the Voice WG.
(e.g., www.tellme.com, www.bevocal.com).

JG: I think that this is out of our current charter, and WAI
needs to examine where this belongs.

AG: Some of the lessons that this group has learned will
be important to helping WAI figure out which directions to take.

DP: Issues like loop-backs in menus, etc.
MQ: And being able to turn up the volume. At these sites,
    the Web site itself may or may not be acccessible. These browsers
    are integrating email (voice mail) and other services.

AG: WAI PF is currently the point WG on this topic. The discussion
reveals that our current documentation doesn't cover this. We need to
examine what the UA WG has been doing to get the whole picture.  For
example, consideration of discussion at Technical Plenary in February
with Voice WG is a good idea.

IJ: We will need to review and update Techniques Document before going
to Rec. Earlier review preferred. Please be prepared as we go to last
call to accept to review chunks of the document.

6.Issue #321: Equivalency relationships and the wording of checkpoint

JG Summarizes:
 - In many cases, two chunks of content are not equivalent 
 - Wording in the document: equivalency and equivalency target
   suggests that the target has priority, and the relationship
   of the alternatives is "downstream". AG has suggested that
   the checkpoint should not limit the requirement to the
   downstream requirement, but should be generalized to 
   consider a set of interchangeable alternatives.

EH: Before last call, there were proposed new wordings of
2.3 to treat the alternatives as "peers". The requirement
is to move from one peer to the other in any direction, and
have access to all peers. It's possible to have bidirectional
navigation without changing the definitions of "equivalency"
or "equivalency target". AG's other concern was about the
definition of the terms, but I think that's a separate issue.

JG: Need to consider definitions as used in other Guidelines.
We shouldn't give a different definition of a term if we
don't have to.

HB: I prefer "alternative" (as used in ATAG 1.0). These
alternatives are not reversable (information loss as you 
go downstream).

AG: The terms "equivalent" and "element" are basically
content description ideas. We use "element" to talk about
something that is content in the Web. "Equivalent" is used
to describe a relationship between pieces of content. In my
opinion, these are content concepts we're trying to define
terms for. We need to have the WCAG WG participate in these
discussions about concepts behind these two words. 

AG: JG used the phrase "true equivalents". This is indicative
of a consumer problem with the word "equivalent". I would say that
there are precise and rough equivalents. But the general relationship
is a peer relationship, not a one-way relationship. The language used
in ATAG conveys a peer relationship (you are "looking down" at a set
of peers). 

HB: ATAG says "essentially" the same function.

AG: It's rough equivalence, but the relationship is communicated
about the elements as peers.

EH: The only aspect of the peer relationship that has poles is
the area where you are defining the audience. You can't just
say "A is equivalent to B when presented to the user" unless
you say something about the user. An image has no value to someone
who is blind. Only when there is value can you talk about about
the equivalency relationship. You can say that "an image presented
to a user who is blind conveys essentially the same function as
this image does to someone who is not blind." 

AG: What is fundamental is that the function needs to be the same.
I think that whether the user has a disability is incidental to
the definition.

EH: But part of the definition involves presentation to the user.
The ability of a piece of content in a particular media type
to convey information does depend on the user's ability.

DP: I see a couple of things here:
 - Beware of bias that something "abnormal" must happen in order
   for some things to be accessible.
 - What the current process attempts to do is to level the 
   playing field. When we look at symmetrical relationships
   of equivalency, we are saying "these are the possible things
   that can be done." I think we will benefit from defining
   "rough" and "precise" relationships in this way. It's a more
   accurate reflection of what really occurs. And it will help
   in the definition of defining more accessible Web content.

EH: When I say, for example, that a text equivalent needs to
be available in three modes to respective disability audiences,
this does not mean limiting access to a person with a disability.
We are committed to making all content available to all users.
All we're doing in the definition of text element is defining
attributes of understandability. The definitions outline
a set of minimal standards for the accessibility of text elements;
they do not mean (or say) that access may be possible otherwise.
It would be useful for a user to be able to configure the UA
for a particular disability profile (e.g., as one result
to present a text equivalent at the top of a list of peers).

JG: I've heard a suggestion that this is a WCAG issue. If so,
what does this WG do with the current definitions? (And how
does this relate to the glossary issue?)

DP: To speak to the issue of what alternatives do what? 
Alternatives are used by many people for many reasons
(e.g., to cut costs), not only related to a disability.

AG: I think we should not close this issue without consulting
the WCAG WG. 

AG: I "groove" on what EH said about policy: that is what we want to
capture and make 2.3 communicate. I think the idea that's in the WCAG
1.0 (perhaps a little slippery): they are trying to tell the author
what the author has to do, given that the author doesn't know about
the characteristics of the user. The word "equivalent" is used to
capture the fact that some alternatives may not work, but when they
work, they deliver roughly the same message. That's why they are
substitutable. You create a set of alternatives when some of the
content types are "risky" for some users. The UA needs to allow the
user to pick the one that's best for them. I believe that in 
WCAG 1.0, where they are talking about using the word "equivalent",
they are talking about the fact that the information in the data
is delivering roughly the same function. The author has to look
at this as a random process (the author won't know which one will
work). They must provide alternatives, the UA's job is not
to pick and choose, but export that job to the user. Profiles
help the user make choices. UAAG 1.0 Checkpoint 2.3 is about
those choices.

IJ Summarizing:

 - UA needs to allow the user to choose from alternatives.
 - Equivalency relationship should be described in the more
   general framework of "rough equivalency". 
 - Checkpoint 2.3 should use the more general formulation, not
 - The term "equivalent" itself is ok to use in this context
   (even if it doesn't mean mathematical equivalence).

EH: Refer to my most recent proposal:

EH: Maybe we can use a different term that captures what AG is
    getting at: "peer for content". E.g., "A peer is content that,
    under some circumstances, can serve essentially the same function
    for some other content." An equivalent and its equivalency
    target are peers for each other.

IJ: What's the difference between "peer" and "equivalent" at this

EH: The definition of peer doesn't involve users. It says nothing
    about the disability status of users receiving the content. 

HB: What about "substitute" or "alternative"?

IJ: The discussion seems to have moved away from symmetry towards
user abilities in the definition.

JG: In our document, we clearly have a requirement in 2.3
to choose. 

AG: Is there risk that we might not get feedback by the 13th.

AG Proposed: 
 - IJ and EH seem to think that we could come up with a change
   to 2.3 that would make people happy. That would close
   this issue within this WG.

 - Ask the two chairs (of UAAG and WCAG) see if there is
   compability. If necessary, take to WCAG for a timely 
   reply (by the 13th).

Action IJ and EH: Propose new language for 2.3.

EH: What will the questions be? In 2.3, have alternatives be peers.
    AG: I would like the language used to include the peer case.
        I want to avoid implying that there's always an A/B polarity.
        I want to include the case where everyone would agree
        that the relationship is symmetrical.

Action JG: Take this proposal for discussion with WCAG Chair,
           possibly to take to WCAG for quick turnaround.

Completed Action Items

    1.IJ: Prepare last call document

    2.JG: Review checkpoint in Guideline 5 for implementation

    3.JA: Review checkpoint in Guideline 7 for implementation

   10.TL: Check with Microsoft Multimedia group to find a reviewer
    Yes. (Masahiko Kaneko)

   11.TL: Check to see if MS can send representative to FTF meeting
    Probably not. I should be able to teleconference in.

Open Action Items

    4.DP: Review checkpoint in Guideline 1 for implementation

    5.GR: Contacts for Dolphin for reviewing WCAG

    6.GR: Review checkpoint in Guideline 10 for implementation

    7.MQ: Review speech checkpoints for implementation information
    Suggestion: Two implementations.
    AG: Any life on GUISpeak (list server)?

    8.KB: Submit technique on providing information on current item and 
          number of items in search

    9.RS: Send information (if you can) about tagging for information
          improving performance

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 26 October 2000 15:41:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:29 UTC