See also: IRC log
AM: Tweeted...lots of people re-tweeted
JT: ADIO still looking for items
for newsletter
... 6 emails from people sayig tehy wil review
JR: Hope to have proposed changes in a draft for next week.
http://lists.w3.org/Archives/Public/w3c-wai-au/2009OctDec/0031.html
JR: Starts explaining http://lists.w3.org/Archives/Public/w3c-wai-au/2009OctDec/0031.html
JT: Comments that even when mouse control is available, users can do much more with keyboard control which allows macros etc
GP: Keyboard plus mouse AT is fine....but keyboard access alone is not reasonable
TB: What about keyboard + AT
GP: THat's what I'm advocating
JT: we are talking aobut diff between functional possibility and functional equivalence
JR: Any objections to the items proposed in A.3.1.2
A.3.1.2 Drawing Keyboard Access (Minimum): The following *drawing
functionality* (if present) is operable through a keyboard interface
(Level A):
(a) inserting new drawing objects; and
(b) selecting drawing objects; and
(c) moving drawing objects; and
(d) modifying the overall size of drawing objects; and
(e) rotating drawing objects; and
(f) adding/editing text for drawing objects
Note: It is possible to implement keyboard access directly (e.g.,
keyboard-driven manipulation of drawing objects) or indirectly (e.g.,
keyboard editing of drawing object property values).
*Drawing functionality:*
Authoring tool functionality that involves adding or modifying graphical
representations of content (e.g., rotating a shape in a vector graphic
editor, using a freehand “airbrushing ” tool in a raster graphic editor,
resizing a div element in a WYSIWYG webpage editor, adding freehand
waveforms to a visual representation of audio content in an audio
editor). *Drawing objects* are graphical representations of content that
remain independently selectable, in contrast to graphical
representations that do not remain selectable (e.g., when drawing
actions are made directly to a single raster graphic).
GP: Thinking about "movement"
JRL: Thinking about nudging up, down, left, right
GP: Seems to work for that use-case
JR: Mentions : A.3.1.4 Drawing Keyboard Access (Intermediate): Any drawing
functionality of the authoring tool is operable through a keyboard
interface, except where the input depends on the path of the author's
movement and not just the endpoints.
Note: It is possible to implement keyboard access directly (e.g.,
keyboard-driven manipulation of drawing objects) or indirectly (e.g.,
keyboard editing of drawing object property values).
JR: And...A.3.1.6 Drawing Keyboard Access (Enhanced): Any drawing functionality of
the authoring tool is operable through a keyboard interface. (Level AAA)
Note: It is possible to implement keyboard access directly (e.g.,
keyboard-driven manipulation of drawing objects) or indirectly (e.g.,
keyboard editing of drawing object property values).
GP: I guess for AAA that's fine.
JS: THis is a totally different
direction...I'm thinking....
... I think the only exceptions should be for advanced pointing
functions...like pressure
JT: And direction relations to speed etc?
<jeanne> there should be an exception for advanced pointing functions that don't map to a keyboard, like pressure tablets.
JR: Just concerned if we have a very small exceptiion it will dissuade tools that are quite good but not completely there
JT: Maybe we can reiterate that we are not looking for functional equivelence we are looking for keyboard hooks to make use possible.
GP: In illustrator...can draw
rectangle using keyboard...but using keyboard don;t have as
many options for precise placement
... Is that good enough?
JT: Other thing is that a lot of the alternative input systems that exist in this space are using keyboard functions rather than pointers....e.g. when using gestures...hook in to keyboard rather than the mouse
GP: Endpoints are fine...but
definition of path is a problem
... And to be fair...people doing high-lvel graphics are using
tablets and styluses
... So these people are already using alternative input
devices
JT: And if you look at how these hook in, they are sending bit by bit info
GP: So I guess I'm saying I don't want us to come up with a defn of accessibility that relegates these tools as being defined as deficient
JT: We have programmatic contol wording already....
GP: Just trying to make point
that functional equivalence is not possible in some cases
... Will come up with comments on the proposal
<scribe> ACTION: GP to Comment on Drawing Keyboard Access proposal by Nov 16 [recorded in http://www.w3.org/2009/11/09-au-minutes.html#action01]
<trackbot> Created ACTION-194 - Comment on Drawing Keyboard Access proposal by Nov 16 [on Greg Pisocky - due 2009-11-16].
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Jan Inferring Scribes: Jan Default Present: Jeanne, Jan, Greg_Pisocky, Jutta, AnnM, +1.301.963.aaaa Present: Jeanne Jan Greg_Pisocky Jutta AnnM +1.301.963.aaaa Agenda: http://lists.w3.org/Archives/Public/w3c-wai-au/2009OctDec/0029.html Got date from IRC log name: 09 Nov 2009 Guessing minutes URL: http://www.w3.org/2009/11/09-au-minutes.html People with action items: gp WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]