AC: embedded elements with volume control (video embedded in web page with widget) - would that widget's volume control need to be adjustable

18:18:22 [oedipus]

JA: player another UA, so flash player needs to put in adjustable volume; parent UA probably unaware of embedded player functions

18:18:38 [oedipus]

KF: global volume or application volume - how deeply do we want to dig in this list?

18:19:25 [oedipus]

JB: appreciate your broaching this, kelly; one possibility is to pick 2 to discuss can then try to extrapolate from concerns arising out of 2 we discuss

18:19:29 [Zakim]

WAI_UAWG()2:00PM has been moved to &elsewhere by Ralph

18:20:32 [oedipus]

JB: one thing running through my head is question of: should this list be in some other document that is not normative and static; might be far worse - potentially asking people to conform or build software that may not be stable; dev's perspective, that is worse, but presents dilemma either way; think haven't found right approach for particular needs

18:22:26 [oedipus]

JA: might be overkill; original were somewhere else in guidelines; provide user ability to do x, y, and z; this particular one says functions addressed elsewhere in document, but have to provide direct keyboard command for function; that was original intent for these 14 items; all have specific guideline that refers to specific function; listed all in one place to say not enough to provide function but must provide keyboard command

18:22:40 [oedipus]

JA: could add keyboard requirements to the 14 individual GLs

18:23:01 [oedipus]

JB: could say "for every thing at such-and-such a level" - want to genericize

18:23:51 [oedipus]

SH: are we saying that these things should be included and should have keyboard commands or if functionality in UA, use theese keyboard commands

18:24:19 [oedipus]

JR: are these all things UA has to have with keyboard function, or have to have keyboard support if included and think is second

18:24:23 [oedipus]

JA: agree with that

18:24:52 [oedipus]

SH: integrate into other checkpoints; might be good things to offer explicitly when functionality defined

18:24:59 [Jan]

JR: AU: If the authoring tool includes any of the following functions, authors can enable key-plus-modifier-key (or single-key) access to them

18:25:57 [oedipus]

q+ to ask if can have meta-guideline "all functionalities provided by a User Agent must enable key-plus-modifier-key or single key access to them

18:26:45 [oedipus]

JB: i don't get a lot from having specific list of items - kind of direct keyboard access that i've been trying to articulate in document is more general principles

18:26:49 [oedipus]

q?

18:27:19 [oedipus]

JB: concern: list might include a lot but may also leave out a lot - want to genericize - anything that is active command needs direct keyboard support

18:27:35 [oedipus]

JB: list very fixed in time and seems different from all other GLs

18:28:14 [oedipus]

JA: dilemma - UAAG1 and UAAG2 have 13 separate GLs to say "have to offer x functionality" and this one says this functionality has to have keyboard command

oedipus, you wanted to ask if can have meta-guideline "all functionalities provided by a User Agent must enable key-plus-modifier-key or single key access to them

18:29:51 [Zakim]

WAI_UAWG()2:00PM has been moved to &elsewhere by Ralph

18:30:02 [oedipus]

AC: danger! danger!

18:31:33 [oedipus]

AC: not sure that "everything" is true - things that can be gotten to by going through menu (especially if not used often) - functions used every day need keyboard

18:32:43 [oedipus]

GJR: menus may be too onerus, a lot of chrome available by default

18:32:58 [oedipus]

JR: alot that can't be done by direct key

18:33:09 [oedipus]

JB: what is criteria for what is most important?

18:34:13 [oedipus]

KF: if have top-level features try to have direct hotkey access to features; other dev goal is "if you can do with mouse wiht one click, should be able to do at most with 5 keystrokes"

18:34:27 [oedipus]

KF: end goal is all top-level stuff key-bound

18:35:26 [oedipus]

JA: UAAG1 a lot of checkpoints about changing font size, searching within page, moving focus backwards and forwards; essential features the group thought in 1998-2002 were important - genesis of 13 GL checkpoints; ported to this list because already levelA or level AA

18:35:45 [oedipus]

JA: conformance claim can say "our UA doesn't do search" - so don't conform to that GL, but that is origin of list

18:36:43 [oedipus]

KF: example: reading this GL what was meant in 1998 was search web content (find on page/document); today, have search box that launches web search automatically - should that have direct hot key access

18:37:10 [oedipus]

KF: not just the naming of what you want, new feature added to UA now considered a must have

18:37:47 [oedipus]

JB: Jan tying to reqs i've been raising; req i've been raising was less that a specific keyboard command has to be available for everything, but findability is a parmount concern

