User Agent Accessibility Guidelines Working Group Teleconference

25 Jun 2015

See also: IRC log


jim, jeanne, greg
jim allan


<trackbot> Date: 25 June 2015



<scribe> scribe: allanj

open, item 2

Low Vision Task force, approve draft work statement

low vision task force

Jim Allan will be the facilitator of the Low Vision Taskforce

close item 2

Henny media player comments - see list

Media Player comments

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 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.


<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.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/06/25 18:44:10 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]