WCAG Meeting Minutes, June 7, 2001

In attendance:
Jason White
Greg Vanderheiden
Loretta Guarino Reid
Matt May
Donovan Hipke
Jenee Anderson
William Loughborough

Action Items:
1.	Discuss the audio constraint, that it be expressable in words, with PF.
(JW)
2.	Fine-tune the wording for Checkpoint 2.4 proposal (MM)
3.	Look at all the place where guidelines need a "where reasonable" clause
and see if we can define  what is reasonable for each. (WA)


JW: There is a proposal on the mailing list to revise Checkpoint 2.4 by
requiring that all time limits be avoided. There has been discussion on the
mailing list. Greg had some problems with this proposal that he posted.
Because the User Agent Guidelines provide some requirements on User Agents
to permit control over timing, there is a difficult split of responsibility
between the user agent and the author.
GV: Open-ended time limits are a problem - without any timeout option an
order can be left open forever, since there is no way to tell when a user
has left. I don't believe we can have a ban on transactions timing out. The
suggestion that 15 minute timeout is an access problem is a problem. It is
not tied to how long it takes to understand the request. Consider the
example where the person just forgot. That person could come back and use it
later successfully. The design should not be a bar to understanding. But I
have no better wording to propose. Our original discussion for WCAG 1
proposed a three part test: if a response was needed, the user should be
able to extend the response time limit. If the interaction is about to
time-out and the person hasn't finish, you should post a notice and ask the
person to respond if they need more time. You need to give them sufficient
time to respond to this. But now we are getting very restrictive and we were
trying to be more general
JW: What is we added something like: "Timeouts greater than X minutes are
permissible". If we had some grounds for believe that X minutes is enough
that there wouldn't be accessibility barriers imposed, then we could add it.
WA: How about the words "within reason" to the current guideline.
JW: We'll get complaints from people who will want more precision.
WA: All our words require interpretation.
GV: The rise and run rule is an example. 12:1 doesn't make the ramp
accessible to everyone, but it was judged a reasonable accommodation. There
must be some number of minutes that would be a reasonable accommodation. If
you are reading a document and after so many minutes the document goes away,
that is a problem. The time needed depends on the document length. But a
transaction should be more manageable. The length of time should be plenty
to allow most everybody to confirm the transaction.
It is easy to write a book about what is helpful for people with
disabilities. It is hard to write a book of rules. This timing issue is
always seen as an important item, but it is really hard to write a general
rule for it. Is there anything we do agree on? We do agree we need a
provision on timing. Do we agree with the wording that requires there be no
time limits or that the user should always be able to exceed the time limit?
MM: Usually you can defeat time-outs by hitting Refresh in the browser.
Except there is a WebGrocer requirement that if you want your grocery
delivery by a certain time, it must be submitted by a certain time. This is
not a web issue.
JW: The guideline only applies to interaction with the web site, not with
what happens afterwards.
MM: But they interact. You can't really separate them.
JW: There is agreement that we shouldn't be prohibiting time-based
interactions outright. Whether there should be a general control to block
time-outs in all cases is an open question.
WA: We all said there should be something about controlling it, within
reason.
GV: If there are timing constraints on web interactions, the user should be
able to control them to the maximum extent that there isn't some good reason
that it has to end. It shouldn't be an arbitrary limit.
WA: Most of use have experienced the credits of a motion picture where a
list of 100 contributors is shown for 10 seconds, and "directed by" is shown
for half an hour. You won't be able to legislate no timed events on the web.
We need some way to control it.
JW: An idea - one legitimate reason for timeouts is a discontinuous network
connection between the two sides of the communication. There is a technical
term that means there is nothing continuous happening to say that the user
is still there or that the system is still paying attention to the user. One
legitimate use of timeouts is for servers to conclude that there is no
longer an active session and to conclude it. Time-out controls should be
provided up to the time that it is reasonable to conclude that the user
session is no longer active.
WA: How long does the chair pause waiting for objections to a motion?
GV: Whenever a user must respond within a timed interval, the user must be
able to defeat, adjust, or extend the timed limit to the maximum extent
reasonable for the application.
The loophole is how to define what is reasonable for the application. And
everyone will complain that this is vague, untestable, undefinable. We
should get some examples. But unless you know what the application is, it is
hard to say what the limit is. Perhaps add "The minimum response time should
be 10 seconds for a single keystroke."
WA: There is a second loophole - "for events that require interaction". We
are also dealing with timed events that don't require interaction.
GV: Like reading something? we could say "respond or perform"
GV: What is the minimum response time for a single keystroke?
JW: a single activation?
GV: I used keystroke on purpose. If the interaction is a mouse click, it may
take a lot of keystrokes to click on that spot on screen.
WA: But keystroke doesn't qualify. perhaps "user event"?
GV: A simple user event. A mouse gesture .. but we require everything to be
possible without a mouse.
GV: "A minimum of 10 seconds must be provided for a single user
response/event/interaction to extend the timed interval."
WA: Isn't this what 2.4 already says? if we add "within reason"?
JW: We must make it clear in the introduction that the guidelines are to be
applied with a view towards their purpose and with an assumption of
reasonableness. Version 1 of Guidelines were being interpreted literally,
without an eye toward reasonableness. We had to go through and issue errata
to deal with such a strict reading.
WA: e.g. 3.6 says define key terms. Are all terms key terms?
"specialized language"? for some peole all language is specialized.
JW: The checkpoint techniques will provide the definition of what is within
reason.
MM: We need to talk to O'Reilly about writing the web accessibility
O'Reilly book. The techniques are going to be in a relatively
disjointed flow. We need to present things in a way that shows
techniques interacting with one another. When you are writing a
standard on how to do things, there is an accompanying book that says
what it means
JW We seem to have three options for what to do:
1.	Add Greg's explanatory language after the 1st sentence.
2.	Take Freg's proposal as a substitute for 2.4,
3.	Leave 2.4 as is

