- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Thu, 3 May 2007 01:21:37 -0500
- To: <w3c-wai-gl@w3.org>
- Cc: "'Andi Snow-Weaver'" <andisnow@us.ibm.com>, <Bailey@Access-Board.gov>, <curtischong@earthlink.net>, <Earl.Johnson@Sun.COM>, "'Richard Schwerdtfeger'" <schwer@us.ibm.com>, "'Sean Hayes'" <Sean.Hayes@microsoft.com>
- Message-ID: <002701c78d4b$519177e0$136fa8c0@NC84301>
I agree that it is better to use language in a provision than have to refer to a definition. Couldn't figure out how to do this without making it too complicated. But looking for suggestions that might work. RE: Using the "path of the pointer movement", not the "path of the users movement". This limits this to just pointing devices rather than including other gesture devices besides pointing devices. I pasted the original proposal below. Trying to paste the definition into the provision gives us: "All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying task requires input that depends on the path of the user's movement and not just the endpoints. (Level A) A bit long. And it doesn't allow us an easy way to attach the notes.... Hmmmmm Maybe "All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying task cannot be accomplished without input that includes the path of the users movement and not just the endpoints. (Level A) Again quite long. But clearer perhaps. The tricky part is wording it so that it is clear that the path dependence applies to the underlying task and not in the interface task. Handwriting input is an input (interface) technique that requires path dependent input but the underlying task is text - which does not. Thoughts? Gregg 2.1.1 Keyboard (Except): All functionality <http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/#functiondef> of the content is operable through a keyboard interface <http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/#keybrd-interfacedef> without requiring specific timings for individual keystrokes, except where the underlying functionality requires path dependent input. (Level A) <http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20070426/Overview.h tml#keyboard-operation-keyboard-operable> 2.1.2 Keyboard (No Exception): All functionality <http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/#functiondef> of the content is operable in a non-time-dependent manner through a keyboard interface <http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20070426/#keybrd-interfacedef> . (Level AAA) path dependent input input that depends on the path of the user's movement and not just the endpoints. Note: This relates to the underlying function - not the input technique. For example, using gestures to enter text is an input technique where the outcome is dependent on the path of the user's movements but the underlying functionality is just text input (which does not require that one use an interface that records or passes on the user's movement paths). Note: Most actions carried out by a pointing device can also be done from the keyboard (for example, clicking, selecting, moving, sizing). However, there is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion without requiring an inordinate number of keystrokes. Free hand drawing, watercolor painting, and flying a helicopter through an obstacle course are all examples of functions that require path dependent input. Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. > -----Original Message----- > From: Andi Snow-Weaver [mailto:andisnow@us.ibm.com] > Sent: Wednesday, May 02, 2007 11:13 AM > To: Gregg Vanderheiden > Cc: Bailey@Access-Board.gov; curtischong@earthlink.net; > Earl.Johnson@Sun.COM; 'Gregg Vanderheiden'; Richard > Schwerdtfeger; 'Sean Hayes' > Subject: RE: Gapsin Web Requirements- keyboard operation > > Gregg, > > I think this is a good way to describe it. > > I would prefer to just use the words in the provision rather > than creating the term "path dependent input" and then having > to define it. > > Also, I would say it is the "path of the pointer movement", > not the "path of the users movement". > > I haven't seen anyone except Bruce weigh in on this proposal. > Can we talk about this today? > > Andi > andisnow@us.ibm.com > IBM Human Ability & Accessibility Center > (512) 838-9903, http://www.ibm.com/able > > > > > > "Gregg > > Vanderheiden" > > <gv@trace.wisc.ed > To > u> "'Gregg Vanderheiden'" > > <gv@trace.wisc.edu>, > Andi > 05/01/2007 04:26 > Snow-Weaver/Austin/IBM@IBMUS > PM > cc > > <curtischong@earthlink.net>, > > <Earl.Johnson@Sun.COM>, Richard > > Schwerdtfeger/Austin/IBM@IBMUS, > "'Sean Hayes'" > > > <Sean.Hayes@microsoft.com>, > > <Bailey@Access-Board.gov> > > Subject > RE: Gapsin Web > Requirements- > keyboard operation > > > > > > > > > > > > > > > > > > To clean this up a bit it might look like this for WCAG > (where we have two levels of conformance for this) > > > 2.1.1 Keyboard (Except): All functionality of the content is > operable through a keyboard interface without requiring > specific timings for individual keystrokes, except where the > underlying functionality requires path dependent input. (Level A) > > > > 2.1.2 Keyboard (No Exception): All functionality of the > content is operable in a non-time-dependent manner through a > keyboard interface. (Level AAA) > > path dependent input > > > input that depends on the path of the users movement > and not just > the endpoints. > > > Note: This relates to the underlying function - not the input > technique. For example, using gestures to enter text > is an input > technique where the outcome is dependent on the path of > the users > movements but the underlying functionality is just text > input (which > does not require that one use an interface that records > or passes on > the user's movement paths). > > > Note: Most actions carried out by a pointing device can > also be done > from the keyboard (for example, clicking, selecting, > moving, sizing). > However, there is a small class of input that is done > with a pointing > device that cannot be done from the keyboard in any > known fashion > without requiring an inordinate number of keystrokes. > Free hand > drawing, watercolor painting, and flying a helicopter through an > obstacle course are all examples of functions that require path > dependent input. Drawing straight lines, regular > geometric shapes, > re-sizing windows and dragging objects to a location > (when the path > to that location is not relevant) do not require path dependent > input. > > > > > Gregg > -- ------------------------------ > Gregg C Vanderheiden Ph.D. > > From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] > Sent: Tuesday, May 01, 2007 3:42 PM > To: 'Gregg Vanderheiden'; 'Andi Snow-Weaver'. > Cc: 'curtischong@earthlink.net'; 'Earl.Johnson@Sun.COM'; > 'Richard Schwerdtfeger'; 'Sean Hayes'; 'Bailey@Access-Board.gov' > Subject: RE: Gapsin Web Requirements- keyboard operation > > There has been a lot of discussion here and in other > standards regarding the language to use for Keyboard > operation. The goal is to have everything accessible from > they keyboard whenever possible > > > > > If all functionality can be achieved using the keyboard, it > can be accomplished by keyboard users, by speech input (which > creates keyboard input), by mouse (using on-screen > keyboards), and by a wide variety of assistive technologies > that create simulated keystrokes as their output. No other > input form has this flexibility or is universally supported > and operable by people with different disabilities. There is > a limitation however in that it is not possible to make > everything operable from the computer. > > > While much can be done there are things like freehand > sketching or watercolor painting or threading a helicopter > through a barrage of flack and obstacles that cannot be done > from the keyboard without an in-ordinate number of > keystrokes. (e.g. For watercolor painting one could specify > for each pixel along the travel path the exact direction and > width / depth of color to apply but it would be hundreds or > thousands of keystrokes to represent one brush stroke.) > > > To capture the dividing line between what is practical and > what is not, a number of things have been proposed. These include > > > 1) ....whenever the action or its outcome can be > described in words > > > a. This works unless you allow an inordinate > number of words. > The length and simplicity of the sentence then becomes the > dividing line and the discussion continues as to > how to draw a > line there. Also there was confusion as to whether this > required things to be controlled by typing in a sentence > describing the outcome (i.e. it was confusing why > this was the > 'bright line'). > > > 2) ... except when the underlying function requires > time-dependent > analog input > > > a. This tries to get at the cause of the > restriction (i.e. > why it is and exception) but there is a lot of > discussion about > the fact that any analog input can be described > as an infinite > number of discreet motions (see above). The > time-dependent > seems to eliminate the ability to use an infinite > number of > commands but then this appears to overlap with > the 'time limit' > provision which has exceptions. > > > 3) ...except if the underlying function requires path > dependent input > > > a. Free hand drawing, watercolor painting, and flying a > helicopter through an obstacle course are all examples of > functions that require path dependent input. > Drawing straight > lines, regular geometric shapes, sizing windows > and dragging > objects to a location (when the path to that > location is not > relevant) do not require path dependent input. > > > The suggestion is to use #3. Comments are sought as to > problems with this approach (#3) or whether it was the best > approach or not (for drawing the line between what should > have to be controllable from a keyboard and what should not > be required at the basic level of accessibility). > > > NOTE: there is a higher level of accessibility that requires > ALL content to be controlled from a keyboard to be VERY accessible. > > Gregg > > ------------------------ > Gregg C Vanderheiden Ph.D. > Professor - Depts of Ind. Engr. & BioMed Engr. > Director - Trace R & D Center > University of Wisconsin-Madison > <http://trace.wisc.edu/> FAX 608/262-8848 DSS Player at > http://tinyurl.com/dho6b If Attachement is a mail.dat try > http://www.kopf.com.br/winmail/ > > > > > > > > > Gregg > -- ------------------------------ > Gregg C Vanderheiden Ph.D. > > > > > -----Original Message----- > > From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] > > Sent: Wednesday, March 28, 2007 12:00 PM > > To: 'Andi Snow-Weaver' > > Cc: 'curtischong@earthlink.net'; 'Earl.Johnson@Sun.COM'; 'Richard > > Schwerdtfeger'; 'Sean Hayes'; 'Bailey@Access-Board.gov' > > Subject: RE: Gapsin Web Requirements- keyboard operation > > > > The comment was to the group - including you Andi. > > > > See Bruce's note that followed re timing. If we separate > > analog and time dependent it changes the whole scope of the > exception. > > > > See my other note on volume. Oh I see - I didn't finish it. > > > > Will do so and send out. > > > > > > Gregg > > -- ------------------------------ > > Gregg C Vanderheiden Ph.D. > > > > > > > > > -----Original Message----- > > > From: Andi Snow-Weaver [mailto:andisnow@us.ibm.com] > > > Sent: Tuesday, March 27, 2007 5:57 PM > > > To: Gregg Vanderheiden > > > Cc: curtischong@earthlink.net; Earl.Johnson@Sun.COM; Richard > > > Schwerdtfeger; 'Sean Hayes'; Bailey@Access-Board.gov > > > Subject: RE: Gapsin Web Requirements- keyboard operation > > > > > > Gregg, > > > > > > Was that question for me or for the rest of the group? My > > view is that > > > the first note implies it should be an OR. To me, a task > > that CAN be > > > done with keystrokes but it would require an inordinate > > number of them > > > is ANALOG but is not necessarily time dependent AND analog. > > So I would > > > vote for the "or" > > > instead of the comma. > > > > > > We need to finish this ASAP. Can we all agree on the latest > > proposal > > > if we use "time dependent or analog input"?. > > > > > > That is: Except where the underlying task requires > > time-dependent or > > > analog input, all functionality of the content is operable > > through a > > > keyboard interface without requiring a specific duration for any > > > individual keystroke. > > > > > > (Adding Bruce Bailey as he expressed interest in this topic.) > > > > > > Andi > > > andisnow@us.ibm.com > > > IBM Human Ability & Accessibility Center > > > (512) 838-9903, http://www.ibm.com/able > > > > > > > > > > > > > > > > > > "Gregg > > > > > > Vanderheiden" > > > > > > <gv@trace.wisc.ed > > > To > > > u> Andi > > > Snow-Weaver/Austin/IBM@IBMUS > > > > > > cc > > > 03/22/2007 01:14 > > > <curtischong@earthlink.net>, > > > PM > > > <Earl.Johnson@Sun.COM>, Richard > > > > > > Schwerdtfeger/Austin/IBM@IBMUS, > > > "'Sean Hayes'" > > > > > > > > > <Sean.Hayes@microsoft.com> > > > > > > Subject > > > RE: Gapsin Web > > > Requirements- > > > keyboard operation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Here is what we are looking at in WCAG right now. > > > > > > > > > It looks pretty good but one member suggested we change > > > "time-dependent, > > > analog input" to "time-dependent OR analog input". > > This would be > > > significant and is being explored now. > > > > > > > > > Thoughts on this version? > > > > > > Thoughts on the "comma or OR" question? > > > > > > Gregg > > > > > > > > > > > > 2.1.1 Keyboard: Except where the underlying task requires > > > time-dependent, > > > analog input, all functionality of the content is operable > > through a > > > keyboard interface without requiring a specific duration for any > > > individual keystroke. > > > Note: Tasks that would require an inordinate number of > keystrokes > > > instead of one time-dependent, analog input are considered > > to require > > > time-dependent, analog input., > > > Note: This does not preclude and should not discourage the > > support of > > > other input methods (such as a mouse) in addition to keyboard > > > operation. > > > > > > > > > Revised INTENT section from Understanding 2.1.1 > > > > > > The intent of this success criterion is to ensure that, wherever > > > possible, content can be operated through a keyboard or keyboard > > > interface. When content can be operated through a keyboard or > > > alternate keyboard, it is operable by people with no vision (who > > > cannot use devices such as mice that require eye-hand > > coordination) as > > > well as by people who must use alternate keyboards or > input devices > > > that act as keyboard emulators. Keyboard emulators include speech > > > input software, sip-and-puff software, on-screen keyboards, > > scanning > > > software and a variety of assistive technologies and alternate > > > keyboards. Individuals with low vision also may have > > trouble tracking > > > a pointer and find the use of software much easier (or only > > > possible) if they can control it from the keyboard. > > > The phrase "without requiring a specific duration for any > > individual > > > keystroke" is used ensure that speech recognition, Morse > > code, macros > > > and many other alternate ways of 'typing' > > > can be used that do not allow users to hold individual keys > > down for > > > specific periods of time. > > > The phrase "except where the task requires analog, time-dependent > > > input" is included to separate those things that cannot > > reasonably be > > > controlled from a keyboard. For example, a watercolor application > > > where the stroke is defined by the movement and speed of movement > > > and/or pressure is not something that can be controlled from a > > > keyboard except by entering an almost infinite number of > > incremental > > > move commands combined with the duration effect (e.g. width > > of line at > > > each point). The use of MouseKeys also would not satisfy > > this success > > > criterion because it is not a keyboard equivalent to the > > application; > > > it is a mouse equivalent (i.e. > > > it looks like > > > a mouse to the application). If the application itself > > implemented a > > > MouseKeys like interface it would violate either the "key > duration" > > > provision (if holding the key down was used) or the > > 'inordinate number > > > of commands" provision if one keystroke for each pixel" was > > > required. Thus > > > MouseKeys, although very valuable for allowing access to > > > non-conforming content, cannot be used to meet this provision. > > > Again, it is emphasized that making things mouse operated > > as well as > > > keyboard operated is not discouraged and is in fact strongly > > > encouraged. > > > Note: The time-dependent analog input is not a time limit > > situation, > > > so is not covered by 2.2.1. > > > When considering whether analog, time-dependent input is > > required for > > > the underlying task (what you are trying to do) a > critical question > > > is, could you achieve the same functionality in a different > > way using > > > an input device that was not analog, time-dependent (e.g. using a > > > keyboard). > > > Another quick test is to ask whether the command or its > > outcome could > > > be described in a sentence having only one clause. > > > > > > Examples 1: A 'Frogger' game is designed so that the user > > can operate > > > it from the keyboard. When the spacebar is pressed the > frog jumps. > > > The jump command is keyboard operated and not a function of > > time. The > > > game itself involves timing (e.g. person needs to tell > the frog to > > > jump at the right > > > time) but that timing is covered by 2.2.1 since the > timing doesn't > > > affect 'what' the input is, just 'when'. > > > Example 2: A physics lesson allows the user to learn about > > ballistic > > > motion by changing the angle and pressure of a cannon. The > > user can > > > adjust the angle and pressure and then watch the different > > paths and > > > distances the > > > cannonball travels. If designed to operate with a mouse > > > only it would > > > fail this SC. It would also fail if it was designed so > > that holding > > > down a key raised the barrel until released - and another > > key was held > > > down to increase the cannon pressure until the key is > > released when it > > > fires. > > > However it would pass if it was designed so that the person could > > > enter the angle and pressure from the keyboard (or change > > them with a > > > few key > > > presses) and then fire the cannon. > > > > > > > > > > > > > > > > >
Received on Thursday, 3 May 2007 06:22:02 UTC