[media] topics for discussion with the larger group

Hi all,

Sean and I have discussed our topics and I have extracted the
following list of issues to return to the larger group for discussion.

0. General Point

Sean pointed out that the document needs a Glossary of Terms.

=======

1. Captioning Section

Feedback was provided at:
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq7
for the text at:
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Captioning

Discussion thread between Sean and I starts at
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0198.html

The following need to be discussed in the larger group:


(1) Philip's feedback on positioning

(CC-5) Support positioning in all parts of the screen.

Philip's issue: Is this a requirement for pixel-perfect positioning,
or relative positioning? Must it be possible to give a bounding box
for the text, or is it enough to say where it starts?

Sean:
CC-5 is for positioning of regions of text, e.g. to disambiguate
multiple speakers or to avoid some information in the underlying
media. Therefore the min requirement is a bounding box (with an
optional background) into which text is flowed, and that probably
needs to be pixel aligned. The absolute position of text within the
region is less critical, although it is important to be able to avoid
bad word-breaks and have adequate white space around letters and so
on.

Silvia:
I further think with "all parts of the screen" we mean either the
bounding box of the video or a randomly provided bounding box on the
web page into which the caption cues are rendered. I think by default
the caption format should provide a min-width/min-height for its
bounding box, which typically is calculated from the bottom of the
video box, but can be placed elsewhere by the Web page, with the Web
page being able to make that box larger and scale the text relatively,
too. The positions inside the box should IMHO be into regions, such as
top, right, bottom, left, center.

ISSUE: What are the positioning and size requirements for captions on screen?

(2)
I don't think there are any other issues to discuss on captions, but
there are changes to be made according to the discussion between Sean
and myself.

========

2. Extended Captions Section

Feedback was provided at:
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Extended_Captioning
for the text at:
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq8

Discussion thread between Sean and I starts at
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0215.html

The following need to be discussed in the larger group:


(1) Philip's feedback on activation mechanisms

(ECC-2) Support hyperlinks and other activation mechanisms for
supplementary data for (sections of) caption text.

Philip: I would like to see links, but "other activation mechanisms"
is again much too vague. What are the actual requirements and use
cases?

Silvia: improve ECC-2 by replacing it with "These enrichments may be
provided as additional timed text tracks, or inline in the captions as
comments, or as hyperlinks on the terms that are being described
further.

Sean: Hyperlinks is still vague, since it could have multiple
meanings. The other parts seem fine. We need to flesh out exactly what
is required by 'linking' in the larger group since this could go well
beyond anything that has been deployed to date.

ISSUE: What do we mean by "linking"?


(2) Eric's feedback on overlapping captions

(ECC-4) Support captions that may be longer than the space to the next
caption and thus provide overlapping caption cues - in this case, a
feature should be provided to decide if overlap is ok or should be cut
or the media resource be paused while the caption is displayed.

Eric: How does this work? Who decides if "overlap is OK ..."

Silvia: If an author provides extended captions, then overlap has to
be expected to play back those captions with the media resource. A
user could always overrule the default behaviour, i.e. decide to
ignore caption extensions, or control them better with from keyboard,
etc.

Sean: Not necessarily for a very fast reader. So again I think this
needs more thought.

ISSUE: Who decides which overlap is ok?


(3) Richard's feedback on smaller font

(ECC-4) Support captions that may be longer than the space to the next
caption and thus provide overlapping caption cues - in this case, a
feature should be provided to decide if overlap is ok or should be cut
or the media resource be paused while the caption is displayed.

Richard: Regarding ECC-4 what about providing a feature to configure
wrapping text with smaller fonts? This seems better than cutting off
the text.

Silvia: it still needs to remain readable, so smaller font is probably
not a good idea.

Sean: It should be up to the user to decide what is OK; so defining a
smaller font is a possibility, although I agree maybe not universally
desirable.

Silvia: I think there may be a misunderstanding about what this
requirement is referring to. I do not think this requirement refers to
the lack of physical space
to display the caption text.

IMO, the idea of ECC-4 is that captions may be provided for a longer
time than is available to them (from the media resource timing).
Giving them the time they need is an alternative to shortening their
text. Thus, the problem is that the text is too long for the time
period to read fully and the caption will be provided longer and
overlap with the next one. This is possible, because the UA can pause
for the time that the caption cue needs before moving the media
resource and the
caption on to the next. Thus, making the font smaller will not have
any effect on the readability of the caption cue.

ISSUE: What did ECC-4 refer to?


(4) Sean's feedback on what extended captions mean

