minutes of 3 January 2002 Telecon

Present:  Gian Sampson-Wild, Mark Stimson, Cynthia Shelly, Katie 
Haritos-Shea, Gregg Vanderheiden, Eugenia Slaydon, Jo Miller.

Summary (Gregg has captured these main points more precisely and will 
post to the list):

2.5
1. need a complete list of generic event handlers (or a place where 
they're officially defined--put in glossary?)
2. Is requirement for generic event handlers going to ensure keyboard 
access? If not, do we need to include keyboard access as requirement?
3. Is there an exception for any kind of direct-manipulation 
interface? (What about flying a plane.)

Conclusion: Further discussion on 2.5 is postponed until we have a 
generic list.

2.6
1. Would be great if there was a tool to measure flicker.
2. "What is flicker? If I can't tell it's flickering, does it pass?"
3. What if it's caused by slow computer, will I know?

Conclusions: No amendments except to add an example: your animation 
doesn't flicker when played. (This example adds the word animation so 
people know where we're coming from.)

2.7
1. Recommend that this be changed to advice.
2. reword as the three pieces of advice as follows:
  a) "as possible, provide suggestions, when input is invalid due to 
spelling  spelling or other causes"
  b) if possible, allow user to choose between choosing from a list 
and providing direct input. (not either/or; give user choice)
  c) if possible, user errors should be reversible or users should be 
given a warning.

Conclusions: Good advice, but not a checkpoint. Not worded well now.

-------------------------
Full minutes:

Gregg- Does 2.5 belong under 4?

Eugenia- Not under 4.

Jo- Think it goes under 2, not 4.

Gregg- Not subset of AT. It's talking about whether you have an 
option to use standard interfaces. Let's figure out the purpose of 2 
and the purpose of 4. It belongs in 2 because it's important in 
allowing people to decide which of the standard interfaces they want 
to use to access.

Katie- Still think it might belong under 4, we can talk about this more later.

Gregg. Let's revisit this at the end.
Agreed that this is more than AT compatibility?  [All agree.]
Success criteria seem sufficient. Do we want to add "per action" to 
the second criterion? And shouldn't keyboard be required as one of 
the event handlers? We do not require that things be operable from 
the keyboard. This is the only place keyboard appears, except for up 
before 1.1 in yak-yak section. What is a generic handler?

Jo- Don't these discussions always come back to OnFocus and onBlur 
and the uneven support for those generic handlers?

Gregg- Yes. There should be a list of generic event-handlers. 
[agreed] Some people could think that an event handler is generic 
when it is not. Does generic solve the problem?

Jo- From the discussions it seems that the browsers/agents haven't 
caught up with the specifications in this area. Generic ones not 
always supported. Is this the case?

Gregg- Yes. Just realized that these criteria don't work. If a 
generic is available and just doesn't work, criterion 1 doesn't 
require you to use anything else in addition to it. Maybe should be 
"All non-generic event handlers must have a generic event handler 
that provides parallel functions, or must have a keyboard event 
handler which provides the same function."

Jo- Does this cover the problem of lack of support for generic event handlers?

Gregg- Accessibility aids should support them (philosophical position).

Jo- But if we're not strictly talking about AT, but standard 
keyboard/browser combination that just might not support generics (I 
don't know what the level of support is right now, so this is 
theoretical).

Gregg- So maybe we should require keyboard support (as opposed to 
direct manipulation).

<someone>- Isn't tabbing direct manipulation?

Gregg- No, that's encoded. Gesture and pointing are direct 
manipulation, keyboard tabbing is encoded. Even pointer users have an 
onscreen keyboard, though.

Gian- What about people who only use a mouse and not a keyboard? Is 
that anyone?

Gregg- This only says you have to also have keyboard access, doesn't 
say that you can't use mouse-access too.

Katie- What about people who are mentally disabled and use devices like web-tv.

