Re: [media] Addressing "2.7 Extended Captioning" feedback

Note to all:

Changes to the Extended Captions 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.

I am not very happy with this section yet, though - it could become a lot
more concrete and useful with more discussions in the wider group.

To see the changes, go to :
http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Media_Accessibility_Requirements&diff=1890&oldid=1889

[1]
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Extended_Captioning
[2]
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq8<http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq12>

Best Regards,
Silvia.




On Sun, Jul 4, 2010 at 8:43 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
wrote:
> Hi Sean,
>
>
> On Wed, Jun 30, 2010 at 2:12 AM, Sean Hayes <Sean.Hayes@microsoft.com>
wrote:
>> 1. As I said in the previous review. This document really needs a
glossary of terms, and I think your definition is a good start.
>
>
> Should the terms be defined in the respective sections or in a summary
> section? Maybe just in the respective sections might be best for
> readability reasons.
>
>
>> 2. 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.
>
>
> Should we replace "hyperlink" with URL or URI to make it more
> concrete? I think we really only care about the Web meaning of
> hyperlink here.
>
> Happy to discuss in the larger group.
>
>
>> 3. I see the analogy, but it doesn't quite work; as (unlike audio) the
duration of the pause is dependent on the users reading speed and not
anything intrinsic to the media. So this implies user control. This needs a
bit more thought and is related to the hyperlink comment.
>
>
> It may be worth more concretely explaining the examples rather than
> mentioning the analogy with audio descriptions. I can really only see
> user controlled duration on this - either through closing an overlay
> or through pressing the play button after a pause.
>
>
>> 4&5. OK.
>>
>> 6. Not necessarily for a very fast reader. So again I think this needs
more thought.
>
>
> Happy to discuss in larger group.
>
>
>> 7-10 OK
>>
>> 11. 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.
>
> 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.
>
> 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.
>
>
>> 12. I would still prefer something like "annotated captions" but it's a
moot point if we have a good glossary definition.
>
> OK.
>
>> 14. 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.
>
> 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. Might be worth discussing in the larger group.
>
>
>> 15. Yes, obviously not all the time; but this is a common occurrence in
real media.
>
> 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.
>
>
> Cheers,
> Silvia.
>
>
>> -----Original Message-----
>> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
>> Sent: Thursday, June 24, 2010 2:04 PM
>> To: Sean Hayes
>> Cc: HTML Accessibility Task Force
>> Subject: [media] Addressing "2.7 Extended Captioning" feedback
>>
>> Hi Sean,
>>
>> (cc-ed to a11y TF for documentation)
>>
>> I'm now reviewing the "extended captioning" section 2.7:
>>
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Extended_Captioning
>>
http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq8
>>
>> 1.
>> (ECC-1) Much too vague. What are the actual requirements and use cases?
>>
>> Reply: the use cases are described in the introduction to this section;
however, they should probably be made more concrete and the term "extended
captioning" be described better.
>>
>> Proposal: add an introductory sentences, something like "Extended
captions are captions that have been enriched with further data - examples
are glossary definitions for acronyms and other intialisms, foreign terms
(for example Latin), jargon or descriptions for other difficult language.
Such extensions can provide important additional information to the content
that will enable or improve the understanding of the main content to
accessibility users. Extended captioning will be particularly useful for
those with restricted reading skills."
>>
>>
>> 2.
>> (ECC-2) I would like to see links, but "other activation mechanisms"
>> is again much too vague. What are the actual requirements and use cases?
>>
>> Proposal: 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.
>>
>>
>> 3.
>> (ECC-4) Is the feature part of the format, or a feature of the UA?
>>
>> Reply: this feature is analogous to extended audio descriptions - where
timing for an extended caption is longer than the available time for the
caption, it may be necessary to halt the media to allow for more time to
read back on the caption and its additional material.
>>
>> One particular instance of this feature may be: when a hyperlink is
clicked in a caption, the media resource pauses and the new resource opens
in an overlay. When the overlay is closed, the media resource and the
synchronised caption continue.
>>
>>
>> 4.
>> (ECC-1) What does this mean? What is the format of "metadata markup"?
>>
>> Reply: see 1. above
>>
>>
>> 5.
>> (ECC-2) What are "other activation mechanisms"?
>>
>> Reply: see 2. above
>>
>>
>> 6.
>> (ECC-4) How does this work? Who decides if "overlap is OK ..."
>>
>> Reply: 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.
>>
>>
>> 7.
>> ECC-1,2 and 4 need to be more explicit
>>
>> Reply: see above
>>
>>
>> 8.
>> ECC-4   Could say "with the user setting overriding the author setting",
>> or specify which side sets this option?
>>
>> Replay: just adopt proosed text
>>
>>
>> 9.
>> Also I am not sure what ECC-1 and -2 actually mean.
>>
>> Reply: See 1. and 2. above
>>
>>
>> 10.
>> (ECC-1), (ECC-2) and (ECC-4) need to be defined more clearly.
>>
>> Reply: see 1., 2., and 4. above.
>>
>>
>> 11.
>> Regarding ECC-4 what about providing a feature to configure wrapping text
with smaller fonts? This seems better than cutting off the text.
>>
>> Reply: it still needs to remain readable, so smaller font is probably not
a good idea.
>>
>>
>> 12.
>> General, these should probably be called additional text information or
something, as captions are a representation of the audio track; and this
text is not in the audio. This text should not be marked as caption type.
>>
>> Reply: The word "caption" is actually menat here, but extended with
further information. And since the effect can be similar to extended audio
descriptions, this seems a valid name for the requirement.
>>
>>
>> 13.
>> ECC-1 - what user need is this addressing?
>>
>> Reply: See 1. above
>>
>>
>> 14.
>> 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.
>>
>> Reply: don't quite understand what purpose that has
>>
>>
>> 15.
>> ECC-4 - needs to be distinguished from the normal caption case of two
speech acts that overlap in time (e.g. an interruption).
>>
>> Reply: are overlapping captions necessary for the "normal case"?
>>
>>
>> 16.
>> 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
>>
>> Reply: add this as extra requirement
>>
>>
>> Cheers,
>> Silvia.
>>
>>
>