(ECC-2) Support hyperlinks and other activation mechanisms for
supplementary data for (sections of) caption text.
(ECC-4) Support captions that may be longer than the space to the next
caption and thus provide overlapping caption cues - in this case, a
feature should be provided to decide if overlap is ok or should be cut
or the media resource be paused while the caption is displayed.

Sean:
ECC 2 - split into two requirements, one for additional information
that can be displayed in the same time as a caption (Ruby for example
could be considered this kind of information); and another for
information which is presented independantly outside the timeline of
the media.

ECC-4 - needs to be distinguished from the normal caption case of two
speech acts that overlap in time (e.g. an interruption).

Also the required display time of extended text information is
dependant on the users reading speed. user should have a means to
control the display time and size so that if they can keep up they
avoid pausing the video

Silvia: are overlapping captions necessary for the "normal case"?

Sean: I think it is important to distinguish between caption
annotations which won't imply changing the underlying timeline of the
media, and those that will. Since the latter requires a lot more
mechanics to support and may not be acceptable, while the former
should be.

Silvia: That may be the case. Maybe there are two types of extended
captions that we are dealing with, which may also relate to your issue
of what to call them.

Sean: Yes, there are overlapping captions, though obviously not all
the time; but this is a common occurrence in real media.

Silvia: I see - you are there talking about e.g. conversation where
captions overlap in time, but not in space. Indeed, there needs to be
a distinction. It sounds like it will be worth a discussion to
identify how to distinguish between the cases and what groups of cases
we have and what we can call them.

ISSUE: are we subsuming too many different types of "extended
captions" under that term? Should we separate out different types and
what should they be?


========

3. Keyboard Access to Interactive Controls Section

Feedback was provided at:
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Keyboard_Access_to_interactive_controls_.2F_menus
for the text at:
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq12

Discussion thread between Sean and I starts at
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0232.html

The following needs to be discussed in the larger group:


(1) Philip & Eric's feedback on the section:

(KA-1) Support operation of all functionality via the keyboard using
sequential or direct keyboard commands that do not require specific
timings for individual keystrokes, except where the underlying
function requires input that depends on the path of the user's
movement and not just the endpoints (e.g., free hand drawing). This
does not forbid and should not discourage providing mouse input or
other input methods in addition to keyboard operation.

Philip's feedback:
The requirement is sound, but the introductory text is strange.

"If the author chose to create a new interface using scripting, that
interface MUST map to the native controls in the user agent, so the
user can ignore author controls and use accessible native controls."

Scripted controls do not "map" to native controls, rather they both
control ("map to") the same underlying interface. However, this is
completely unrelated to the possibility of ignoring author controls. I
suggest removing the section completely and adding a requirement that
it should be possible to enable native controls regardless of the
author preference (stated through the controls attribute on <video>)

Eric's feedback:
I don't understand "If the author chose to create a new interface
using scripting, that interface MUST map to the native controls in the
user agent". Controls implemented with scripting should *use* the same
interface to control a media file, but they do not use the native
controls. Like Philip, I suggest we add a requirement that it must be
possible to enable native controls even if a page has custom controls.

Sean: I think what this may have been trying to say is the requirement
to have the same functionality be present in the scripted controls as
in the built in, and have them go through the same platform level
accessibility framework (where it exists), so that a user presented
with the scripted version is not shut out from some expected
behaviour. I agree however that the section needs a re-write.

Silvia: Yes, agree with that analysis. In addition, it seems to me
that the introductory text has more requirements than the requirements
list - we could turn many of them into actual requirements. In
particular to provide a rich set of controls to the user and to
ascertain that they are keyboard accessible.

ISSUE: Did the requirement relate to having the same platform level
a11y framework for scripted and declarative controls or for requiring
native controls? And do we want to extend the set of controls that
should be required?


(2) Masatomo's concern about native controls:

Masatomo: In the introductory text, could say like "MUST NOT interfere
the native controls" instead of saying "MUST map to the native
controls"?

Silvia: sounds good - accept?

Sean: I think that's a good addition, but not I think the original
intention (but I could be wrong)

ISSUE: What was the original intention?


(3) Richard's feedback on mobile devices

Richard: How do mobile devices operate these controls without a
keyboard? Are you going to require that devices support a keyboard to
access controls/menus? I would investigate this issue with the mobile
device manufacturers.

Sean: We should prefix all keyboard and focus requirements with
something like "on systems where a keyboard is (or can be) present,
and where a unique focus object is employed..."

ISSUE: what to do about keyboard accessibility on mobile devices?


========