Gregg- If we required a keyboard, do we need to require anything 
else? For some people pointing may be all they can do. That means 
there's a lot that they won't be able to do on the web such as typing 
a URL or doing a search. We can't require that everything be doable 
via pointing.

Jo- I don't see it happening, in real life, that a developer will 
design a site that can be used only via keyboard, not mouse.

Gregg- I can see voice-only interactions being designed. Speech 
interface only. If you said the mouse has to be usable, what would 
the mouse do?

Gian- It's theoretically possible. If we say keyboard access, then 
people will have the same response as people who think accessibility 
means text-only?

Gregg- Let's say you have a direct-manipulation interface and you 
can't make it keyboard operable. Can the site never be accessible 
unless you remove this feature?

Gian- I run into this problem with PDFs. People remove the content 
rather than create accessible versions.

Jo- Isn't keyboard access a requirement in the UA guidelines? So if 
it is, shouldn't we require it too?

Gregg- They require keyboards to handle generics. Need a complete 
list of the generics. If we don't have a definitive list, our 
checkpoint fails.

Katie- Put 'generic event handlers' in the glossary.

Gregg- Yes. Is a requirement for generic [event handlers] going to 
ensure keyboard access? If not, then we need to require keyboard 
access as an option. That gets us back to "does that mean I can never 
have a direct-manipulation interface"? Like a picture of a universe 
with an infinite number of points, where you can zoom in on a part of 
the screen with a click. Can't tab to that.

Mark and Gian- You can do it by saying "zoom in" then "move left, 
move right", or you can provide a ruler on each side and allow users 
to enter coordinates by keyboard.

Gregg- What about a school system adopting these checkpoints, and 
then they can't have any interactive games in the whole school? Now 
in section 508 they said in all actions where the action or its 
outcome could be described in words, then the action has to be 
keyboard accessible. Means you don't have to have access to the paint 
programs via the keyboard, for instance.

Gian- Wouldn't that require some kind of AI?

Gregg- If I said "press the go button," I can describe that in words, 
so it should be accessible via the keyboard.

Gian- So zooming in on the top left hand corner can't be described in words?

Gregg- Zoom, pan up, pan down are things that you should be able to 
support. But coordinates...Isn't this particular one a user agent 
issue?

Katie- Sounds like it.

Gregg- This is doable that way, but flying an airplane through a canyon is not.

Gian- That doesn't mean it can't be done, that's a time thing. Which 
is covered in requirements. You can slow it down.

Gregg- If user agent gave you ability to move the pointer, that would 
solve the problem.

Gian- Should we be looking at this from a point of view that you 
should be able to use the keyboard just because you're blind...

Jo- Hey! Motor impairments! Not just blind people who aren't mouse-users.

Gregg- And typing in coordinates doesn't help the person who is 
blind, because they can't see where the coordinates are. Let's come 
back to this after we have a list of what the generics are. So: 1. we 
need a list and need to put generic event handlers in the glossary, 
and 2. we need to ensure that keyboard access is captured, and 3. is 
there an exception for any type of direct manipulation interface? 
What about flying a plane? Note: remember that slow operation is 
already required for non-competitive or real-time situations.

Greg. On to flicker.

Eugenie- how do you count flicker? I can't count that fast.

jo- If you can see it flickering, it's probably in the danger range. 
Above 49, you're into the refresh rate of many monitors, and you 
probably won't notice it flickering.

Gregg- Some people have seizures watching TV. But 20 is the real danger range.

Eugenie- Is there something you can do as a web developer that would 
cause this? Other than animated gifs and Flash? Can we put examples 
so people will realize that it's not something they're going to 
stumble into by accident.

Gian- Means you can't have something going on and off at a regular 
rate. The whole point is not so much what frequency but that it can't 
be regular. Anything that's regular will cause seizure in someone.

Gregg- Is there a tool where you can submit your site and have it 
check? Seems like it would be doable. Also, if you have one pixel 
flashing, it's not going to trigger anything, but if the whole screen 
is flashing, it can be very bad. We talk about frequency but not 
intensity, size, other things. If it's a small object and you're 
looking at it, it uses a huge amount of your brain, so you can't just 
use size. It would be great to have a tool or a website that tests 
for flicker rate. What if it is caused by slow computer, how will I 
know?

