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.
WL: How about the words "within reason" to the current guideline.
JW: We'll get complaints from people who will want more precision.
WL: 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.
WL: 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.
WL: 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.
WL: 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."
WL: 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" 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.
WL: 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. "A minimum of 10 seconds must be provided for a single user response/event/interaction to extend the timed interval."
WL: 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.
WL: 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 Gregg's proposal as a substitute for 2.4, 3.Leave 2.4 as is
WL: 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.
WL: 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.
WL: If you discuss this with folks in the PF group, see if they are dealing with this specifically. (directed to 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. 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.
WL: 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.
WL: 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 a proposal 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.
WL: In a quick glance, I can't find anything about language.
JW: it would be moved into the technology-specific part. There is a proposal to add the checkpoint.
WL: 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.
JW: 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.
Thursday, June 14th, 2001 @ the usual time. (20 hours UTC (+1-617-252-1038))
$Katie Haritos-Shea 06-10-2001$