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

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.

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.

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.

4&5. OK.

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

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.

12. I would still prefer something like "annotated captions" but it's a moot point if we have a good glossary definition.

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.

15. Yes, obviously not all the time; but this is a common occurrence in real media.



-----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 Tuesday, 29 June 2010 16:13:05 UTC