W3C home > Mailing lists > Public > public-html-a11y@w3.org > July 2010

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 23 Jul 2010 07:17:24 +1000
Message-ID: <AANLkTinQUwq6I723I_OYYXYyMlzJaLTfptcDGR_gBIHK@mail.gmail.com>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
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.
>>
>>
>
Received on Thursday, 22 July 2010 21:18:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:13 GMT