16:50:32 RRSAgent has joined #ua 16:50:32 logging to http://www.w3.org/2015/06/25-ua-irc 16:50:34 RRSAgent, make logs public 16:50:34 Zakim has joined #ua 16:50:36 Zakim, this will be WAI_UAWG 16:50:36 ok, trackbot; I see WAI_UAWG()1:00PM scheduled to start in 10 minutes 16:50:37 Meeting: User Agent Accessibility Guidelines Working Group Teleconference 16:50:37 Date: 25 June 2015 16:50:48 rrsagent, set logs public 16:51:13 Agenda+ Use Cases - Accessible by Default. 16:51:14 http://www.w3.org/WAI/UA/work/wiki/Use_Cases_for_UAAG_Applicability 16:51:16 Agenda+ Low Vision Task force, approve draft work statement 16:51:17 http://www.w3.org/WAI/GL/low-vision-a11y-tf/work-statement.php 16:51:19 Agenda+ Henny media player comments - see list 17:03:26 Greg has joined #ua 17:04:43 scribe: allanj 17:04:49 regrets: Kim 17:05:04 agenda? 17:05:51 open, item 2 17:06:01 zakim, open item 2 17:06:01 agendum 2. "Low Vision Task force, approve draft work statement" taken up [from allanj] 17:06:24 topic: low vision task force 17:07:18 jeanne has joined #ua 17:07:32 Jim Allan will be the facilitator of the Low Vision Taskforce 17:08:46 close item 2 17:10:14 zakim, take up item 3 17:10:14 agendum 3. "Henny media player comments - see list" taken up [from allanj] 17:10:28 topic: Media Player comments 17:20:25 from Henny Swan - went through all UAAG for application to media players 17:21:15 user style sheets 1.7 - if you skin a media player for folks with cognitive issues 17:21:55 js: but not at level A, perhaps not apply, but reasonable to add to examples 17:22:54 gl: why does it not apply to media player but does apply to chrome 17:23:13 js: author vs user styling 17:25:20 gl: caption styling? 17:27:33 js: need to fix in 1.7 all start with "if user XXX" except 1.7.4 no if clause 17:29:20 If a media player supports a format that includes style sheets (e.g. HTML) but entirely ignores the style sheets, then the current wording would allow them to NOT provide UI to save style sheets referenced in the HTML. 17:32:46 js: 2.1.6 keyboard shortcuts, henny though this was a nightmare, screenreaders take all of the keys 17:34:01 ... this SC is not for screenreader users. it is for keyboard users, perhaps sr users turn off keyboard shortcuts 17:34:41 If an accessibility aid grabs hotkeys before the application sees them, then there's no need to turn off hotkeys in the browser, it's just that the browser will never see them. That's why guidelines say that hotkeys should not be the only keyboard mechanism of doing an action. 17:35:11 If the browser grabs hotkeys and prevents accessibility aids from seeing them, then you need the ability to turn them off in the browser so that they're passed on. 17:35:29 ja: easy way to stop JAWS keyboard shortcuts make the media player have aria-role=application 17:38:03 ja: third party players, plugins are different from html5 mediaplayer 17:38:38 js: perhaps add examples to 2.1.6. 17:39:33 gl: efficient keyboard access for the average user. can't worry about 3rd party software. add a note to that effect. 17:41:41 Henny is building a checklist for mediaplayers for UAAG 17:42:47 js: 3.3.1 and 2.1.4 overlap? 17:42:56 2.1.4 Separate Selection from Activation: 17:42:56 The user can specify that focus and selection can be moved without causing further changes in focus, selection, or the state of controls, by either the user agent or author-supplied content. (Level A) 17:43:20 3.3.1 Avoid Unpredictable Focus: 17:43:20 The user can prevent focus changes that are not a result of explicit user request. ( 17:44:36 2.1.4 is about when the user navigates (moves the keyboard focus), not causing anything to automatically activate as a side effect (e.g. when you use arrow keys to move to a radio button and it gets selected). 17:44:58 By contrast, 3.3.1 is about not having the focus move without the user's permission. 17:45:11 So one's about when you move focus, the other is not having it move on its own. 17:45:59 3.3.1 is about, for example, when the browser suddenly pops up a message box, or when the user types the third digit into a text field and suddenly the browser moves the focus to the next field. 17:48:25 For any use case, if it happens when the user explicitly moves the keyboard focus, it's covered by 2.1.4. If it's about anything else, it's 3.3.1. 17:49:31 Intent of Success Criterion 2.1.4: 17:49:33 People do not expect side effects when moving the keyboard focus regardless of whether the side effect is caused by the user agent or author content. If users fail to notice side effects, they could end up doing something disastrous. This is especially likely for users of assistive technology who cannot see changes happening elsewhere on the screen. Users may also find it confusing or... 17:49:34 ...disorienting if the effect causes unexpected focus movement or changes in context. If the user agent does implement side effects to keyboard navigation, it is recommended that it provide a user preference setting to disable them. However, in some cases it may be more appropriate to provide a separate navigation mechanism that avoids side effects, such as allowing the user to hold down the... 17:49:36 ...Ctrl key while navigating to avoid changing selection or choice. Note: It may not be possible for the user agent to detect or prevent side effects implemented by scripts in the content, but the user agent is required to prevent side effects that are under its control. 17:50:06 2.1.4 is about when the user TRIES to navigate, 3.3.1 is about when the browser tries to navigate for them. 17:50:19 Intent of Success Criterion 3.3.1: 17:50:20 Users need to know that navigation in a web page is going to start in a predictable location and move in a predictable fashion. If a page moves the initial focus to somewhere other than the beginning of the page, the user can skip over content without realizing it. If the focus moves and remains unnoticed, users can make unintentional changes, such as entering data in an incorrect field.... 17:50:22 ...Focus changes can cause a window to scroll unexpectedly, confusing users. This is particularly problematic for users who can only see a small portion of the document, because they must use more effort to determine where the cursor has moved. Such users also are more likely to continue typing, not immediately realizing that the context has changed. Users who find navigation time consuming,... 17:50:23 ...tiring, or painful (including those using screen readers or with impaired dexterity) can also need more steps to return to the area where they want to work. It can improve accessibility for some users on some pages to have the page set focus to specific links or fields when the page loads, but this can be detrimental for other users, and therefore users need to control this behavior. 17:52:20 Things might be confused by the last clause, which appears to be ambiguous as to whether it modifies "The user can specify that focus and selection can be moved" or "further changes in focus, selection, or the state of controls". 17:52:41 It's supposed to modify the second, not the first. 17:52:44 3.3.1 Avoid Unpredictable Focus - more information on unexpected changes initiated by the user agent. 17:54:58 in Reference for 2.1.4 add 3.3.1 Avoid Unpredictable Focus - more information on unexpected changes initiated by the user agent. 17:55:06 Thus 2.1.4 could be clarified as "The user can specify that focus and selection can be moved without the user agent or author-supplied content further changing focus, selection, or the state of controls." 17:56:12 That is, it's *NOT* supposed to equate to "The user can specify that focus and selection can be moved *by either the user agent or author-supplied content* without causing further changes in focus, selection, or the state of controls." 17:59:00 The idea was that we'd reorder the clauses in 2.1.4 to clarify it, and more clearly differentiate it from 3.3.1. 17:59:29 js: 2.1.4 and 3.3.1 have been cross referenced 17:59:37 5.1.5 18:00:13 5.1.5 Allow Content Elements to be Rendered in Alternative Viewers: The user can select content elements and have them rendered in alternative viewers. (Level AA) 18:00:34 js: henny huge concern about DRM 18:03:47 ja: perhaps some clause to exempt media with DRM 18:04:12 I don't think it's the browser's responsibility to not let the user get an address that can be passed or pasted into another application. Isn't it the responsibility of the streaming service or the content developer to make the data unplayable in other clients? We are talking about information that's encoded in the source ("elements"), so if the source is viewable, then addresses are... 18:04:13 ...available for reuse. 18:05:28 Things like data streams going between the Silverlight player and the server are not elements, and thus are not relevant to this SC. 18:10:35 scenario: some standard for jpg with drm that only allows display on screen, but not download 18:11:22 is it the browsers responsibility to block the source so you can't download the image 18:16:22 It seems reasonable to conclude that the Silverllght plug-in is a web-based UA that doesn't meet AA because it doesn't let the user use an alternative renderer (e.g. one that supported better captions or enhanced contrast). 18:16:43 s/Siverllght/Silverlight/ 18:18:40 I'm just using Silverlight as an example, of course; this would apply to any plug-in media player that supports DRM. 18:22:27 If HTML5 video is rendered natively by the browser, and supports DRM, and the video is essentially an element, then the browser should allow the user to launch an alternative renderer, which may well support DRM properly and thus not violate any IP restrictions. 18:22:47 If the alternative player doesn't handle the DRM, it should not be able to play the video. 18:23:53 Presumably whatever the browser is passing to the alternate renderer is already available to any user agent rendering the page. 18:24:06 http://techblog.netflix.com/2013/04/html5-video-at-netflix.html 18:25:30 It is also possible that a user agent could report its status as meeting Level AA except when rendering DRM content, in which case it only meets Level A. 18:27:37 js: is it possible to pass the drm along with the source content to a different player in the browser 18:29:21 gl: configure browser to open content with drm in a different player 18:30:01 We would expect the user to be able to configure their browser to say "play HTML5 video using this alternate plug-in" in order to get enhanced contrast, better captions, etc. If the renderer doesn't properly support DRM it might be unable to render some videos. 18:32:42 rrsagent, make minutes 18:32:42 I have made the request to generate http://www.w3.org/2015/06/25-ua-minutes.html allanj 18:36:52 zakim, please part 18:36:52 Zakim has left #ua 18:43:33 rrsagent, make minutes 18:43:33 I have made the request to generate http://www.w3.org/2015/06/25-ua-minutes.html allanj 18:43:53 present: jim, jeanne, greg 18:44:01 chair: jim allan 18:44:05 rrsagent, make minutes 18:44:05 I have made the request to generate http://www.w3.org/2015/06/25-ua-minutes.html allanj