See also: IRC log
<scribe> scribe: Gregory_Rosmaita
<scribe> scribeNick: oedipus
rssagent make logs public
<Jan> Current text (see 4.1):
<Jan> http://www.w3.org/TR/2008/WD-UAAG20-20080312/#principle-operable
<Jan> JR and JA attempts at requirements that include visual indicators:
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0052.html
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0053.html
<Jan> JR's attempt at definition of "Keyboard Commands":
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0078.html
zakim aaaa is Sean_H
zakim 0154558aaaa is Sean_Hayes
JR: would like to see if new
definition i proposed captured discussion from last week, what
it missed and needs to be added, then address kelly's concerns
about scope creep, and then return to priorities
... has everyone seen
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0078.html
[general assent]
JR: no replies
SH: been pushing to finish TITAC work for last week; started action item and review of JR's post
JR: will walk group through
... looking for meta term to capture access keys accelerator
keys, etc. and decided on "keyboard commands"
... signals sent from interfaces to keyboard or alternate
keyboard -- single key operation (for mute) and multiple key
combos, stickykeys, repeatkeys, etc.
SH: IME -- language where not
simple mapping from key to language concept
... japanese, chinese, etc.
JR: IME?
GJR: IME = Input Method Editor (http://en.wikipedia.org/wiki/Input_method_editor)
<KFord> ime = input method editor.
<KFord> Looks like I was a bit slow and Gregory beat me.
AC: like single key - like use of numeric keys; multiple keys simultaneously need to be broken down into 2 -- sequence of keys (stickykeys) for managing menu
http://a11y.org/kafs - basic functionality (defines stickykeys, repeatkeys, etc.)
JR: just a special case of single key -- operating UI with sequence of keys -- not so different from tabbing to list, using arrow to move to desired item; maybe add a note that single keys can be used in sequence to achieve a result
AC: single key in sequence
GJR: should borrow vocabulary from KAFS (builds on XBE Library)
SH: wording used for "accelerator key" talks about a toggle key plus an alpha-numeric key -- not really a combination but a sequence
JR: will take that out
AC: DeadKeys
JR: DeadKeys?
AC: exists in progs like MS Word -press key from key sequence nothing appears on screen -- appears keystroke dead; first keypress, deadkey goes in instead -- control plus comma in word, nothing happens, but if then type an "e" puts an accent upon the key
JR: not quite "dead" -- sequence of single keys where first one sets mode and what input follows follows mode
SH: direct command and sequential commands not pairs -- can have sequences of pluses -- key event can be single key or cluster or keys; not sure either or -- 2 parts of story, but not only parts
GJR: instead of "DeadKeys" "DelayedKeys"?
SH: driving mouse with keys (MouseKeys) and command line intercept also need to be considered
AC: for mouse emulation on keyboard should be mentioned as possibliiity -- draw distinction between keyboard and point-and-click -- keyboard not a substitute for mouse (bounded mouse free agent)
KF: need to state that feature like MouseKeys is not sufficient means of making keyboard accessible
AC: exactly -- people jump to conclusion that MouseKeys are acceptable alternate
SH: 2 concepts: keyboard commands and broader concept keyboard operation
JR: require keyboard operation in UAAG2 and one of them will be keyboard commands
SH: command line interfaces? like sequential commands, but not really
JR: worth considering
AC: command line usually ignored
SH: "power shell" - drive command
line -- unix/linux world command lines prevalent
... need to consider
AC: agree
JR: agree
GJR: agree
KF: agree
JR: broke down into 2 groups:
direct commands (tied to particular UI control for app function
in order to achieve action with one keystroke)
... direct command just does what you want done right
away
... sequential commands cannot be repeated immediately and less
common for them to activate controls (arrow keys for mouse
pointing on list -- need to note not same as other sequential
things)
SH: an accelerator key is a single character that gives focus to object and triggers default event -- default event may be to make menu pop-up, then use sequential keys
JR: no point in pressing accelerator key multiple times
SH: set up a mode so that direct
commands are available for specific purposes
... think have all right concepts but haven't teased out
fully
AC: useful to describe in functional terms rather than "sequential" and "direct" -- on windows, moving foucus to objects and then activting objects
SH: "before event" activates it,
but may need subsequent action
... fundamental difference: moving and sending events to things
one means of driving interface, directly reaching into
functionality another
AC: when press control plus f if happen to press alt key for entering a mode, global keystrokes may no longer work / may be trumped
GJR: precedence needs to be addressed -- OS keys usually trump all others
JR: fundamental dividing line between commands that cause navigation and those that don't?
SH: yes, on windows -- don't know
globally, but important distinction
... those that don't cause change of focus dealt with
differently
[scribe missed due to being disconnected]
KF: what file do you want to save this as -- still activating command, just stopping to let user save file where wants
JR: "wedge" word/concept -- not moving focus, because there is focus that moves but plenty of other things move focus
SH: if no UI just a bag of functions -- reaching around UI to get to functions directly (figuratively speaking)
AC: "direct commands" almost always available via UI -- faster ways to do things than working through menuing system or mouse on toolbar
JR: because people who designed them took care to program that way
GJR: tabindex="-1" doesn't apply to mouse
JR: right
... indicators is point judy stressing; good point, but tricky
to draw a box around; direct commands might be subdivided into
2 -- those associated with currently rendered controls and
those not directly associated with rendered controls (F1 to
open help; typing an a to input an "a" character); idea is
indicator on first class needs to expose accelerator; don't
think could require in UI, but could be easily accessible
SH: not just "currently rendered" but "currently rendered in current context"
JR: good point
... existing functionality in menus not controversial, but
toolbars...
SH: operating system might get
involved; AT might supply extra commands, plugins or embedded
apps may cause extra commands/reassignment of key
commands;
... concept of whether these things are static -- is CONTROL +
S always the same, or are bindings only available under certain
state or condition or context
JR: who provides -- JB's point is that a lot of people who need this aren't running ATs -- using keyboard with less strength, digits, etc.
SH: user agent like EMACS -- who provides control keys to EMACS -- written by tens of thousands of people funneled into app -- what is properly the UA's in that respect?
JR: in EMACS direct keyboard alternatives -- programmatically available to be understoon on activation of button tantamount to a display?
SH: point is that actual commands
provided by script writer being interpreted by EMACS
shell
... EMACS an environment which can be extended -- many others
in wide use
... AT only another contributor to an environment -- why
compllicated to deliver myriad software
JR: can cut through that by
saying it is up to claimant of conformance has to document
everything: this tool plus this extension plus whatever, and
disavow conformance for other external/third party pieces
... UAAG 1.0 had a lot that could be punted to ATs, but a lot
of issues where people need accessibility without AT
AC: like to think of keyboard as an AT
SH: dynamic content/interfaces -- certain amount of predictability necessary
JR: in terms of?
... underline under F to signal accelerator key?
SH: alt-w-1 maps to third tab in display sequence - created at runtime, can't write down because dependent upoon runtime conditions -- created by what user is doing
AC: all the more reason from moving away from "commmand" language -- how to drive app with keyboard not knowing which command to use -- principles for driving an application and operating it needed
JR: Judy driving towards putting
in a state of UI and being able to call up a llist of
availabilities when in that state
... new operating system functionality potentially
... not a minor issue
... would like people to comment on list on this; took notes
for revising proposal, but need feedback between calls
SH: not sure if on the list
JR: discusses process with SH
AC: another complexity is direct commands associated with controls (ALT plus a selects all from menu) - when ALT cancels menu mode, will input an "a" instead of chosing item; context is paramount; when in a specific mode, rules may be different -- context and knowing where one is is the exxential need
JR: modes that are part of making
a command, larger mode (where am i when make command) -- will
put that all in
... SH's active context point also to be added
... fifteen minutes left -- continue talking about keyboard
access next week, perhaps -- review what is in document for
rest of minutes
<Jan> http://www.w3.org/TR/2008/WD-UAAG20-20080312/#principle-operable
"4.1.1 Keyboard: The user can, through keyboard input alone, navigate to and operate all of the functions included in the user interface (e.g., navigating and selecting content within views, operating the user interface "chrome", installing and configuring the user agent, and accessing documentation), except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. freeform drawing). This applies
@@The UAWG is currently working to ensure that sufficient requirements are in place regarding how keyboard shortcuts are conveyed to the user (e.g. visual indicators, documentation, etc.). Input from area experts would be welcome.@@
@@The UAWG is also currently working to ensure that the requirements properly cover interaction with video and dynamic Web content. Input from area experts would be welcome.@@
JR: 3 levels of success criteria
-- will be in level A things unless otherwise indicated
... 4.1.1 says if can do with mouse, should be able to do with
keyboard except for free-form drawing -- don't say "do same
actions" because not using mouse handles, but could still
resize window, for example
AC: that is key
SH: "at least one way of using the keyboard..."
AC: don't know what chrome means
JR: chrome is basically all parts of UA that are not rendering contents
KF: chrome and frame often used interchangablely -- UI that app devs developed is chrome, content goes into viewport
JR: piece of text on screen
rendered from content, but if right click on it, the context
menu IS chrome
... if someone wants a radio button, they state radio button
and label it -- that is kind of chrome -- rendered on user
instruction, but part of chrome; AJAX releated content is
rendered and NOT part of chrome
... reads "4.1.2 Precedence of Keystroke Processing: The
precedence of keystroke processing between the user agent
interface, user agent extensions, content keystroke operations
administered by the user agent (e.g., access keys), and
executable content (e.g., key press events in scripts, etc.) is
documented.@@NEW@@ "
... no particular order required, but documentaton of a
particular order IS required
AC: need to state much more clearly than stated now
JR: agree
"4.1.3 No Keyboard Trap: If focus can be moved to a component with the keyboard, then at least one of the following is true: @@WCAG2 concept@@
(a) standard keys: focus can be moved away from the component with the keyboard using standard navigation keys (i.e., unmodified arrow or tab keys), or
(b) documented non-standard keys: focus can be moved away from the component with non-standard keys and the user is advised of the method.
JR: if in a plug in and no key combo to escape, need to be able to discover escape method
SH: problematic -- really on borderline of UA and GL merge -- inside content that has hijacked normal navigation, how can user [droppee]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/operations/operation/ Found Scribe: Gregory_Rosmaita Found ScribeNick: oedipus WARNING: No "Present: ... " found! Possibly Present: AC Cantor GJR Gregory_Rosmaita JR Jan KF KFord Microsoft P4 SH Sean_Hayes scribeNick You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: Jim_Allan Judy_Brewer Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0000.html Got date from IRC log name: 03 Apr 2008 Guessing minutes URL: http://www.w3.org/2008/04/03-ua-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]