- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 26 Oct 2000 15:41:51 -0400
- To: w3c-wai-ua@w3.org
26 October 2000 UA Guidelines Teleconference
Present:
Harvey Bingham, Tim Lacy, Mickey Quenzer, Eric Hansen,
Jon Gunderson, David Poehlman, Jim Allan, Ian Jacobs,
Al Gilman
Regrets:
Kitch Barnicle, Gregory Rosmaita
Absent: Rich Schwerdtfeger, Charles McCathieNevile
Next meeting: 2 November
Agenda:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0142.html
Minutes of previous meeting 10 October:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0125.html
Announcements
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
meeting.
2. User Agent FTF meeting update and call for participation
IJ: Registered so far: IJ, JG, JA, GR, HB
Refer to meeting page:
http://www.w3.org/WAI/UA/2000/11/ua-meeting
Registration form:
http://cgi.w3.org/Register/selectUser.pl?_w3c_meetingName=WAIUANOV2000
Discussion
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:
http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Aug/0006.html
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
2.3
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0085.html
JG Summarizes:
- In many cases, two chunks of content are not equivalent
symmetrically.
- 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
one-way.
- 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:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0153.html
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
point?
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
http://www.w3.org/TR/2000/WD-UAAG10-20001023/
2.JG: Review checkpoint in Guideline 5 for implementation
information
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0149.html
3.JA: Review checkpoint in Guideline 7 for implementation
information
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0152.html
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
information
5.GR: Contacts for Dolphin for reviewing WCAG
6.GR: Review checkpoint in Guideline 10 for implementation
information
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
for
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