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

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

Received on Sunday, 4 July 2010 10:44:10 UTC