WAI UA -- 03 Apr 2008

<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

Distinctions - Where you need indicators and were one doesn't

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]

- DRAFT -

WAI UA

03 Apr 2008

Attendees

Contents

Distinctions - Where you need indicators and were one doesn't

Summary of Action Items

Scribe.perl diagnostic output