Minutes from 21 Sept. 2000 telecon

Summary of action items and resolutions
     - Resolved: terminology - agreed to guidelines and checkpoints. could
not agree on techniques but will use for draft being prepared for f-2-f in
October.
     - Resolved: techniques must be written to be verifiable.
     - Resolved: splitting guideline 3 - agreed to split. Disagreement on
whether animation checkpoint belongs with guideline 3 or 6. Will keep in
both places with appropriate cross-referencing for next draft.
     - Resolved: auditory description checkpoint - agreed to keep this in
guideline 1 even though user agent support will eventually obsolete the
requirement.
     - Resolved: "until user agents" issues - agreed to specify the
requirements in the guidelines and cover implementation issues in the
techniques.
     - Action: Lisa will take one of the checkpoints and see if a table
approach works better: left column is the checkpoint, with a column for
HTML, one for CSS, etc.

Participants:
Jason White
Loretta Guarino Reid
Cynthia Shelley
Charles McCathieNevile
Dick Brown
Kynn Bartlett
William Loughborough
Donovan Hipke
Katie Haritos-Shea
Andi Snow-Weaver
Marshall Jansen
Lisa Seeman

Regrets:
Wendy Chisholm
Gregg Vanderheiden

Agenda:
1. Terminology.
2. Reorganization of items currently appearing under Principle 3.
3. Auditory descriptions: How should interim measures such as these be
treated in the guidelines?
4. Qualifications attached to Principles 3 and 4: do they need further
clarification? Should any of them be dropped?

JW: Issues with the draft. Need to have a structurally complete draft, one
with all three layers, ready for the f-2-f meeting in Bristol. Gregg and I
will be there by telephone. Wendy will attend in person. First agenda item
today is terminology. We have a well-articulated position from Charles. May
not be able to close without Gregg and Wendy.
CMN: Strongly feel we shouldn't change them. People shouldn't have to learn
a new nomenclature.
CS: Agree but the third layer in the new version is different from 1.0. If
third layer remains non-normative, okay to call them techniques.
WL: Little question that we will still have checkpoints.
JW: Renaming third level to "Technology specific checkpoints" as Wendy
suggested will be confusing because we will have checkpoints on both the
second and third level.
CS: The bulk of the checking would be done against the third layer.
KB: What about checkpoints that are not technology specific, such as color?
CMN: For a given second level checkpoint, there are various ways of
implementing it. Some technologies have more than one way to do it. Some
have no way to do it.
KB: What about "Technology techniques"
CMN: Just "Techniques"
CS: Have to make a decision about whether they are normative or not.
WL: There will be lots and lots of techniques. All that matters is the
"what" (the checkpoint).
CS: Disagree. Testers will not test whether or not there is a text
alternative. They will test for alt text on img tags.
CMN: In well-designed languages, there is an appropriate way to address the
requirement. In poorly designed languages, there may be many things you
have to do to address the requirement. In a technology where you have to do
5 or 6 different things to achieve one requirement, testing will be very
difficult.
CS: I envision a technology-specific checkpoint: For example, to meet
guideline 1, do A, or B and C,  or ...
CMN: When we write techniques, we should describe what it achieves. The
complex stuff requires more description.
JW: We have agreement to use "guidelines" and "checkpoints". For the
purpose of the next draft, can we go with "techniques"?
WL: The current "techniques" are four documents, subservient to the core
document.
CS: A tester wants to use something that is normative, technical, and
specific.
WL: We are looking at this in the ER group.
CS: Those are tool requirements, we need something for a person (the
tester).
WL: The person will use a tool.
CS: Not necessarily. Testers will test with browsers. They may or may not
look at the HTML. For example, they should run browsers with images turned
off to ensure that text is there for all images.
WL: Are you saying that a checkpoint can't be checked?
CS: I would like the techniques to be normative and technical.
KB: Agree. One of the weaknesses of the current techniques document is that
it is very hard to know when you have actually satisfied the checkpoint. It
has no "authority". If you are using HTML, you need to know specifically
what you need to do to satisfy a checkpoint. One possibility is to include
the techniques in the core document but the term "techniques" may already
have the wrong meaning.
WL: What about "Techniques for satisfying checkpoints"?
KB: Yes, if they are actually written this way. If someone is working in
HTML, it is not acceptable for them to only look at the base document. They
must look at the techniques for technologies that are well understood.
CMN: I disagree. People who really understand HTML will be able to use the
checkpoints. It should only be necessary to read the techniques once.
JW: Have agreement on terminology for next draft: guidelines, checkpoints,
and techniques. Techniques must be written to be verifiable.
[some agreement, no disagreement expressed]
LS: ACTION ITEM: I will take one of the checkpoints and see if a table
approach works better: left column is the checkpoint, with a column for
HTML, one for CSS, etc.

