17:48:39 RRSAgent has joined #ua 17:48:39 logging to http://www.w3.org/2014/11/06-ua-irc 17:48:41 RRSAgent, make logs public 17:48:41 Zakim has joined #ua 17:48:43 Zakim, this will be WAI_UAWG 17:48:43 ok, trackbot; I see WAI_UAWG()1:00PM scheduled to start in 12 minutes 17:48:44 Meeting: User Agent Accessibility Guidelines Working Group Teleconference 17:48:44 Date: 06 November 2014 17:48:53 rrsagent, set logs public 17:50:05 chair: jimAllan, KellyFord 17:50:13 Agenda+ Action items 1037 - 1053 17:50:14 Agenda+ CSUN activity (test browsers) 17:50:16 Agenda+ comments 17:59:58 WAI_UAWG()1:00PM has now started 18:00:07 +Jim_Allan 18:00:15 +Eric 18:00:55 +Jeanne 18:01:23 KimPatch has joined #ua 18:01:42 +Kim_Patch 18:01:43 Eric has joined #ua 18:03:17 Greg has joined #ua 18:03:39 Jan has joined #ua 18:03:39 +Greg_Lowney 18:04:00 zakim, code? 18:04:00 the conference code is 82941 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Jan 18:04:20 +[IPcaller] 18:05:31 zakim, [IPcaller] is really Jan 18:05:31 +Jan; got it 18:06:00 scribe, allanj 18:06:08 scribe: allanj 18:06:52 agenda? 18:08:43 topic: tpac wrap-up 18:09:50 http://w3c.github.io/UAAG/UAAG20-Reference/ 18:10:04 jr: web-based user agents - not popular. js and jr reviewed UAAG to see who would implement 18:10:25 Jan's email -> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0049.html 18:10:25 ... http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0049.html 18:11:38 ... most of SCs are pass through and not a worry. there are a few that need to be looked at. these could be placed in a separate section of the document 18:12:42 jr: SC - meet WCAG with some extra bits might help. worried about web-based holding UAAG back 18:13:36 gl: its a matter of perception. and rewrite to make the what the actual requirements are. worried about splitting the document. 18:14:30 jr: what above wcag is necessary for web=based UA, then link into document 18:15:03 js: perhaps non=normative, non-scary 18:16:43 jr: is there anything in UAAG that is separate and unique that is not done by base browser, or not already a WCAG document, what doesn't apply...what's left 18:17:00 jr: don't want to cover the entire internet. 18:18:03 eh: what is covered by this (web applications) 18:18:32 jr: reference document, but plump it up a bit to make it more understandable 18:19:12 eh: user has control vs app having control 18:19:35 gl: developer of app is also developer of content 18:21:08 eh: what is difference between an os based UA and and web-base tool. 18:22:14 ... good to have a rationale on why they are separate, and differences between browser types. 18:23:34 https://www.youtube.com/watch?v=cZiSPsaZ_Dc 18:23:47 +1 to its coolness 18:24:01 js: symposium was fun...saw an app with 3d camera and you can play a xylophone without touching a screen, knows where your head is in space in relation to the keys and you can virtually play the instrument 18:24:52 js: KP had a chat with Apple folks about speech interface issues. it is being taken up by ATAG 18:25:33 js: many groups reaching out to accessibility. they have non WAI accessibility folks in their groups 18:26:16 jr: talked with the DPUB group, and we reinforced their accessibility directions. 18:28:22 zakim, agenda: 18:28:22 I don't understand 'agenda:', allanj 18:28:27 zakim, agenda? 18:28:27 I see 3 items remaining on the agenda: 18:28:28 1. Action items 1037 - 1053 [from allanj] 18:28:28 2. CSUN activity (test browsers) [from allanj] 18:28:28 3. comments [from allanj] 18:28:36 Action item URL? 18:28:36 Error finding 'item'. You can review and register nicknames at . 18:28:59 http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/ all recent action items in email 18:29:08 topic: CSUN 18:30:16 js: get a room and food at CSUN (end) have a day of testing specific SC, OS, browser, at, etc. 18:30:39 kp: +1 18:31:13 http://www.w3.org/WAI/UA/tracker/ 18:31:28 js: need help, need to get the word out in december CSUN newsletter 18:31:51 js: we could also meet at CSUN 18:32:35 kp: not sure how practical, but a good idea. 18:33:12 js: needs to be focused and organized tightly. 18:34:09 gl: we should be clear what the goals are...testing and awareness of UAAG 18:35:14 js: mostly promoting UAAG. give feedback to the browsers, filing a bug 18:36:05 gl: longer list of benefits...finding different browsers, mobile or desktop, extensions, and other goodies 18:36:16 s/it is being taken up by ATAG/it is being taken up by WebApps 18:36:32 gl: if after CSUN, travel budgets, fewer people. 18:37:13 ja: during csun, a couple of hours. 18:37:53 js: CSUN negotiation for rooms. 18:38:04 Topic: Comments 18:38:11 http://jspellman.github.io/UAAG-LC-Comment/ 18:40:11 topic: MS01 def of UA 18:40:25 jr is working on a new proposal for this 18:41:20 js: review the comments on Web apps and work in to proposal 18:41:43 topic: MS05 distinction for content, browser, AT 18:43:07 jr: in Reference Document - Implemented In section for each SC. 18:45:00 RESOLUTION: MS05 done, jim to write cs about Reference document - implement in section, after web-based solved 18:45:50 js: also added @@core and @@techy for items that are core features and those for super users 18:46:09 gl: will something like this remain in the final document. 18:46:33 jr: user facing features, A vs AA, or ??? 18:47:01 js: more that it should be in the document or not 18:47:44 kp: if it is implemented well it is easy for users (even if it is technical). or if it is shareable will be easier for users to use 18:48:33 jr: agree...balance with what is really important, what do we want the developers to spend time on. 18:49:28 gl: do a better job in the intent, to explain what would be useful. easy way for users to use stylesheets built by experts. 18:49:59 ... some user agent only allows one user stylesheet, so no cascade. 18:50:34 ... add What is Reccommended in the intent to flesh out what is useful and how used by the user 18:50:42 jr: good idea. 18:52:00 topic: MS06 setting levels A, AA, AAA 18:52:05 http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0002.html 18:56:23 Last Call Comment Disposition -> http://jspellman.github.io/UAAG-LC-Comment/LCcomments.html 18:56:33 eh: definition of web-based user agent, seems circular. user agent with Ui based on a web technology. 18:56:40 jr: explains it. 18:57:28 ... reason for new section to not scare people 18:57:44 micorsoft a, b, c, d for A, AA, AAA 18:57:48 a) interact with web content that meets WCAG 2.0, and 18:57:49 b) facilitate programmatic access of the content and its user interface to and from AT, and 18:57:51 c) follow the accessibility settings from the OS, and 18:57:52 d) provide an user interface that is generally accessible, such as enabling keyboard control on its own features when operating on an environment where keyboard control is available, and 18:57:54 e) nothing more 18:58:36 so A SC should meet the above 18:58:38 and 18:58:41 Level AA should consist of success criteria that aid users in case of common content failures and predictable solutions are available. 18:58:42 Level AAA should consist of success criteria that aid users in case of content failures and where implementable solutions are available. 19:00:48 I think that Microsoft's "A" criterion, saying that user agents should only need to provide an accessible experience when viewing well designed content that fully meets all of WCAG, is like saying cars should be designed to be safe as long as everyone drives so carefully that the cars never hit anything. 19:06:02 Topic: MS08 stylesheets 19:06:15 comment: Realistic expectation of the end users We still do not agree that user stylesheets are a reasonable end user feature. User Stylesheets are too technical to be an end user feature. They make sense only as a programmatic interface available to AT developers. We would be satisfied if the references to "users can" were changed to "AT can" or "developers can". 19:07:33 gl: didn't we demolish this last comment round 19:08:21 jr: what if we move 1.7.1, 1.7.2 to AA, 19:09:01 ... so a mobile browser did all of 1.4 but not 1.7 do we want to fail the browser. 19:10:59 js: Stylish app, easy to use. use it as a way for 1.7 to be implemented easily 19:12:05 js: user stylesheets don't exist on mobile so moving 1.7.1, 1.7.2 to AA, leave 1.7.3 as A 19:14:57 PROPOSAL: 1.7.1 and 1.7.2 to AA 19:15:10 objections? 19:15:26 I'm not thrilled with reducing these in priority, but I'll accept the will of the group. 19:15:34 js: microsoft wants AAA 19:16:09 jr: we have implementations, so not too difficult. (stylish) 19:17:16 kp: not thrilled but OK 19:18:00 RESOUTION: move 1.7.1 and 1.7.2 to AA, MS08 done 19:18:47 gl: explain why... for the disposition document 19:19:31 js: writing them as we go along in the disposition docuemtns 19:19:54 topic: SB01 1.74 save stylesheets 19:20:10 Regarding SB01 (not sure if 1.7.4 Save Copies of Stylesheets is really needed), yes the new additional explanation is good, especially the point about making sure the stylesheet is pretty-printed (which is not usually possible if you simply inspect the page's source code and fetch the stylesheet URLs from it, which is what I'm in the habit of doing). 19:20:12 Highly complex stylesheets can still be difficult to make sense of though, even when pretty-printed. Some current browsers have "inspect this element" functionality which can help here - they tell you exactly which CSS rules were applied to the element you pointed at, and, as a bonus, include any overrides that were generated by a script rather than a CSS file. 19:20:13 One addition that might be useful is in the case when a page's styles come from not just one CSS file but quite a lot of them (I've seen sites with over 20 CSS files all loaded from the same page, and no they weren't alternates, they were ALL applied) - the user might choose whether to save them individually or to merge. But I wouldn't worry too much about a browser lacking that addition. 19:20:15 And one reason why it might be a good idea to have this function from inside the browser (rather than relying on command-line tools like "wget") is the page might be available only from behind a "login" page, and it's often quite a chore to set up wget with the correct authentication cookies just to get a copy of all the CSS files. (True, some servers will serve the CSS files even without... 19:20:16 ...correct authentication, but that's not always the case.) 19:23:31 jr: css is difficult to make sense of, in the intent make clear that user will use a tool to make sense of, edit, etc the css. all we want is for the css to be saveable 19:24:33 RESOLUTION: added paraphrase of statement above to intent of 1.7.4, SB01 done 19:26:52 gl: add to the intent, "sometimes a page might have a number (10+) of css applied. ideally the UA would allow the user to save these individually or merged. 19:27:05 Topic: SB03 1.8.11 top level viewport focus 19:27:20 comment: (1.8.11 Allow Top-Level Viewport Open on Request), I believe the problem I mentioned is caused by scripts intercepting the "mousedown" or "mouseup" event (rather than the "click" event), and therefore intercepting middle-clicks and (unintentionally?) causing these to perform some action on the page instead of opening the link in a new window. One solution might be to allow the user... 19:27:21 ...to specify which mouse buttons are allowed to generate Javascript events. For example, if the user says "do not allow any mouse buttons to generate Javascript events" then no click or mousedown / mouseup events are generated and clicks always perform the default browser behaviour; if the user says "allow only the left mouse button to generate Javascript events" then the other buttons will... 19:27:23 ...not; if the user says "allow left and right but not middle" then pages can override context menus but cannot override whatever the middle button is bound to (e.g. "open in new tab"). I'm not sure how exactly these options should be described to the user, or where to put them (probably in an "advanced" section somewhere), but being able to tell the browser not to generate JS events when I... 19:27:24 ...middle-click would stop a lot of annoying sites from overriding this "open link in new tab" shortcut. (Yes, there will be times when the site is so script-driven that "open in new tab" can't work anyway, but in these cases the user would find out soon enough; I find in most cases "open in new tab" certainly CAN work - and DOES work when you bring up the context menu and select it from... 19:27:26 ...that - but the site simply prevents middle-click from doing that job.) 19:28:44 rrsagent, make minutes 19:28:44 I have made the request to generate http://www.w3.org/2014/11/06-ua-minutes.html jeanne 19:29:01 rrsagent, make logs public 19:30:00 gl: sounds like a request for a new SC, to prevent various mouse buttons from scripting events. 19:30:21 It seems like he's saying we need a new SC where the user can restrict which mouse buttons' behaviors can be customized by scripts. 19:30:37 jr: seems to be saying that. but the SC is only concerned about viewports getting focus. 19:33:17 gl: comment seems not to be about this SC. 19:33:57 kp: this is very specific. there are probably lots of things like this we could write SCs about. 19:34:19 jr: this may be relevant. 19:35:43 -Jan 19:35:44 -Kim_Patch 19:35:47 -Greg_Lowney 19:35:50 -Eric 19:36:08 gl: SC to prevent scripting from opening new windows... 19:36:14 rrsagent, make minutes 19:36:14 I have made the request to generate http://www.w3.org/2014/11/06-ua-minutes.html allanj 19:36:23 zakim, please part 19:36:23 leaving. As of this point the attendees were Jim_Allan, Eric, Jeanne, Kim_Patch, Greg_Lowney, Jan 19:36:23 Zakim has left #ua 19:37:38 rrsagent, make minutes 19:37:38 I have made the request to generate http://www.w3.org/2014/11/06-ua-minutes.html allanj 19:38:04 rrsagent, please part 19:38:04 I see no action items