18:38:28 [Ralph]

Ralph has left #ua

18:38:29 [oedipus]

JB: more classic - ought to be direct keyboard way to do everything, but agree with AC's point about not commonly used features

18:38:59 [oedipus]

JB: why this list? wouldn't stand up as set of requirements - is there a principle that separates them from other things

18:39:15 [oedipus]

JA: have GLs that say "you must do this";

18:39:25 [jeanne]

present + Jim, Judy, Jan, Jeanne, Alan, Simon, Kelly, Gregory

18:39:33 [oedipus]

JB: can we then say "for anything at Level A, make sure a direct keyboard command for that

18:39:49 [oedipus]

JR: used to be the case, but not requirements in document for "favorites/bookmarks"

18:39:55 [jeanne]

present+ Jim, Judy, Jan, Jeanne, Alan, Simon, Kelly, Gregory

18:40:04 [oedipus]

JA: to address Judy's comment, sounds fuzzy - more work for developer

18:40:46 [oedipus]

JB: could either enumerate in TECHS doc, or list in UAAG2 itself, but need to ensure list is updated;

18:41:26 [oedipus]

JB: concern about being static, but if principle is "these are things that are level A" if do 2.1 and need to drop and add, can just change one place in document

18:41:40 [oedipus]

q-

18:42:24 [oedipus]

JA: not going to be picked up by developers

18:42:42 [oedipus]

q?

18:43:21 [oedipus]

JB: suggest we move on from this fairly soon

18:44:30 [oedipus]

KF: in addition to list, GLs implicit - design principles wouldn't be encouraged by this; point to encourage/require "sufficient" keyboard use (as few keystrokes as possible); not setting parameters for number of key strokes -- very testable for conformance

18:44:46 [oedipus]

KF: or do we just say "you should go in this direction" and leave to notes and techniques

18:44:57 [oedipus]

KF: if Level A feature or function needs single hot key

18:45:44 [oedipus]

AC: support what Kelly said; don't want to go through P1 things; usability of keyboard; moving to address bar not P1, but needs useable keyboard shortcut; also agree that need principle as to whay here

18:45:51 [oedipus]

s/AC: support/JR: support

18:46:16 [oedipus]

AC: so important for keyboard access can't give devs an out on keyboard support; big difference between barely useable, and usable

18:46:58 [oedipus]

JB: for higher priority functions identified as A, should apply principle of "efficient keyboard support" defining number of acceptable keystrokes

18:47:47 [oedipus]

JR: proposal is: what is used on daily basis - enter URI in address bar - basic, but not P1/Level A requirement, just feature of tool; example of keyboard hotkey that isn't a P1

18:48:10 [oedipus]

JA: think should take to list - 3 people sub-committee to thrash out on list?

18:48:23 [oedipus]

JB: may want competing versions

18:48:36 [oedipus]

JB: might be critical mass that want to ditch list of specific commands

18:48:43 [oedipus]

JB: who would like to ditch list

18:48:45 [oedipus]

KF: yes

18:48:50 [oedipus]

JR: yes

18:48:53 [oedipus]

JB: yes

18:48:56 [oedipus]

SH: yes

18:48:59 [oedipus]

JS: yes

18:49:06 [oedipus]

AC: keep list

18:49:14 [oedipus]

GJR: half-and-half

18:49:32 [oedipus]

JB: Alan will be a quality control to ensure we can win him over

18:49:54 [oedipus]

JA: several points: 1) efficient keyboard use - x number of keystrokes

18:50:03 [oedipus]

JA: 2) need keystrokes for all Level A

18:50:24 [oedipus]

JA: 3) need to identify key features not explicitly addressed as keyboard accessible

18:50:42 [oedipus]

JA: still need critical mass of people - volunteers for changing list?

18:50:50 [oedipus]

zakim, choose a victim

18:50:50 [Zakim]

sorry, oedipus, I don't know what conference this is

18:51:00 [oedipus]

JR: would like to hear from Kelly

18:51:04 [oedipus]

KF: accept

18:51:33 [oedipus]

SH: would like to help, but on vacation

18:51:41 [oedipus]

JB: group will go ahead and then review

18:51:50 [oedipus]

JR: will work with Kelly on this

18:51:54 [oedipus]

AC: should sit in on this

18:52:03 [oedipus]

JB: could do on email list or have 3-way call

18:52:08 [jeanne]

s/SH: would / JS: would

18:52:11 [oedipus]

