Re: [media] Addressing "3.7 Requirements on the use of the viewport"

Note: you can see the changes that have been made to the viewport section by
following this link:
http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Media_Accessibility_Requirements&diff=1883&oldid=1806
and ignoring the top part about "Clear Audio" (there were intermediate
commits to the wiki).

Regards,
Silvia.


On Fri, Jul 23, 2010 at 7:17 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> Note to all:
>
> Changes to the Viewport section [1]
> according to feedback from the survey [2]
> and discussions of that feedback between Sean and myself have been
> finalised in the wiki [1].
>
> Some notes on technical realisation have also been included, similar
> to other discussions in the group on other media requirements areas.
>
> [1]
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Requirements_on_the_use_of_the_viewport
> [2]
> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq17
>
> Best Regards,
> Silvia.
>
>
> On Sun, Jul 4, 2010 at 7:58 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
> > Hi Sean,
> >
> > On Wed, Jun 30, 2010 at 2:22 AM, Sean Hayes <Sean.Hayes@microsoft.com>
> wrote:
> >> 1. 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.
> >
> >
> > 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.
> >
> >
> >> 2. 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.
> >
> >
> > Might be worth discussing this in the group.
> >
> >
> >> 3. 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.
> >
> >
> > OK.
> >
> >
> >> 4. Yes I think that was the intention.
> >
> >
> > OK, no need to discuss then - this is the reply and the requirement
> > should be made more concrete to contain this.
> >
> >
> >> 6&7 yes moving the captions is an option.
> >>
> >> Otherwise agree.
> >
> > Awesome.
> >
> > Cheers,
> > Silvia.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
> >> Sent: Saturday, June 26, 2010 2:48 AM
> >> To: Sean Hayes
> >> Cc: HTML Accessibility Task Force
> >> Subject: [media] Addressing "3.7 Requirements on the use of the
> viewport"
> >>
> >> Hi Sean,
> >>
> >> (copied to list for documentation purposes)
> >>
> >> This is the last section we are reviewing from the media requirements.
> >> These are my initial thoughts.
> >>
> >> Requirements on the use of the viewport
> >>
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Requirements_on_the_use_of_the_viewport
> >>
> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq17
> >>
> >> 1.
> >> (VP-1) 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.
> >>
> >> Reply: 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)"
> >>
> >> Discussion: 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.
> >>
> >>
> >> 2.
> >> (VP-3) 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?
> >>
> >> Reply: 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.
> >>
> >> Discussion: 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.
> >>
> >>
> >> 3.
> >> (VP-4) 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.
> >>
> >> Discussion: 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.
> >>
> >>
> >> 4.
> >> (VP-5) All browsers use this area for controls. What is the suggested
> alternative?
> >>
> >> Reply: I think the idea of this requirements is to make sure to avoid
> overlap of controls and captions, such that when controls are displayed, the
> captions are moved up above them. Should discuss with larger media a11y
> group if that was the intention.
> >>
> >>
> >> 5.
> >> (VP-3) 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?
> >>
> >> Reply: indeed - see 2. above
> >>
> >>
> >> 6.
> >> (VP-5) All existing browser, and many stand-alone media player
> applications, place controls along the bottom edge of the movie. Where
> should they go instead?
> >>
> >> Reply: see 4. above
> >>
> >>
> >> 7.
> >> VP-5 may not be relevant in some case for example if the video contain
> essential information in this area overlapping it with caption make it
> impossible to see
> >>
> >> Reply: Maybe the requirement can be reformulated to talk about avoiding
> overlapping of displayed content on the video, but in particular in the
> lower third where lots tends to happen. It could be made more concrete such
> as if there are video controls, and overlay ads, and captions, then the
> captions should move up the highest, the overlay below that, and the
> controls should always stay at the bottom edge.
> >>
> >>
> >> 8.
> >> Again UA guidelines need to be introduced as recommended practice in a
> content spec.
> >>
> >> Reply: Yes, agreed, this needs to become much more concrete.
> >>
> >>
> >> 9.
> >> "(VP-1) If alternative content has a different height or width to the
> media content, then the user agent will reflow the viewport." - this does
> not seem to account for a scenario when the view-port has already been
> maximized, but remains small due to device limitations.
> >>
> >> Reply: agreed - should be included with 1. above
> >>
> >>
> >> 10.
> >> "(VP-4) Provide the user with the ability to control the contrast and
> brightness of the content within the playback viewport." - appears to be a
> user-agent device requirement and should already be addressed in the UAAG.
> This is also to me a clear candidate for "SHOULD" language as it does not
> account for limitations of various devices
> >>
> >> Reply: agreed, see 3 above
> >>
> >>
> >> ===
> >>
> >> This one again has several issues that may need addressing by the whole
> media subgroup.
> >>
> >> Cheers,
> >> Silvia.
> >>
> >>
> >
>