- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Mon, 07 Apr 2008 20:39:32 -0400
- To: David Poehlman <poehlman1@comcast.net>
- CC: Gregg Vanderheiden <gv@trace.wisc.edu>, "'Sean Hayes'" <Sean.Hayes@microsoft.com>, "'WAI-UA list'" <w3c-wai-ua@w3.org>
Hi Dave, You're right in theory, but it's a question of complexity (and thus practicality). When a drawing pad is used to "paint" a "brush stroke" on an electronic "canvas" the result is "just" a static bitmap...but it is an extremely complex one that took as input the stylus's speed, pressure and movement in 2-D space over hundreds of time points as inputs. While these could be specified by a large number of numeric parameters, there is a practical limit. Cheers, Jan David Poehlman wrote: > so you are saying free hand drawing cannot be done via the keyboard? I > agree flying a vehicle or even driving one might be collosally difficult if > possible, but Unless I'm missing something, anything that is stationary can > be done with a keyboard. > > ----- Original Message ----- > From: "Gregg Vanderheiden" <gv@trace.wisc.edu> > To: "'Sean Hayes'" <Sean.Hayes@microsoft.com>; "'Jan Richards'" > <jan.richards@utoronto.ca>; "'David Poehlman'" <poehlman1@comcast.net> > Cc: "'WAI-UA list'" <w3c-wai-ua@w3.org> > Sent: Monday, April 07, 2008 2:00 PM > Subject: RE: UAAG2 Guideline 4.1 Level A Only (following 3 April 2008 Call) > > > > The exception (which is in TEITAC and WCAG) is > > [Except where] the underlying function requires input that depends on the > [full] path of the user's movement and not just the endpoints. > > > So the exception isn't about drawing that can be done with rubber band lines > or anything that can be (easily) specified without a near infinite number of > data points - but rather to things like freehand drawing. > > This provision interacts with the timing provision to also not require > keyboard access to things like flying a helicopter in real-time. > > We are doing some work to look at the limits of different types of input > devices for different tasks. It is interesting and challenging when you get > down to the details. > > > > Gregg > -- ------------------------------ > Gregg C Vanderheiden Ph.D. > If Attachment is a mail.dat try http://www.kopf.com.br/winmail/ > > > >> -----Original Message----- >> From: w3c-wai-ua-request@w3.org >> [mailto:w3c-wai-ua-request@w3.org] On Behalf Of Sean Hayes >> Sent: Monday, April 07, 2008 10:15 AM >> To: Jan Richards; David Poehlman >> Cc: WAI-UA list >> Subject: RE: UAAG2 Guideline 4.1 Level A Only (following 3 >> April 2008 Call) >> >> >> The TEITAC exception does not cover all drawing, only that >> which really requires real time capture (such handwriting >> analysis, or as exhibited by some paint type applications >> where pressure and velocity affect the final stroke). Basic >> line drawing, shapes and stuff like that could be done via >> the keyboard. >> >> Sean Hayes >> Media Acessibility Strategist >> Accessibility Business Unit >> Microsoft >> >> Office: +44 118 909 5867, >> Mobile: +44 7875 091385 >> >> -----Original Message----- >> From: w3c-wai-ua-request@w3.org >> [mailto:w3c-wai-ua-request@w3.org] On Behalf Of Jan Richards >> Sent: 04 April 2008 21:40 >> To: David Poehlman >> Cc: WAI-UA list >> Subject: Re: UAAG2 Guideline 4.1 Level A Only (following 3 >> April 2008 Call) >> >> >> Hi Dave, >> >> I'm not very comfortable with exceptions either...and didn't >> take it lightly writing it... >> >> How would you want to handle drawing, etc.? Driving the mouse >> with keys or do you have something else in mind? >> >> Cheers, >> Jan >> >> >> >> David Poehlman wrote: >>> We had a big discussion about this in the ITTac. >>> "available. The only exception is for underlying functions >> that depend >>> on the path of the user's movement and not just the >> endpoints (e.g., drawing)." >>> Suffice it to say that I take exception with the exception. >>> >>> >>> >>> ----- Original Message ----- >>> From: "Jan Richards" <jan.richards@utoronto.ca> >>> To: "WAI-UA list" <w3c-wai-ua@w3.org> >>> Sent: Friday, April 04, 2008 4:08 PM >>> Subject: UAAG2 Guideline 4.1 Level A Only (following 3 April 2008 >>> Call) >>> >>> >>> >>> The other thing we were doing on the 3 April 2008 UAWG call was >>> looking at the Level A requirements of 4.1. I made some >> notes from the >>> discussion and have tried to turn them into a proposal that also >>> attempts to bring in the requirements for "visual indicators": >>> >>> ORIGINAL Wording: >>> http://www.w3.org/TR/UAAG20/#principle-operable >>> >>> NEW Wording Ideas: >>> >>> Level A Success Criteria for Guideline 4.1 >>> >>> 4.1.1 Keyboard Operation: All functionality can be >> *operated via the >>> keyboard*, even if pointing device-only modes of operation are also >>> available. The only exception is for underlying functions >> that depend >>> on the path of the user's movement and not just the >> endpoints (e.g., drawing). >>> 4.1.2 Keystroke Precedence: The precedence of keystroke >> processing is >>> documented (e.g., user agent interface, then user agent extensions, >>> then content features administered by the user agent such as >>> accesskey, and then executable content). >>> >>> 4.1.3 No Keyboard Trap: When the content display has focus, >> a standard >>> keyboard command is always available that can "back out" >> the focus by >>> one level in the content hierarchy. From the top level of the >>> hierarchy, this command moves focus to the user agent's >> chrome (e.g., >>> the address bar). >>> >>> 4.1.4 Caret Text Navigation: Views that render text also >> support the >>> standard text area conventions for the platform (e.g., "arrow" key >>> navigation, shift-to-select mechanism). >>> >>> 4.1.5 Indicating Direct Keyboard Command (Chrome): A mode >> is provided >>> in which any *direct keyboard commands* associated with the >> currently >>> displayed controls in the user agent chrome are indicated: >>> (a) visually at the location of the control (e.g. with an accesskey >>> underlined, with an overlay), and >>> (b) centrally in a programmatically available fashion >> (e.g., the menu >>> system). >>> >>> 4.1.6 Indicating Direct Keyboard Command (Content Display): >> A mode is >>> provided in which any *direct keyboard commands* associated >> with the >>> currently displayed controls in the content display are indicated: >>> (a) visually at the location of the control (e.g. with an overlay), >>> and >>> (b) centrally in a programmatically available fashion >> (e.g., a list of >>> accesskeys). >>> >>> >>> >>> >>> NOTES: >>> >>> 4.1.4 Separate Activation: REMOVED -DUPLICATES 3.12.11 >>> >>> 4.1.7 "Chrome" Navigation: REMOVED - IMPLICIT IN 4.1.1 >>> >>> >>> >>> >>> Cheers, >>> Jan >>> >>> >>> >>> >>> >> -- >> Jan Richards, M.Sc. >> User Interface Design Specialist >> Adaptive Technology Resource Centre (ATRC) Faculty of >> Information Studies University of Toronto >> >> Email: jan.richards@utoronto.ca >> Web: http://jan.atrc.utoronto.ca >> Phone: 416-946-7060 >> Fax: 416-971-2896 >> >> >> >> >> >> > > > > -- Jan Richards, M.Sc. User Interface Design Specialist Adaptive Technology Resource Centre (ATRC) Faculty of Information Studies University of Toronto Email: jan.richards@utoronto.ca Web: http://jan.atrc.utoronto.ca Phone: 416-946-7060 Fax: 416-971-2896
Received on Tuesday, 8 April 2008 00:39:05 UTC