18:46:01 RRSAgent has joined #ua 18:46:01 logging to http://www.w3.org/2008/02/28-ua-irc 18:46:12 Zakim, this will be UAWG 18:46:13 ok, Jan; I see WAI_UAWG()1:00PM scheduled to start 46 minutes ago 18:46:20 Meeting: WAI UA 18:47:19 Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0048.html 18:47:50 jan, FYI: the second nested heading under "Status of this Document" at 18:47:50 http://www.w3.org/WAI/UA/2008/WD-UAAG20-20080220/WD-UAAG20-20080220.html 18:47:50 refers to ATAG, rather than UAAG... 18:49:26 /me re: reference to ATAG...I see one spot "Editor's Draft of ATAG 2.0"... 18:49:51 .me yeah, that's the one 18:52:26 Chair: Jim ALlan 18:54:01 Scribe: Jan 18:55:48 AllanJ has joined #ua 18:57:07 http://accessibility.linux-foundation.org/a11yweb/presentations/csun2008/slides/opena11y/index.html 18:57:16 WAI_UAWG()1:00PM has now started 18:57:23 +JimAllan 18:58:42 +??P4 18:59:17 zakim, ??P4 is really jan 18:59:17 +jan; got it 18:59:27 +[Microsoft] 18:59:51 zakim, [Microsoft] is really Kford 18:59:51 +Kford; got it 19:00:53 +Gregory_Rosmaita 19:01:33 +Judy 19:04:37 Topic: 1. Review New Editor's draft 19:04:42 KFord has joined #ua 19:05:07 GR: Bit more than half way through it... 19:05:21 GR: Only thing noticed was ATAG ref out of place 19:05:34 KF: Done once and 25% of way through again 19:07:03 JR: Jim and i met for 2 intense days of edits; produced proposed text to bring back to group -- reorganized things into 5 principles: 19:07:12 1) follow applicable standards and conventions 19:07:42 JR: follow-up principle a bit different from other WAI GL docs 19:08:19 JR: not much to say at high level -- need to go through and get consensus on structure and flow -- trying to move a public working draft; shifted things without changing sens (tried to) 19:08:43 JA: couple of issues that made our brains sweat, but that may have had to do with the time of day at which they were addressed 19:08:54 JA: KF or GJR have issues that leapt out at you? 19:09:01 JA: Any issues that jumped out? 19:09:12 KF: Nothing makes me say "oh my gosh" 19:09:12 KF: nothing that made me stop and pause on first read; second read more detailed and slower 19:09:42 GR: Flows really well 19:10:23 GR: Not done UA review of HTML5 yet... 19:10:37 GR: Easier with new structure... 19:10:44 GR: Can't promise before April 19:11:01 JA: Suggest posted new addition to list about keyboard support 19:11:35 JB: Appreciated work on it 19:11:49 JB: From TEITAC seems like this will be very complicated 19:11:59 JB: But great if we could get something into draf 19:12:13 JB: Great if could go out before or during CSUN 19:12:45 JB: Would also like to do cursory walkthrough of proposed doc 19:12:54 FYI: Keyboard Access Functional Specification, Release Candidate 2: http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-rc2.html 19:12:59 Topic: Displaying key commands 19:13:06 and http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-gta-rc2.html 19:13:27 JA: In UAAG1.0 covered by 1.1 and 11.1... 19:13:44 JA: But its a pain to hunt through when they are distributed 19:13:58 judy has joined #ua 19:14:20 http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0049.html 19:14:50 JB: Term distributed confuses the issue 19:15:07 JB: Explicitly looking for "visual" 19:15:35 JB: Some people fixated on programmatic route to these 19:16:10 JB: Realizing not a lot of orientation to needs of people with physical disabilities but sight... 19:16:40 JB: Use case....person with limited movement ...hard to move from keyboard back and forth to mouse 19:16:52 JB: Another case: head pointer, head mouse users 19:17:35 JB: Concerned that back in UAAG1 there was an option to have it distributed 19:18:08 JB: THat is basis for looking at things differently from here, TEITAC, ISO... 19:18:50 GJR: related to issue PF been wrestling with -- trying to get programmatic access not only to AT or a11y API, but to base operating system -- use OS' native renderer to play aural cues (including ACSS) and to trigger "show sounds" or "sound sentry" events, as well as getting a UA to provide a summary of X in document (where X is accesskey assignments, tabindex, number of forms, etc.) 19:18:52 KF: Scenarios are valid...can imagine even more 19:19:18 KF: Today there is feeling that accessibility=prog access=screen reader 19:19:45 JB: Real problem that some people in field couldn't picture the scenarios 19:20:12 http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0049.html 19:20:19 GJR: would like to update "how people with disabilities use the web" 19:20:28 JR: wasn't happy with what i sent, so let me explain 19:20:39 JR: idea is to split the followig 19:20:46 4.1.5 Available Keystrokes: The user can always determine available binding information in a centralized fashion (e.g., a list of bindings) or a distributed fashion (e.g., by keyboard shortcuts listed in user interface menus) for the following: @@11.1,11.2@@ 19:20:47 (a) user interface "chrome" and extensions (including any user re-mappings), and 19:20:49 (b) content keybindings that the user agent can recognize. 19:20:53 s/followig/following 19:21:24 JA: link in IRC to new one JR talking about old one 19:21:44 JR: old one restatement of UAAG1 -- explaining what is different 19:22:11 JR: example access key in HTML 19:22:49 JR: have to show user keys from 1) chrome, 2) extensions to chrome, 3) derrived from content (accesskey binding need to be shown to user) 19:23:09 JA: things might be done in something outside the DOM and UA knows nothing about them so can't make req on UA 19:23:23 JR: now, to the new stuff in the email (subj line is Re: agenda) 19:23:42 JR: split into 2 -- one for chrome and one for content 19:24:23 KF: hold on -- first one -- what are you trying to get them to do -- help file or something else? 19:24:27 JR: help file 19:24:49 JB: number of issues -- maybe should note things to discuss, hear proposal 19:25:21 JR: menu items with shortcut keys as well as shortcut keys for buttons or other interactive items would be in UA UI 19:25:52 KF: hold on -- available by default, or keyboard binding in tooltip ok? 19:26:12 JR: option user sets - most appriate for that user -- could underline on pressing alt 19:26:50 JR: shortcut keys available programmatically for all input 19:26:50 JB: relationship with 4.1.x 19:26:53 JR: content keyboard commands -- don't make sense unless content being rendered 19:27:01 JB: access keys? 19:27:07 GJR: tabindex order 19:27:08 JR: all of that 19:27:21 JR: all keyboard commands that are currently available (content sensitive) 19:27:58 JR: keyboard trap addressed -- if not easy to tab out of, user can query what are my keyboard options, would bring up list of all possible actions, one would be leave trap 19:28:00 KF: trap? 19:28:11 JR: standard navigation won't get you back into document 19:28:19 JA: old flash an example 19:29:05 JB: back to beginning of proposed rewording? 19:29:07 JA: sure 19:29:09 GR: also a problem with some CAPTCHA grabbing keyboard focus and not letting it go 19:30:17 JB: not technical issue, but interprative -- when JA and JR and i spoke about this already being coverred in UAAG 1.0 and i responded that it wasn't clear -- need to have worded as transparently as possible, so users can understand what is being described -- could we remonve chrome from the defnintion/first bit 19:30:21 JA: ok with that 19:30:36 JB: just "available shortcut keys" 19:31:09 OedipusWrecked has joined #ua 19:31:46 JB: second: notify may be confusing term -- current option C is where is most relevant, but not exactly correct --- available programmatically; on others display or inform --- notify creates consusion upfront and might bias interpretation -- want displaying visual indication without anyone having to do anything to UI 19:32:21 JA: UUAG 1 -- provide info to user about current input configurations 19:32:24 JB: front half good 19:32:30 JA: in place of "notify"? 19:32:38 JB: worth trying 19:32:54 KF: item C -- 19:32:54 JA: finish 1 first 19:32:54 KF: come back to it 19:33:29 JB: looking at it phrase by phrase -- "provide information to the user about shortcut keys" then could mention "chrome" as long as links to definition 19:33:37 JR: what info other than shortcut keys 19:36:58 KF: if I invent new UA, then need to faclitate the revealing of shortcuts to users 19:37:18 ...if you have extensibility mechanism, this must be cosidered. 19:37:33 s/cosidered/considered 19:38:36 in 4.1.5.a need centeralized listing (help file), but extensions won't be documented in base UA helpfile 19:39:08 JR: remove 'extensions' prevent word clutter. 19:39:39 JR: add conformance claim about extensions 19:40:06 oedipus has joined #ua 19:40:13 JB: indicate work for all 3 environments 19:40:15 JA: works 19:40:17 JR: any is important -- may not have shortcut keys available 19:40:19 JB: came up in TITAC -- would solve problem 19:40:21 KF: one point -- cover all the time, but need to state user agent may not know about shortcut keys added by an extensions -- UA extension mechansim has to facillitate this action 19:40:24 JA: discussions way back when, when peter was still on call working on orca, if something plugs into FF through XUL, becomes part of UA and UA is congnizant of it 19:40:27 KF: what if browser x comes out tomorrow, is a huge success, but doesn't learn or have knowledge of extension capabilities 19:40:30 KF: if information not there, can't be magically obtained -- if building UA with extensibility mechanism, this HAS TO BE CONSIDERED 19:40:34 JR: could say "conforming extensions" or say "user agent/tool plus any extensions you add onto it for purposes of conformance" 19:40:36 KF: follow-up under point A have to list all shortcut keys -- can't do that in help file if using toolbar extension, for instance -- could suck up all shortcut keys -- need to discuss 19:40:39 JR: lets take out extensions -- word clutter if add "and extensions" to everything we say -- add verbiage to conformance section (user agent + extensions) 19:40:42 JR: have to change A 19:40:44 JA: need another GL or ckeckpoint dealing specifically with extensions or modular add-ons -- stick all odd little bits into that -- don't do if don't extend or modularize 19:40:52 JR: like that idea -- good place to target 19:41:02 KF: extensions make a lot of interesting challanges 19:41:10 JA: and add a lot of functionality 19:41:27 JB: have to flag that issue prominently if going to publish as FPWD 19:41:41 JB: can we mark that and park it under continued? 19:42:09 JB: on A, issue want to raise first is that this doesn't belong first, but last in list of 3 items; might be arguments for it to be at diff priorty level than other 2 19:43:03 JB: in addition to issues of usefulness there are also technical issues as to feasibility; 2 diff kinds of interpretations and fears in developers: no definition of what a centralized listing meant (everyone had their own, mnostly idiosyncratic opinion) 19:43:14 JB: some in help menu, some on product web site 19:43:16 JA: ugh 19:43:44 JB: yes, -- also how to aggregate listings with extensions from thirdparties -- how do you document that 19:43:55 JB: one list or a reliable place for users to go 19:44:32 JB: brad hodges at AFB said what is most useful is a reliable place to go to in the help for the user agent that has a direct link to the most up-to-date aggregation of documentation 19:45:03 JB: wanted to point out that this isn't as simple as stating "listing of shortcut keys" -- also technical problems with third-party extensions, OS shortcuts, etc. 19:46:13 JB: another ascpect misunderstandings of importance -- for someone with limited or no use of hands and need visual indication in UI without having to hunt with hands, is useless except when someone is attempting to become a speed user -- for someone with cognative disaiblity (particularly learning or retention area) this is a level 1 -- even if being coached 19:46:45 JB: regardless, that is a P1 for cognative, but not satisfactory for those with limited hand movement and those useing screen readers 19:47:12 JR: if don't want to look through menus and trawl serval layers deep - how are you going to expse? 19:47:51 JB: in FF, want to use "find in this page" which has mulitple choices in it -- can have nested options and a ... and the keyboard shortcut next to primary command 19:48:03 JR: still have to go to edit menu, then... 19:48:12 JB: no, if alt-b in FF, opens bookmarks 19:48:28 JR: ok if distributed as long as path is keyboard perceptable and accessible 19:49:01 JB: yes, been saying that from the beginning; UAAG 1.0 says by item or sequential access -- sequential access breaks down in many use cases 19:49:15 JR: downArrow downArrow downArrow is sequential 19:50:14 JB: can do a lot with arrows, but when went onto mac for 6 weeks killed my hands -- only 50% keyboard shortcuts -- tried everything i could, but had to get up to speed on 10 diff apps on new OS -- simply impossible in a work sitation 19:50:33 KF: opera's behavior for ACCESSKEY press keycombo and displays all access keys 19:50:46 q+ to say true on the sequential issue, but very keying-intensive 19:50:59 KF: could press one key, and if a product is built correctly, should be able to generate a "show me everything i can do" dialog 19:51:08 JB: need to do a lot of looking through stuff 19:51:54 JB: ArrowKey navigation extremely keying intensive -- really an undue and inefficient burden -- if engineered right way, can be autogenerated and listed in menu 19:52:15 JR: depends upon one's keyboards (doOver versus hunting for key) 19:52:21 JB: on screen keybaords? 19:52:27 JR: that's where i got the concept 19:52:53 JR: KF made good point -- context sensistive listing on the fly "what can i do now" is what i tried to capture and why i divided the point 19:53:04 KF: is there a product that does what you want today? 19:53:07 JB: windows 19:53:48 JB: Looking for direct visual discoverability 19:54:00 KF: And windows is acceptable 19:55:57 JR: beyond direct Visual discoverability 19:56:30 GR: use keyboard to move with keyboard same as mouse user does 19:57:51 JR: problem with DVD, for all keys. if a user with mouse does one click, but takes three keys for keyboard user 19:58:19 JR: need to get wording right to explain clearly 19:58:49 JB: some menus have direct access, others must arrow 20:00:43 GR: see Keyboard Access Functional Specification, Release Candidate 2: http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-rc2.html 20:00:55 GR: Earl Johnson working on thias 20:01:14 Displaying key commands and http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-gta-rc2.html 20:01:43 GR: to be released before CSUN 20:03:38 JB: Is this cooked? 20:03:42 GR: Pretty much 20:03:56 GR: Meeting tomorrow ... then we need an IPR policy 20:04:43 JA: Looks like rewrite of older stuff StickyKeys etc 20:05:14 GR: Will be released as a Release Candidate 20:05:58 GR: Will bring up "visual indicator" up on call tomorrow 20:06:46 JB: Even have place to put it...display state 20:07:07 JA: THey are talking about hardware in some places 20:07:14 JA: May be ok 20:07:29 GR: Something seems to be missing from conversation 20:07:50 GR: OK here are hardware reqs, now we neeed HCI software ones 20:08:52 Action JR: Reformulate visual display of key commands proposal 20:09:41 JR: UAAG says user OS conventions. 20:10:11 if the OS does not provide something, should the UA do it anyway. 20:11:03 -jan 20:12:56 JR: just going to say... 20:12:56 have to make your own custom controls accessible 20:13:02 JR: follow platform but if you don't want to you have to do the hard work yourself 20:13:28 -Kford 20:13:29 -Judy 20:13:29 -Gregory_Rosmaita 20:15:34 rrsagent, create minutes 20:15:34 I have made the request to generate http://www.w3.org/2008/02/28-ua-minutes.html AllanJ 20:15:59 rrsagent, set logs public 20:16:59 -JimAllan 20:17:00 WAI_UAWG()1:00PM has ended 20:17:02 Attendees were JimAllan, jan, Kford, Gregory_Rosmaita, Judy 20:20:53 AllanJ has left #ua 22:00:53 Zakim has left #ua