JW: Second item on the agenda is discussion of the proposal on the mailing
list to split Guideline 3 into two guidelines: one for comprehension and
another for browsing. Reactions?
WL: I love what Lisa wrote.
LS: I liked it.
JW: But you worte it. :-) I thought it was very good but I wonder if the
checkpoint related to animation is more appropriate under guideline 6.
LS: Even when the user agents support disabling animation, people with ADD
may not think to turn it off.
LG: [....didn't get this comment from Loretta ...]
JW: In version 1.0, the "until user agents" provision was sprinkled
throughout the checklist. In 2.0, we want to eliminate this phrase but
there are some things that are so critical for accessibility we feel
strongly we need to include them. One way to address the problem without
sprinkling them throughout the document was to collect them together under
guideline 6.
LG: Will other requirements in the checkpoints also become obsolete due to
user agent support?
JW: Yes, but whatever we say, it is up to the author's discretion as to
when there is enough user agent support to justify not doing it anymore.
I'm interested in reactions on checkpoints which are obsolete in principle
(because user agent or other standards require it) but required in practice
(because user agents don't support the standards yet). Specifically, Lisa's
proposed checkpoint on animation and the one on auditory descriptions.
CS: Is there any way to determine when "until user agents" has been met?
CMN: There is some point where we have to require that people get new
browsers. In 1.0 the criteria was that when it was freely available on
Windows, Mac, and Unix, that mean it was "available." For example, is it
reasonable to require JavaScript support? No, because EmacSpeak, the only
screen reader solution on Unix platforms, does not support it. We have to
draw a baseline and be clear about it.
CS: But we haven't done that yet.
JW: There are various factors to be taken into account but we don't have
anything definite. It's up to the author's discretion.
CS: Can we open a work item on this?
CMN: It is an existing noted issue.
JW: The separate issue is where the requirements should be specified.
Should we address them in the techniques? Some technologies will have more
variability in implementation in user agents than others. For example, XML
and SVG are more consistently implemented than HTML.
CMN: If we have a clear and explicit set of baselines, it will be easier to
judge a new technique against it. For example, a technique that is not
implemented in the main browsers is not appropriate.
JW: I would like some concrete proposals regarding animation and auditory
descriptions.
LS: Back to guideline 3, there are two issues: do we like splitting the
guideline and the separate issue of whether or not these are usability
requirements or accessibility requirements? My personal preference would be
to include these checkpoints. This is the place people go to get guidance
for people with disabilities. A usability checklist doesn't cover these
issues. People expect to see all disabilities covered.
WL: Reminds me of the television commercial about the usability of VCRs
where the grandfather can't program it but the grandson can. Is being old a
disability? If so, usability is part of accessibility.
JW: People use usability, accessibility, and universal design
inconsistently. I think we have agreement that we can separate
comprehension and browsing into two guidelines. We have agreement that we
need the checkpoint on animation but we have to decide where it should go.
WL: Which checkpoint under number 3 is it?
AS: 3.11
WL: I don't see why it can't be both places because it's needed for
different reasons.
CMN: We should be able to take the checkpoints and order them
alphabetically. It doesn't matter which section they are in. It just helps
us. I think we should just stick it somewhere and note that it's relevant
to a couple of different guidelines.
CS: I have a preference to putting it with the "until user agent" things
but it is not a strong preference.
LS: I have a strong preference for keeping it where it is.
JW: If a user agent can handle it, it's no longer the author's
responsibility. It's the user's responsibility.
WL: I don't see how "until user agents" satisfies it.
AS: But the user can turn off the animation.
WL: But that doesn't solve the problem.
JW: I recommend we do as Charles suggests - split it between 3 and 6 and
cross reference them.
[general agreement]

JW: Now what about auditory descriptions? They are redundant in theory but
necessary in practice. User agents can't deal with intermixing synthetic
speech with the audio portion of a multimedia presentation.
CMN: Auditory descriptions are clearly part of guideline 1. If user agents
render this unnecessary that's great but the requirement is clear.
JW: Do we need to put a note in that this could be rendered obsolete?
CMN: I think this applies to a lot of the checkpoints. These are only
organizing principles so it doesn't matter that much.
WL: To some extent, there is no question that it belongs with the other
checkpoints on redundancy.
JW: User agents are going to supplement the checkpoints. Should we have the
"until user agents" clause everywhere?
CMN: I would like to get away from the "until user agent" clauses
altogether. Maybe the guidelines can only have a life of two or three
years.
KB: I have found that the "until user agents" phrase introduces a lot of
confusion. It makes it look like we haven't done our homework. It's too
easy to fall back on. It has been detrimental to people understanding and
using the guidelines. It may be better covered in the techniques which we
can change more easily as the support increases.
CMN: I hate having to explain what a user agent is.
LS: Maybe we could make the guidelines match what is supported now and
provide a link to a bulletin board for current information.
JW: For 1.0, we have a web page maintained by the W3C for all the "until
user agents" things. The problem is resources to maintain it. We need a
better solution.
CMN: I agree. Resources is one problem. But at one point in time, we
assumed there were only 2 browsers. Now the number of browsers is
increasing. I support Kynn's suggestion that we cover these in the
techniques.
JW: But some are so globally important that they need a place in the
guidelines.
CMN: We should state the requirement but the technology my eliminate the
need for it.
KB: Technology is not just what the spec says. The browser implementation
is part of it too. It's the difference between what "should" work versus
what "does" work.
LS: Isn't this covered by "transform gracefully"? In the example of
bidirectional languages, what "should" work does "not" work.
CMN: This is a special case. One way is right, just, and good but doesn't
work. The other way is wrong and immoral. The more common case is that it
doesn't break but it doesn't work either.
JW: Charles' suggestion is that we specify the requirements in the
guidelines and cover the "until user agents" implementation issues in the
techniques.
[agreement]
JW: Time is up. Next meeting. Wendy and I will work on the draft this
weekend. Next meeting Thursday, 28th September.

Andi
andisnow@us.ibm.com
IBM Accessibility Center - Special Needs Systems
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo

Received on Friday, 22 September 2000 12:13:46 UTC