Minutes: User Agent telecon 25 June 2015

from http://www.w3.org/2015/06/25-ua-minutes.html

​User Agent Accessibility Guidelines Working Group Teleconference 25 Jun
2015

See also: IRC log  http://www.w3.org/2015/06/25-ua-irc
<http://www.w3.org/2015/06/25-ua-irc>
Attendees
Presentjim, jeanne, gregRegretsKimChairjim allanScribeallanj
Contents

   - Topics <http://www.w3.org/2015/06/25-ua-minutes.html#agenda>
      1. Low Vision Task force, approve draft work statement
      <http://www.w3.org/2015/06/25-ua-minutes.html#item01>
      2. low vision task force
      <http://www.w3.org/2015/06/25-ua-minutes.html#item02>
      3. Henny media player comments - see list
      <http://www.w3.org/2015/06/25-ua-minutes.html#item03>
      4. Media Player comments
      <http://www.w3.org/2015/06/25-ua-minutes.html#item04>
   - Summary of Action Items
   <http://www.w3.org/2015/06/25-ua-minutes.html#ActionSummary>

------------------------------

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

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.
 Summary of Action Items [End of minutes]​

-- 
[image: http://www.tsbvi.edu] <http://www.tsbvi.edu>Jim Allan,
Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964