WA: I think 3 is a good option with a tacit "within reason".
GV: We need to add the tacit "within reason" explicitly to all the
guidelines where it applies, because if a guideline says "you must", people
get held to a hard requirement, and they start doing strange things to
satisfy it.
WA: is there someplace we don't need to add it?
GV: Maybe we need to add it to the top of the whole thing. How would we add
a textual description to Beethoven's Fifth? This is a problem that has
always been lurking in the guidelines. With cognitive, it pops up as a
Beethoven's Fifth on everyone's web page. There aren't absolutes. The
problem with adding "where reasonable" is that we don't trust who is going
to decide what is reasonable. We are afraid people will decide it is never
reasonable. What I would like us to do is see if we can identify things like
the work done in Section 508 where it says there should be keyboard access
to everything that can be described with words or where the result can be
described with words.
Whoever wrote that should get an access award for that phrasing. It did
something we haven't been able to do: set a bright line in an area that was
ambiguous. Can we make a bright line like that in the timing area? Keyboard
means typing, so if you can't express it in words, you won't be able to type
it. Is there something similar for the audio issue? Do we also say that all
audio that can be expressed in words should be accompanied by text.
WA: If you discuss this with folks in the PF group, see if they are dealing
with this specifically. (Jason)
GV: What if we said no timed response for a single user event should be less
than 10 seconds. We'll end up with a bunch of guidelines if we follow this
path. Users should be given reasonable control over the time allowed for
them to read, perform or respond. No user response should be required in
less than 10 seconds without the user's ability to adjust it up to 10
seconds. The user should be provided with the ability to extend time
indefnitely unless there is a hard external justification. (Very rough, just
for discussion.)
JW: The best way to proceed would be for someone to take an action item to
fine tune the wording. (Matt)
GV: I recommend that we think about it and bring it up again next time for a
brief discussion.
GV: I'm asking William to go through the guidelines and look for all the
other places that need "reasonable" and see if you can find a way to draw a
bright line.
WA: I think it will be at the top level.
GV: But that won't be a bright line, where you can substitute something that
doesn't contain the word "reasonable". The same phrase might apply to
graphics, e.g., Guernica can't be expressed in words. But maybe requiring
that only things that can be expressed in words be described in words is
redundant.
WA: Is there something wrong with redundance?
GV: Just adding "reasonable" to the end throws the whole thing into chaos,
but it shouldn't have to. 10 seocnds throws down a bright line. This does
mean that the minimum time for a redirect would be 10 seconds, if there is
any information there.
JW: The UA guidelines require it should be possible to stop these things
from occurring from the user agent. A certain class of these problems is
handled that way.
JW: We need agenda items for the face-to-face meeting. There has been little
response on the web.
GV: Unless we get the right people together, it is probably better to tackle
something that we dont really have ideas about yet. We could begin the
process of walking through whether everything is really doable? testable?
Can the guildelines be better worded? Look for problems where a diversity of
ideas is needed.
JW: What qualifications are needed? clarify, clean up the draft. Some time
needed on techniques as well. I'm not sure how time will be divided.
Authoring Tool group will be joining the meeting to discuss issues with HTML
requirements.
MM: I will be there for that.
JW: There is aproposal to add a checkpoint requiring ID of natural langauge.
Is this part of the semantics checkpoint, or does it need a separate
guideline? In WCAG 1, we added guidelines driven by HTML capabilities. In
2.0, we are moving these into checkpoint solutions for technologies.
Language identification is a general requirement that covers text as a
whole. But it is also a specific example of a more general requirement.
MM: The problem is that HTML has this capability but other technologies
might not. Putting it under another checkpoint deals with this. How is this
specifically an access problem?
JW: It is an access problem for braille and speech in particular. Applying
braille translation rule or text-to-speech rules, you need to set the rules
to the right language. For a document that contains more than one language,
you need to switch between the appropriate rules. In braille this can really
be an issue. Proper pronunciation greatly affects comprehension.
This issue  would map to Checkpoint 1.4 (the one about strcture)
GV: But language is not structure.
JW: I think the checkpoint was intended to cover semantics that aren't just
structure.
WA: In a quick glance, I can't find anything about language.
JW: it would be moved into the technology-specific part.
JW: There is a proposal to add the checkpoint.
WA: Where should it go?
GV: The language ID should be there. If there is nothing in the technology
to address that, then there is no technology specific solution. Maybe that
technology deficiency should be noted in that technology document.
JW: Or we could make sure the related checkpoint about structure has
sufficient scope to cover this.
GV: i don't like adding guidelines, but I'm not sure that is appropriate.
Structure should be higher priority than lang. Lang is useful, but not
priority 1 or even priority 2.
JW: i've run into it, and I'd put it at priority 1 or 2. Priority 1 for
identifying languages in a multilingual setting.
GV: Even if you do this, you still can't access it if you don't know the
languages.
JW: But if you can read both languages, you can access it
WA: In google they suggest reading a translation of the document
GV: Suppose you encounter a section in another language. Can't you look at
it in uncontracted braille, analyze the language, then set it yourself.
JW: You'd have to mark up all the transitions manually, then retranslate
into braille.
GV: This sounds like a priority 2; you can access it, but it is very
difficult.
(slight sidetrack into general priority discussions)
JW: There are two position: create a separate chekpoint or put it under
structure.
GV: Under semantics, but not structure
JW: Perhaps we need to add a semantics guideline to capture markup that
isn't structure.

Received on Friday, 8 June 2001 12:31:41 UTC