WC Refer to Kynn's proposal, my response, CMN's response to the
JW Provide consistent interaction behaviors (including navigation mechanisms).
WC My response to KB was "provide more than one path or mechanism to find content" but does not get at consistency. Then search would be a technique underneath this.
JW Right, so have one that says, "Provide consistent interaction behaviors (including navigation mechanisms)" then a second one that says, "provide more than one path or mechanism to find content" or something like them.
DB Sounds good.
AP Agree, search should be mentioned under navigation.
/* GV joins */
Action WC: incorporate these into the draft to be released next week.
GV We do have situations where the author specifies a timeout.
WC Theoretically, UA could replace that with an interval the user defines.
JW Of coures UAs can solve, the checkpoint has grounds for situations where UA has not solved. "give users control" is a code word for "if you don't think UAs are going."
WC This is the "until user agents" coming back to haunt us. <grin/>
GV I want to see if we can avoid writing guidelines that really should be someplace else. If the problem is that most users will want it to redirect, don't tell authors not to, tell the UAs to provide mechanism. Forward be done by script if script not supported not forwarded. Could defeat auto-forward.
JW Various ways to implement. Easily avoided if using server-side techniques or scripting techniques. UAs should fix, but I'm not sure whether taking a requirement out since UAs should fix is reasonable.
KHS Did you read what Matt said about 2.4?
WC /* reads Matt's response */ Agrees. In ERT WG haven't figured out how to determine that javascript is accessible or not much less how to control parts of it. People define own functions.
JW But at least you can stop the action of it. What is not controlled by the DOM that could be changed?
WC What about Flash or applet? General issue is "until user agent"
JW Handled by checkpoint solutions.
GV Always be the until user agents bit. Think we need to tackle it in 3 ways. Define what people need to do to make pages accessible on a conceptual level. Then work with user agents to get them to get rid of quirks caused by past user agents. 3rd is to create special tools, proxies, that allow you to jet past temporary problems. Allows us to move it out. Otherwise get ourselves in trouble when the UAs do handle them. Also don't want to overly restrict things that people should be able to do.
KHS Don't think we can get rid of it. Important for authors to understand.
AP Agree. Since web developers will have control over, then give them our recommendation. If the browser takes care of that's great.
GV We haven't done enough to create browser helper tools. We being the WAI, or Trace or other universities. We ought to make a case to the government that we say "people can't access tables since browsers don't do x." This example problem has been solved by tools such as these. But there are many others that haven't.
JW Agree with those propositions.
GV We didn't in 1.0 want to make sure don't in 2.0.
WC In WAI have discussed general principles then divvy up responsibility. For example, "users should have control over timed responses." We then say, "ideally this handled by user agents, here is what authors need to do so that they can." However, instances where are not yet handled, then in techniques talk about what you need to do.
GV Yes, building off of what wendy said. Some things will never be controllable. Written as guidance under techniques.
GR 2 UAAG checkpoints "do not change content on explicit user request" and "configure redirects."
JW Neither covers scripts.
GR Right. That was a conscious decision. It was beyond the scope of the document. We don't have the techniques.
JW Instances with mutation events are not covered. Then this requirement has to stay.
GR UA WG always says an authoring problem.
Action WC: rewrite 2.4 based on this discussion.
WC /* reads kynn's proposal */
GV Says distractive for attractive, when all are considered attractive. Only reason they use it is to get your attention.
JW If 2.4 refers to updating content, then aren't distractive presentations the same as what we described in 2.4?
GV If your connection dropped.
WC reads more of proposal.
GR Proposed something to UA. e.g. configureation settings to prevent user to have a cascade order for messages from the UA. e.g. status bar. allow the user to say, i only want this to be used by the UA, don't let the author take it over with a script. Either prompt me or allow it. Told that this was a new requirement. I think it fits under orientation and navigation. Access to the user interface.
KHS Kynn's statement about alerts is one thing, but companies can't use that an excuse. Not just a cognitive issue, can be an annoying to anyone.
WC But that's the point of advertising. If it gets stuck in your head, they've done their job.
GR Right, that's why suggested as a UA issue.
WC Distraction is based on how our eyes are built, which means distractions aren't just about motion but color, size, and placement. Refer to eye-tracking and other studies.
JW How design for cognitive disabilities.
GR New proposal by Denis to allow people to toggle elements on and off. There might be a breakpoint where too many things might be a distraction. Then someone can set distraction level.
GV If I set it to 5, what does that mean?
GR Want to avoid "if images are a problem, turn them all off." For some, images are a help as long as not too many of them.
GV What if our guidelines did not prohibit anything except something that causes a seizure. Only if a wrong or right way, only the right way to do.
JW If they want to use streaming video with no streaming equivalent...
GV If they want to, if you're going to use, you need to use captions.
GR That's in checkpoint solutions. If using streaming video...
WC I think distraction is a subset of many of the other checkpoints. For example, color could be distracting, the author must separate content from presentation so the user can use the user agent to make changes. In cases of motion, this is covered by giving users control of mechanisms that change or move.
JW Therefore, we could delete this and move forward with what wendy has proposed. Tie these to UA in some way. Are there cases of distraction that would not be covered. Perhaps cover individually rather than a general checkpoint about distraction.
GV Want to go back to my previous comment, we should not prohibit distractions, if movement etc. is what you are talking about, you should be able to control. It is a problem for someone, everything will be a problem for someone. There is a function to attracting attention.
JW instead of specific checkpoint, deal with it piecemeal. a distraction is one consequence of a range of different phenomena, therefore deal with each individually rather than the consequence of it in one place.
GV Say what to do not don't do it. We will have to document since it will come up again.
Action WC: delete 2.2 deal with distractions piecemeal (since distraction is a consequence of a range of phenomena, deal with each individually rather than the consequence of it in one place.)
$Date: 2001/03/22 22:07:50 $ Wendy Chisholm