22 March 2001 WCAG WG Minutes

http://www.w3.org/WAI/GL/2001/03/22-minutes.html

22 March 2001 WCAG WG Minutes
Summary of action items and resolutions
·       Action WC: incorporate these into the draft to be released next week.
·       Action WC: rewrite 2.4 based on this discussion.
·       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.)
Participants
·       Katie Haritos-Shea
·       Gregory Rosmaita
·       Wendy Chisholm
·       Annuska Perkins
·       Dick Brown
·       Jason White
·       Gregg Vanderheiden
Regrets
·       Charles McCathieNevile
·       Matt May
·       Cynthia Shelly
·       Andi Snow-Weaver
·       William Loughborough
·       Bruce Bailey
·       Kynn Bartlett
·       Len Kasday
Split 2.1?
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.
Drop 2.4, user agent issue?
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.
Kynn's proposal for "distractions" (cp 2.2)
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

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Thursday, 22 March 2001 17:09:03 UTC