AC: on holiday for next 2 weeks

18:52:25 [oedipus]

KF: didn't do other action item (not complete, anyway)

18:52:48 [oedipus]

KF: send something to list, members can kick around, can set up a conference call via MS facilities

JA: proposal to remove configure and state "UA needs to document processing order, so user knows what to expect"

19:08:04 [oedipus]

KF: no, just drop to level 2 (AA)

19:08:14 [oedipus]

JR: that's my thought too - drop to level 2

19:09:17 [oedipus]

JB: concern: if this is something that as currently worded would be show-stopper for some implementors, and change to double A, then we are saying we are ok without working out the conflict, need and feasibility; have problem with not being able to aim for double A

19:09:32 [oedipus]

JB: rather better define user need and developer feasability

19:09:41 [oedipus]

JB: no strong case for this to be level A

19:09:50 [oedipus]

GJR: thinks this is a Level A

19:10:33 [oedipus]

JB: may need to sort issues out before assigning a level to it

19:11:50 [oedipus]

JA: additionally, this proposal came from user agent dev, commenting that current UA serves strict first - hit keystroke, trapped by script but UA has no idea key trapped until script passes on; dev said should be other way around UA handle, if can't do hand down to script - just one developer's perception

19:12:21 [oedipus]

KF: can't just focus on script - widgets, embedded objects all can interfere

19:12:42 [oedipus]

KF: can't agree with making Level A without more consultation with MS developers

19:12:48 [oedipus]

JB: may not have right wording yet

19:13:00 [oedipus]

JA: that's what i hear - configure option

19:13:26 [oedipus]

KF: today, based on what we do and is technically possible, user has a work-around - turn off scripting

19:13:37 [oedipus]

GJR: that is FAR too draconian (turning off scripts)

19:13:56 [oedipus]

JA: don't have depth to investigate - perhaps should throw to PF

19:14:10 [oedipus]

AC: as user don't want to have to turn off scripts to perform normal functions on a page

User can override all keyboard commands for user interface and recognized content with session persistence.

19:23:06 [oedipus]

JA: in glossary - content recognized by UA

19:23:40 [oedipus]

AC: what is session persistence? permanant or one-off

19:23:51 [oedipus]

JR: persistence between sessions?

19:23:54 [oedipus]

JA: think so

19:24:01 [sharper]

Is this any better?

19:24:03 [sharper]

User can override all keyboard commands used for controlling both the User Interface and recognised content.

19:24:15 [Judy]

User can override all keyboard commands for user interface and recognized content with persistence between sessions.

19:24:34 [sharper]

User can override all keyboard commands used for controlling both the User Interface and recognised content.

19:24:37 [oedipus]

JA: persistence refers to content area - site specific, can be saved for next time access site

19:25:28 [oedipus]

JB: not there yet, and dont' think will get there in next 5 minutes

19:25:39 [oedipus]

JB: Simon, yours leaves out session persistence

19:26:24 [sharper]

; and this override is maintained between sessions.

19:26:24 [oedipus]

JB: session persistence - once agree what is - need to get into right place in sentence; make sure that sentence would work without any of the stuff in the middle

19:26:29 [Judy]

User can override [...] with persistence between sessions.

19:27:00 [oedipus]

GJR: model is how UAs handle cookies - session only, always for this site, never

19:27:33 [oedipus]

JB: user can then select or configure whether want configuratgion overrides to last between sessions

19:27:35 [oedipus]

GJR: right

19:27:44 [oedipus]

JB: for UI commands and recognized content

19:27:58 [oedipus]

AC: User can configure keyboard interface of UA to ..."

19:28:13 [oedipus]

JB: user can set configurations that persist between sessions

19:28:50 [Judy]

User can set configurations that persist between sessions for keyboard commands for user interface and recognized content.

19:29:14 [Judy]

User can set configurations that persist between sessions for both keyboard commands for user interface and recognized content.

19:29:20 [Judy]

wrong

19:29:35 [Judy]

User can set configurations that persist between sessions for keyboard commands for both user interface and recognized content.

19:30:09 [Judy]

User can set configurations that persist between sessions for keyboard commands for both user interface and recognized content.

19:30:11 [Judy]

sorry

19:30:36 [oedipus]

GJR friendly ammendment: Users SHOULD have the choice of applying specific configurations for a specific site, for the duration of a particular sesion, in the same manner that a user can control cookie collection

19:31:00 [Judy]

User can [override and ...]configurations that persist between sessions for keyboard commands for both user interface and recognized content.