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

[media] Addressing "Captioning" feedback on requirements document

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 23 Jun 2010 23:52:42 +1000
Message-ID: <AANLkTikp0HmbLuegKQUJ8mx21cdm4Hn4V-yT-y9gr4uN@mail.gmail.com>
To: Sean Hayes <Sean.Hayes@microsoft.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi Sean,

I'm going to start our work item by going through the feedback that
was provided on the captioning section. I'm making suggestions for
changes to make in the wiki. Thus, the notes below are in preparation
for your input.

Feedback was provided at:
for the spec at:

(CC-1) The reference time doesn't have to be the audio track, let's
just say it's the media resource. (Video without audio but with
captions is possible.)

Suggestion: accept proposal
Change: s/audio track/media resource/

(CC-5) Is this a requirement for pixel-perfect positioning, or
relative positioning? Must it be possible to give a bounding box for
the text, or is it enough to say where it starts?

Suggestion: ?? don't understand what erasures means actually ??

(CC-13) Sounds very peculiar and not something that is possible with
most formats I have seen. Please give a rationale for why this is
important (or remove the requirement if it isn't).

Suggestion: Reformulate to "Enable rendering of text with a thicker
outline or a drop shadow to allow for better contrast with the

(CC-14) How can a single caption mix "display styles", e.g. both be
"paint-on" and "pop-up"? (I don't know exactly what any of the quoted
words mean.)

Suggestion: explain the display styles & how several can be active at once

(CC-17) If there are separate caption files, is it expected that these
should be displayed together and not overlap? This sounds rather
difficult to implement, why not simply have a single caption file?

Suggestion: Parallel display should indeed be possible. Add a sentence

(CC-20) Is supporting italics enough to differentiate between
languages, or should it be possible to mark up the actual language. If
yes, why?

Reply: Foreign languages should be exposed specially, possibly in
italics or bold etc. but not to mark up the actual language.

(CC-26) Sounds like a bonus, not an essential requirement.

Reply: Internationalisation of captions is a core requirement,
otherwise we remove a large number of users from access to the

The first paragraph of the introductory text says: "Captions are
always written in the same language as the main audio track."
Whereas the Requirements sections says: "Formats for captions,
subtitles or foreign-language subtitles must:"

Suggestion: remove the first sentence from the introduction.

Obviously the Requirements section knows about subtitles in other
languages than the languag of the main audio track ... Please bring in
the subject of subtitling in other languages into the introductory

Suggestion: agree - introduce a sentence about subtitles in other
languages in introduction

(CC-1) Not all media files have audio.

see 1. above

(CC-17) Does this mean that captions are rendered from more than one
external caption file simultaneously?

Reply: rendering is not mentioned in CC-17, just representation. This
could be in a menu from which the captions are selected.

(CC-25) What must a UA do differently for edited vs full verbatim captions?

Reply: there is a need to potentially have two different caption
tracks available: edited and full verbatim captions. That's what this
refers to.

(CC-1) The timebase master should be the media resource, instead of
the audio track?

see 1. above

(CC-1) What if said media has no audio track?

see 1. above

(CC-17) How would multiple caption files coexist for the same media?
Based on user preferences?

Reply: the point is that they can be made available on the server,
marked up on the HTML page, and downloaded as required for the media

The user should also have final control over rendering styles like
color and fonts

Reply: agree - maybe add another requirement

There should be a way to find and switch caption languages on the fly.
How is that done if the caption document is found at a different URI?

Reply: the URIs need to be all made available to the HTML document

(cc-5) Do you really want to say ALL parts of the screen? Placing
captions to the far right of the screen may not be the best thing to

Reply: any position should be possible. There may be a situation,
where it will be required.

We should be careful not to conflate the terminology between captions
and subtitles as some people get upset about that.

Reply: agreed - however, there are also HoH people of different
languages, so captions need to be internationalisable, too

(CC-1) A media file may have a separate time encoding which is used
both video and audio. However captions are defined as a text
representation of audio; so captions and video only don't make sense.

Reply: There can be videos with multiple audio tracks, so identifying
one as the main time-keeper is dodgy. Also, a captioned video does not
have to retain the audio track to be useful. It is better to simply
refer to the time-keeping of the complete media resource, see also 1.

CC9-12 should be clear that the effects must be mixable within one caption.

Suggestion: accept - clarify that the styling mentioned in cc 9-12
should be applicable to a single caption cue.

CC-13 is to allow the user to see as much of the underlying video as
possible where captions are infrequent. Where captions are frequent;
it is preferable to keep the caption background so that it minimises

Suggestion: add to text proposed in 3.

CC-17 is really a requirement on subtitles (foreign language).

Reply: true, but it also applies to captions for people that do not
speak the main caption language (see also 15).


When we come to an agreement as to what is to be done about each of
the inputs, I can go ahead and make the changes in the wiki.

So much for today on captions - let's do Extended Captioning, Keyboard
Access to Interactive Controls, and Requirements on the use of the
viewport tomorrow?

Received on Wednesday, 23 June 2010 13:53:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:40 UTC