See also: IRC log
<trackbot> Date: 25 June 2015
http://www.w3.org/WAI/UA/work/wiki/Use_Cases_for_UAAG_Applicability
http://www.w3.org/WAI/GL/low-vision-a11y-tf/work-statement.php
<scribe> scribe: allanj
open, item 2
Jim Allan will be the facilitator of the Low Vision Taskforce
close item 2
from Henny Swan - went through all UAAG for application to media players
user style sheets 1.7 - if you skin a media player for folks with cognitive issues
js: but not at level A, perhaps not apply, but reasonable to add to examples
gl: why does it not apply to media player but does apply to chrome
js: author vs user styling
gl: caption styling?
js: need to fix in 1.7 all start with "if user XXX" except 1.7.4 no if clause
<Greg> 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.
js: 2.1.6 keyboard shortcuts,
henny though this was a nightmare, screenreaders take all of
the keys
... this SC is not for screenreader users. it is for keyboard
users, perhaps sr users turn off keyboard shortcuts
<Greg> 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.
<Greg> 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.
ja: easy way to stop JAWS
keyboard shortcuts make the media player have
aria-role=application
... third party players, plugins are different from html5
mediaplayer
js: perhaps add examples to 2.1.6.
gl: efficient keyboard access for the average user. can't worry about 3rd party software. add a note to that effect.
Henny is building a checklist for mediaplayers for UAAG
js: 3.3.1 and 2.1.4 overlap?
<jeanne> 2.1.4 Separate Selection from Activation:
<jeanne> 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)
<jeanne> 3.3.1 Avoid Unpredictable Focus:
<jeanne> The user can prevent focus changes that are not a result of explicit user request. (
<Greg> 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).
<Greg> By contrast, 3.3.1 is about not having the focus move without the user's permission.
<Greg> So one's about when you move focus, the other is not having it move on its own.
<Greg> 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.
<Greg> 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.
Intent of Success Criterion 2.1.4:
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...
scribe: 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...
... 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.
<Greg> 2.1.4 is about when the user TRIES to navigate, 3.3.1 is about when the browser tries to navigate for them.
Intent of Success Criterion 3.3.1:
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....
scribe: 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,...
... 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.
<Greg> 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".
<Greg> It's supposed to modify the second, not the first.
<jeanne> 3.3.1 Avoid Unpredictable Focus - more information on unexpected changes initiated by the user agent.
in Reference for 2.1.4 add 3.3.1 Avoid Unpredictable Focus - more information on unexpected changes initiated by the user agent.
<Greg> 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."
<Greg> 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."
<Greg> 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.
js: 2.1.4 and 3.3.1 have been cross referenced
5.1.5
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)
js: henny huge concern about DRM
ja: perhaps some clause to exempt media with DRM
<Greg> 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...
<Greg> ...available for reuse.
<Greg> Things like data streams going between the Silverlight player and the server are not elements, and thus are not relevant to this SC.
scenario: some standard for jpg with drm that only allows display on screen, but not download
is it the browsers responsibility to block the source so you can't download the image
<Greg> 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).
<Greg> s/Siverllght/Silverlight/
<Greg> I'm just using Silverlight as an example, of course; this would apply to any plug-in media player that supports DRM.
<Greg> 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.
<Greg> If the alternative player doesn't handle the DRM, it should not be able to play the video.
<Greg> Presumably whatever the browser is passing to the alternate renderer is already available to any user agent rendering the page.
http://techblog.netflix.com/2013/04/html5-video-at-netflix.html
<Greg> 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.
js: is it possible to pass the drm along with the source content to a different player in the browser
gl: configure browser to open content with drm in a different player
<Greg> 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.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/Siverllght/Silverlight/ Found Scribe: allanj Inferring ScribeNick: allanj Present: jim jeanne greg Regrets: Kim Found Date: 25 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/25-ua-minutes.html People with action items:[End of scribe.perl diagnostic output]