Katie- That's not an authoring issue.

Gregg- If i set up something that flickers on something lower than a 
gigahertz...

Katie- Then we need some info on what systems will affect the 49 hertz.

Gregg- This could benefit greatly from an instrument. [agreed]

Katie- And in lieu of the tool, is there a technique to 
determine/control your flash rate?

Gregg- Under benefits maybe?

Eugenie- Or an example.

Gregg- OK, on to 2.7- handle errors such as misspellings.

Jo- This checkpoint as currently written has lots of problems. 1. 
Success criteria do not deal with any errors but spelling. But we 
have left the checkpoint open-ended. It includes many possible input 
errors but does not define that set of errors or address their 
handling in the success criteria. We just know that spelling is one 
of them--what are the others?
2. Second criterion should not be instead of, but as well as. 
User-vs-user here: blind people don't want to listen to a whole list, 
long pulldown lists are hard to use with screen magnifiers, etc.
3. This is good advice but it doesn not seem to qualify as a checkpoint.

Gregg- Also it is not possible to recover from or correct many 
(most?) errors. What does "handle" mean?
Conclusion- current guideline good advice, but unworkable as a 
checkpoint as worded.

Katie- It's not worded right even if it's for good advice.

Gregg- Maybe should say user errors should be reversible (this is 
advice, not required). Or a warning should be given before execution.

Katie- Isn't that like prompt? We covered that.
Every time we cover that, it seems to be a UA issue.

Gregg- And the issue here is where do you stop? How much help, how 
much error-handling, and does it mean that every website must have a 
spelling checker in it?

Jo- Philosophical issue: we require (at least implicitly) that people 
with disabilities invest in or acquire or use assistive technology. 
We don't say a developer must provide an audio track of their entire 
site for blind people, we expect people to use screen readers for 
that. Is it too much to require someone with spelling problems to use 
a free online dictionary or to consult a dictionary that they own? 
Rather than requiring the developer to anticipate every possible 
error and accommodate it?

Katie- I don't think you can require anyone to invest in anything. 
We've had discussions about baseline.

Gregg- But we do require people to have assistive technology if you need it.

Katie- But I think this is different.

Mark- General point on this checkpoint: I don't think that it makes 
as much sense to include it because I don't see it as addressing 
accessibility. If I have dyslexia and you have a site that doesn't 
handle input errors, I don't see that as making the site inaccessible 
for interaction, though it might just make it more difficult. 
Sometimes those error-handling things also give you the wrong 
suggestion for spelling, too.

Gregg- Recommendations 1) that this be changed to advice 2) reword as 
the three pieces of advice as follows: a) "as possible, provide 
suggestions, when input is invalid due to spelling  spelling or other 
causes" b) if possible, allow user to choose between choosing from a 
list and providing direct input. c) if possible, user errors should 
be reversible or users should be given a warning.
So we think it's good advice, but it doesn't make a checkpoint for a 
number of reasons. That brings us to 3. Some general issues. Use 
consistent presentation.
This should be use predictable presentation, perhaps?

Gian- Designers would throw it out the window.
Is this one site or more? Consistency within a site or among 
different sites? Seems subjective and easily misconstrued.

Gregg- And making things too uniform is itself disorienting, people 
with cognitive disabilities can't figure out the context change.

Gian will continue with more thoughts on this checkpoint on mailing list.

Gregg- We're on 3 and we just have 3 and 4 to go. 3 is comprehension. 
Everyone, think about table of contents, stare at it, and try to 
think: those things that we can't make specific, how are we going to 
handle the fact that we're failing to objectify some of these things 
that we think are important to be around. Suggestions?

--
Jo Miller
jo@bendingline.com

Received on Thursday, 3 January 2002 18:08:00 UTC