4. Requirements on the use of the viewport Section

Feedback was provided at:
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Requirements_on_the_use_of_the_viewport
for the text at:
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq17

Discussion thread between Sean and I starts at
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0236.html

The following needs to be discussed in the larger group:


(1) Philip's feedback on dimensions:

(VP-1) If alternative content has a different height or width to the
media content, then the user agent will reflow the viewport. (UAAG 2.0
3.1.4).

Philip: Text tracks don't have dimensions, they depend on the video
track. If there are text formats where this is not true, those formats
will not be used on the web. Remove this requirement.

Silvia: UAAG 2.0 states the following:
"3.1.4 Rendering Alternative (Enhanced): Provide the user with the
global option to configure a cascade of types of alternatives to
render by default, in case a preferred type is unavailable. If the
alternative content has a different height or width, then the user
agent will reflow the viewport. (Level AA)"

Text tracks may have dimensions, but they should be provided relative
to the video viewport rather than as absolute sizes IMO. Alternative
content could also be other videos, so this makes reflowing the
viewport still a requirement. It is, however, a question whether
reflowing the viewport is acceptable, in particular if the
dimensions of the media were fixed by the author. May need to discuss
this in the media a11y group.

Sean: I disagree. An audio only player with captions/lyrics etc is an
important use case; I can definitely see the need for the 'overlay' to
exceed the media display size.

Silvia: I did forget about the audio use case. For video, I started
from the TV background, which is the full-screen condition, where
everything is rendered in relation to the video dimensions.

I actually think we may need to distinguish two cases: one where the
author has created the overlay in relation to the video viewport and
wants it scaled with the viewport, and one where the author has
created the overlay with stand-alone dimensions and doesn't want any
media-related scaling - maybe only media-related positioning. If the
position is as an overlay and the overlay is larger, that would result
in a need to reflow the layout (not so much the video viewport, but
the web page IMHO).

Technically, this may create a need to provide an author hint to the
Web page when embedding alternate content so as to tell the Web page
how to render the content: scale with the media resource, or scale
independently. And when scale independently, then a position hint
needs to be provided.

ISSUE: See also captioning feedback above - how to deal with the
mapping of caption dimensions to Web page layout?


(2) Philip & Eric's feedback on video resizing:

(VP-3) Provide the user with the ability to adjust the size of the
time-based media up to the full height or width of the containing
viewport, with the ability to preserve aspect ratio and to adjust the
size of the playback viewport to avoid cropping, within the scaling
limitations imposed by the media itself. (UAAG 2.0 4.9.9)

Philip: Can this be made more specific? Is it about being able to
scale overlay sign language video tracks, or also about some other
kind of track?

Eric: Need details about how this is supposed to work, eg. does the
video pop up over the page content or does the rest of the page
reflow? Is page zoom enough? "with the ability to preserve aspect
ratio" - when would the user ever not want to preserve aspect ratio?

Silvia: The intent of this criterium as per UAAG 2.0 is "User needs
video larger but still needs access to other application (take notes
during playback), fullscreen does not allow that. Content should
reflow as user adjusts playback viewport." It seems it is about
scaling the video by the user beyond its current size, but not to
fullscreen. This may also relate to sign language, but it seems not
the primary concern of UAAG. We should make it more specific and talk
about the intent of the criterium, e.g. the need for a resizing
functionality on the video viewport.

Sean: I can see the need here, but there isn't any requirement to
scale other parts of the flowed document (e.g images) independently,
so this seems a bit out on a limb. Theoretically one could use
viewport scrolling and scaling of the entire page to achieve this I
guess.

ISSUE: How to deal with the UAAG requirement on user adjustable video size?


(3) Philip's feedback on contrast & brightness control

(VP-4) Provide the user with the ability to control the contrast and
brightness of the content within the playback viewport. (UAAG 2.0
4.9.11)

Philip: Is not currently possible since the <video> can be drawn on a
<canvas>, where the colors cannot be altered because of user
preference. No UA has such an option for images, why is it a
requirement for video? Suggest to remove this requirement.

Silvia: should discuss this with the larger media a11y group. I also
wonder if the need to change contrast and brightness is attached at
too low a level with the video and should just be done for the whole
screen, which is already possible through other means.

Sean: Brightness and contrast of video are likely to have different
characteristics than other content, often for example webcams offer
control over this; so I can see the need, agree this should be open
for larger discussion.

ISSUE: How important is it to separately control contrast and
brightness on video?


=====

Cheers,
Silvia.

Received on Sunday, 4 July 2010 13:09:24 UTC