Minutes for User Agent Teleconference for 3 April 2008

(NOTE: Our scribe was bumped off the call a couple times)

Minutes:
http://www.w3.org/2008/04/03-ua-minutes.html

Action Items:
- Non officially, but JR has much to do and the group agrees to start 
sending more comments to the list

Full Text:

<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]





Jan Richards wrote:
> 
> User Agent Teleconference for 3 April 2008
> ------------------------------------------------------------
> Chair: Jim Allan
> Date: Thursday, 3 April 2008
> Time: 2:00-3:00 pm Boston Local Time, USA (19:00-20:00 UTC/GMT)
> Call-in: Zakim bridge at: +1-617-761-6200, code 82941# for UK use
> 44-117-370-6152
> IRC: sever: irc.w3.org, port: 6665, channel: #ua.
> -------------------------------------------------------------
> 
> Regrets: Jim Allan, Judy Brewer
> 
> Agenda:
> 
> 0. Regrets, agenda requests, or comments to the list
> 
> 1. Continue Keyboard Access discussion:
> 
> Current text (see 4.1):
> http://www.w3.org/TR/2008/WD-UAAG20-20080312/#principle-operable
>     
> JR and JA attempts at requirements that include visual indicators:
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0052.html
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0053.html
> 
> JR's attempt at definition of "Keyboard Commands":
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0078.html
> 

-- 
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 Thursday, 3 April 2008 19:05:26 UTC