RE: ISSUE-309 (Image profile fails WCAG 1.2): Image profile needs to permit text equivalent [TTML IMSC 1.0]

Hi Pierre,

Please find attached another proposal for text in IMSC regarding image profiles, the proposed alt tag and WCAG.

Best regards,
John


John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv | www.screensystems.tv | https://twitter.com/screensystems


Visit us at
IBC, RAI Amsterdam, 12-16 Sept, stand 1.C49

P Before printing, think about the environment-----Original Message-----
From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
Sent: 25 June 2014 00:00
To: John Birch
Cc: mdolan@newtbt.com; public-tt@w3.org
Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image profile needs to permit text equivalent [TTML IMSC 1.0]

> In IMSC the provision we are (hopefully) discussing is for subtitles
> or captions to an internet device (a tablet, phone, computer or TV
> acting as a browser etc)

Such applications will in all likelihood require the delivery of a Text Profile document to complement an Image Profile document, thereby removing the need for mandatory 'alt' text... or are you concerned that these applications will not make such a requirement?

Would stating a "Text Profile document shall accompany an Image Profile document" resolve your concern, and remove the need for a mandatory 'alt' text?

> The Digital Cinema use case is fundamentally different.

Not really. Two different kinds of timed text are distributed as two separate documents.

Best,

-- Pierre

On Tue, Jun 24, 2014 at 2:50 AM, John Birch <John.Birch@screensystems.tv> wrote:
> If the text for accessibility devices is recommended for inclusion within an image profile IMSC document it is more likely IMHO that an implementor will produce a tool that will automatically include that text when generating the image set for the document.
>
> The 'requirement' that this is instead provided as a separate text profile document creates more issues for content publishers, in economic and management terms. More documents means more cost and more asset management. These operational issues are typically a greater impediment to provision than technical issues.
>
> The immediate challenge is that as you propose, in a multi language provision your proposal to use separate text tracks (that further debatably do not require to be true styled text but just need to contain plaintext) basically doubles the number of documents that need to be ordered, produced, QC'd, managed and distributed. Which seems ludicrous when simple plaintext inclusion of the precursor text in the image document would suit the requirement. Note I am not disputing that a text based document should be used when styled text based text is required (but that is not the case here).
>
> The Digital Cinema use case is fundamentally different. This provision is made for captioning, this is provision for a deaf audience. In many cases film translation is by dubbing. Further even where DC is displaying subtitles from an image based or text based server implementation the rear view system if present is acting independently (albeit TC synchronised) from the film server. In this use case a text only based document has some justification as the rear view system has **no simultaneous use for the subtitle images**.
>
> In IMSC the provision we are (hopefully) discussing is for subtitles or captions to an internet device (a tablet, phone, computer or TV acting as a browser etc). The accessibility device (braile board or speech engine) will be *directly* connected to that display. Use of an image only based subtitle provision precludes *equal* access for visually impaired viewers to the subtitles without making special separate text based provision. There is in this use case a likelihood of simultaneous use of subtitles on screen AND text to drive the accessibility device. To provide this simultaneous output it makes sense to me to provide the two types of equivalent infornation in the same document. Particularly when one type (the text) is easily included and has only minimal requirements in terms of complexity (I.e. Plaintext only).
>
> Best regards,
> John
>
>
> John Birch | Strategic Partnerships Manager | Screen Main Line : +44
> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile : +44
> 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv |
> www.screensystems.tv | https://twitter.com/screensystems

>
> Visit us at
> IBC, RAI Amsterdam, 12-16 Sept, stand 1.C49
>
> P Before printing, think about the environment----- Original Message
> -----
> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
> Sent: Monday, June 23, 2014 06:31 PM
> To: John Birch
> Cc: mdolan@newtbt.com <mdolan@newtbt.com>; public-tt@w3.org
> <public-tt@w3.org>
> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image profile
> needs to permit text equivalent [TTML IMSC 1.0]
>
>> My problem with the approach of a separate track is that it is far
>> easier (and IMHO far more likely) for implementers not to provide
>> that text track.
>
> Content publishers are responsible for providing these tracks, not
> implementers... or did you mean something else?
>
> In any event, content nowadays consists of many tracks, including
> multiple text tracks for multiple languages, so I do not see an
> immediate challenge to supporting multiple text track for different
> kinds of accessibility requirements across different applications.
>
> As data point, D-Cinema successfully uses the same format but separate
> files for subtitles intended to be displayed on screen and captions
> intended for display on personal captioning devices or rear-window
> displays.
>
> Best,
>
> -- Pierre
>
> On Mon, Jun 23, 2014 at 9:45 AM, John Birch <John.Birch@screensystems.tv> wrote:
>> Hi Pierre,
>>
>> My problem with the approach of a separate track is that it is far easier (and IMHO far more likely) for implementers not to provide that text track. And consequently the principle of equality of access is not met.
>>
>> Further the concept of a more expressive track is not required for most accessibility devices, in fact the less adorned the better... Most devices simply require plaintext.
>>
>> I have no problem with this as an option in addition to the alt attribute in the image based track (although such a text track would probably require better metadata and not style).
>>
>> So in brief, no the proposed does not sufficiently encourage
>> inclusion of alternate text for access
>>
>> Best regards,
>> John
>>
>>
>> John Birch | Strategic Partnerships Manager | Screen Main Line : +44
>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile : +44
>> 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv |
>> www.screensystems.tv | https://twitter.com/screensystems

>>
>> Visit us at
>> IBC, RAI Amsterdam, 12-16 Sept, stand 1.C49
>>
>> P Before printing, think about the environment----- Original Message
>> -----
>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
>> Sent: Monday, June 23, 2014 07:39 AM
>> To: John Birch
>> Cc: mdolan@newtbt.com <mdolan@newtbt.com>; public-tt@w3.org
>> <public-tt@w3.org>
>> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image profile
>> needs to permit text equivalent [TTML IMSC 1.0]
>>
>> Hi John,
>>
>> Different applications of IMSC 1.0 will have different accessibility
>> requirements, i.e. WCAG will not cover all applications of IMSC 1.0.
>>
>>> I am unaware of specific normative prose in IMSC that enforces the
>>> requirement that accessibility is provided as a separate text profile track.
>>
>> The text in Section 3.1 currently reads: "Some applications require
>> the same subtitle/caption content to be available in both text and
>> image form simultaneously (see [WCAG20] for instance). For these
>> applications, two distinct subtitle documents, one conforming to the
>> Text Profile and the other conforming to the Image Profile, can be
>> offered."
>>
>> Are you suggesting that "can be offered" should be changed to "should
>> be offered"?
>>
>>> It seems a small point to support alt text equivalent strings within image based documents...
>>> And I am surprised at the resistance to this concept.
>>
>> I like the idea of adding text equivalent string to content elements,
>> but do not believe that, in IMSC 1.0, the text equivalent string
>> should replace a document conforming to Text Profile, which is vastly
>> more expressive and hence desirable.
>>
>> Best,
>>
>> -- Pierre
>>
>> On Sun, Jun 22, 2014 at 10:26 PM, John Birch
>> <John.Birch@screensystems.tv> wrote:
>>> I am afraid that I see us at an impasse.
>>>
>>> I am unaware of specific normative prose in IMSC that enforces the requirement that accessibility is provided as a separate text profile track.
>>>
>>> I cannot support IMSC if it fails to recommend image profile *documents* that meet WCAG guidelines.
>>>
>>> It seems a small point to support alt text equivalent strings within image based documents... And I am surprised at the resistance to this concept.
>>>
>>> Accessibility is all about in-band support. It is about *equal* access... It is decidedly not about separate optional provision at the munificence of the publisher.
>>>
>>> Best regards,
>>> John
>>>
>>> John Birch | Strategic Partnerships Manager | Screen Main Line : +44
>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile :
>>> +44 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv
>>> | www.screensystems.tv | https://twitter.com/screensystems

>>>
>>> Visit us at
>>> Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand 5E4-01
>>>
>>> P Before printing, think about the environment----- Original Message
>>> -----
>>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
>>> Sent: Friday, June 20, 2014 06:43 PM
>>> To: John Birch
>>> Cc: Michael Dolan <mdolan@newtbt.com>; Timed Text Working Group
>>> <public-tt@w3.org>
>>> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image profile
>>> needs to permit text equivalent [TTML IMSC 1.0]
>>>
>>> Hi John,
>>>
>>> Thanks for taking another stab at the text! I like the detailed
>>> guidance is writing descriptive text to be associated with an image.
>>> I have only one blocking concern with it.
>>>
>>>>The text equivalent string is intended for use by screen readers or reproduction by braille devices etc.
>>>
>>> In IMSC 1.0, content intended for use by screen readers or
>>> reproduction by braille devices etc. is delivered using a Text
>>> Profile document, so the sentence needs to read
>>>
>>> "The text equivalent string is not intended for use by end user
>>> devices, e.g. screen readers or reproduction by braille devices etc.
>>> Such content is delivered using a Text Profile document."
>>>
>>> Note that I do not expect the text to be that specific in TTML 2.0,
>>> when we get around to implementing image support, since TTML 2.0
>>> will probably wish to support applications that specify in-band
>>> content for use by screen readers or by braille devices.
>>>
>>> Best,
>>>
>>> -- Pierre
>>>
>>>
>>> On Fri, Jun 20, 2014 at 3:43 AM, John Birch <John.Birch@screensystems.tv> wrote:
>>>> Hi Pierre,
>>>>
>>>> Is this any better?
>>>>
>>>>
>>>> 6.4 alt attribute
>>>>
>>>> The alt attribute is defined to allow an author to provide a text equivalent string for the image. This text equivalent is intended primarily to support users of the document who cannot see images, and may additionally support indexation of the content and also facilitate quality checking of the document during authoring. The text equivalent string is intended for use by screen readers or reproduction by braille devices etc. allowing the content and function of the image to be accessible to those with visual or certain cognitive disabilities. It should be noted that *in contrast to the common use of alt attributes within html content*, the imsc1:alt attribute content is not intended to be displayed in place of the image if the image file is not (able to be) loaded.
>>>>
>>>> If a smpte:backgroundImage attribute is applied to a div element, an imsc1:alt attribute should be applied to the div element and should contain a 'text equivalent' string value that is an appropriate functional replacement for the image source referenced by the smpte:backgroundImage. In the context of IMSC, where the images are usually representing subtitle or caption text, the guidelines for authoring text equivalent strings given in the html5 specification are appropriate: see section 4.7.1.1.5 Images of text of the draft document for HTML5 - A vocabulary and associated APIs for HTML and XHTML (W3C Last Call Working Draft 17 June 2014). : http://www.w3.org/TR/html5/.

>>>>
>>>> The 'text equivalent' string conveyed by the alt attribute should be written so that it conveys all essential content and fulfils the same function as the associated image. In the context of subtitling and captioning, this essential content will be the verbatim equivalent of the image without précis or summarisation. However the author should consider including extra information to the text equivalent string in cases where styling is applied to the text image with a deliberate connotation, as a *functional* replacement for the applied style. E.g. In subtitling and captioning, italics may be used to indicate an off screen context (for example a voice from a radio). An author may choose to include this functional information in the alt attribute text equivalent; for example, by including the word "Radio: " before the image equivalent text. It should also be noted that images intended for use as *captions*, i.e. intended for a hard of hearing audience, may already include this functional information in the rendered text.
>>>>
>>>>
>>>>
>>>> To maintain a close connection between an image and the associated
>>>> text equivalent I still believe it is more appropriate to place the
>>>> alt attribute within the div. It would be more ideal IMHO if the
>>>> alt attribute was part of smpte:backgroundImage... but of course
>>>> that is outside of our scope, so placing it in the div is IMHO the
>>>> next best alternative. I believe we should basically follow the
>>>> WCAG20 guidelines for "Text Alternatives":
>>>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-text-

>>>> alternatives-head
>>>>
>>>> "In order for people with disabilities to be able to use this text - the text must be "programmatically determinable." This means that the text must be able to be read and used by the assistive technologies (and the accessibility features in browsers) that people with disabilities use.
>>>> It must also be possible for people using assistive technologies to find these text alternatives when they encounter non-text content that they cannot use. To accomplish this, we say that the text must be "programmatically associated" with the non-text content. This means that the user must be able to use their assistive technology to find the alternative text (that they can use) when they land on the non-text content (that they can't use)."
>>>>
>>>> Although the above is written with the assumption of browsers as the processing agent I believe this guidance is still valid. For me, in our context, programmatically associated with the non-text content means placing it as close as is reasonable to the image content. I also believe placing the alt attribute under metadata would encourage the undesirable possibility that the metadata might be deliberately stripped upon transmission as it was 'deemed unnecessary' or to 'save bandwidth'.
>>>>
>>>>
>>>>
>>>> On a new point...Are there cardinality restrictions with regards to smpte:backgroundImage and div in IMSC? They are not apparent in the IMSC draft? Am I correct in assuming that a div can contain only a *single* smpte:backgroundImage? And that timing is therefore applied to the div element? If a div could contain multiple images it is even more difficult to see how correct "programmatic association" between images and metadata could be ensured.
>>>>
>>>> Best regards,
>>>>
>>>> John
>>>>
>>>>
>>>> On Thu, Jun 19, 2014 at 1:24 AM, John Birch <John.Birch@screensystems.tv> wrote:
>>>>> OK...
>>>>>
>>>>> I'm not sure about the *connection* between "the "alt" content needs to be in a metadata element" and "as it does not impact rendering".
>>>>>
>>>>> While I agree with the latter statement completely, I am not sure that this justifies classing it as metadata. It is not data about data, it is an 'alternative form' of the same thing. My preference is to align with HTML alt tag conventions.
>>>>>
>>>>> I understand your concerns with my prose, as it does leave the door open to implementers deciding to use the text to re-render... whilst it will be impossible to stop that, I can and will modify the prose to indicate reasons why that is not recommended... and I will also provide additional rationale for the inclusion of this attribute...
>>>>>
>>>>> Best regards,
>>>>> John
>>>>>
>>>>>
>>>>> John Birch | Strategic Partnerships Manager | Screen Main Line :
>>>>> +44
>>>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile :
>>>>> +44
>>>>> 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv |
>>>>> www.screensystems.tv | https://twitter.com/screensystems

>>>>>
>>>>> Visit us at
>>>>> Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
>>>>> 5E4-01
>>>>>
>>>>> P Before printing, think about the environment-----Original
>>>>> Message-----
>>>>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
>>>>> Sent: 19 June 2014 07:10
>>>>> To: John Birch
>>>>> Cc: Michael Dolan; Timed Text Working Group
>>>>> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image
>>>>> profile needs to permit text equivalent [TTML IMSC 1.0]
>>>>>
>>>>> Hi John,
>>>>>
>>>>> Couple of comments.
>>>>>
>>>>> - the "alt" content needs to be in a metadata element, as it does
>>>>> not impact rendering
>>>>>
>>>>> - I am not comfortable with the statement "text equivalents should be written so that they convey all essential content and fulfil the same function as the images" as it strays from the "It can be used in QC..." use case and appears to define a parallel means of delivering subtitle/caption text content which is already covered by the Text Profile in IMSC 1.0.
>>>>>
>>>>> Best,
>>>>>
>>>>> -- Pierre
>>>>>
>>>>> On Wed, Jun 18, 2014 at 3:16 AM, John Birch <John.Birch@screensystems.tv> wrote:
>>>>>> 6.4 alt attribute
>>>>>>
>>>>>> If a smpte:backgroundImage attribute is applied to a div element, an imsc1:alt attribute should be applied to the div element and should contain a 'text equivalent' string value that is an appropriate functional replacement for the image source referenced by the smpte:backgroundImage.
>>>>>> In the context of IMSC, where the images are usually representing subtitle text, the guidelines given for html5 are appropriate: see section 4.7.1.1.5 Images of text: http://www.w3.org/TR/html5/ of the draft document HTML5 - A vocabulary and associated APIs for HTML and XHTML (W3C Last Call Working Draft 17 June 2014). Text equivalents should be written so that they convey all essential content and fulfil the same function as the images. In cases where styling is applied to the text image with a deliberate connotation, the author should consider including extra information in the alt attribute text equivalent as a *functional* replacement for the applied style. E.g. In subtitling applications italics may be used to indicate an off screen context (for example a voice from a radio). This might be indicated in the alt text equivalent by including the word "Radio:" before the image equivalent text. It should also be noted that images intended for use as *captions* may already include this functional information in the rendered text.
>>>>>>
>>>>>> I have included a definition of imsc1:alt tag attribute... I assume this would be a necessary extension?
>>>>>>
>>>>>> imsc1:alt (attribute)
>>>>>> Type: xs:string
>>>>>> Cardinality: 0..1
>>>>>> Description: Text equivalent for Presented Images for subtitle documents conforming to the Image Profile.
>>>>>>
>>>>>> Does that work for you?
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> John
>>>>>>
>>>>>> John Birch | Strategic Partnerships Manager | Screen Main Line :
>>>>>> +44
>>>>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile :
>>>>>> +44
>>>>>> 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv |
>>>>>> www.screensystems.tv | https://twitter.com/screensystems

>>>>>>
>>>>>> Visit us at
>>>>>> Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
>>>>>> 5E4-01
>>>>>>
>>>>>> P Before printing, think about the environment-----Original
>>>>>> Message-----
>>>>>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
>>>>>> Sent: 17 June 2014 17:59
>>>>>> To: John Birch
>>>>>> Cc: Michael Dolan; Timed Text Working Group
>>>>>> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image
>>>>>> profile needs to permit text equivalent [TTML IMSC 1.0]
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> Ok. Please propose specific text for an optional "imsc1:Alt" metadata element.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -- Pierre
>>>>>>
>>>>>> On Tue, Jun 17, 2014 at 9:54 AM, John Birch <John.Birch@screensystems.tv> wrote:
>>>>>>> This (an alt tag or attribute) is exactly what I am asking for.
>>>>>>> But I would like it to be part of the specification, and ideally a recommendation, rather than leaving it as something that somebody knowledgeable could infer might be possible...
>>>>>>>
>>>>>>> Best regards,
>>>>>>> John
>>>>>>>
>>>>>>> John Birch | Strategic Partnerships Manager | Screen Main Line :
>>>>>>> +44
>>>>>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile :
>>>>>>> +44
>>>>>>> 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv
>>>>>>> | www.screensystems.tv | https://twitter.com/screensystems

>>>>>>>
>>>>>>> Visit us at
>>>>>>> Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
>>>>>>> 5E4-01
>>>>>>>
>>>>>>> P Before printing, think about the environment-----Original
>>>>>>> Message-----
>>>>>>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
>>>>>>> Sent: 17 June 2014 17:50
>>>>>>> To: John Birch
>>>>>>> Cc: Michael Dolan; Timed Text Working Group
>>>>>>> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image
>>>>>>> profile needs to permit text equivalent [TTML IMSC 1.0]
>>>>>>>
>>>>>>>> For example... It can be used in QC... a font selection error
>>>>>>>> could result in images that are incorrect for the input text... but how would you know by examining just the images?
>>>>>>>> Again, it is trivial to include this information during the
>>>>>>>> creation of a primarily image based document track.
>>>>>>>
>>>>>>> As suggested by Mike, this could be served by "alt" metadata that would allow authors to optionally associate text with any IMSC content.
>>>>>>>
>>>>>>> Would this address your concern?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -- Pierre
>>>>>>>
>>>>>>> On Tue, Jun 17, 2014 at 9:44 AM, John Birch <John.Birch@screensystems.tv> wrote:
>>>>>>>> I'm not actually asking anybody to introduce another means...
>>>>>>>>
>>>>>>>> I'm simply stating an opinion that applications that wish to enhance the lives of people who might require accessibility solutions, (e.g. braille readers) might be considered more useful (and I imagine would be the preferred application) if they choose to implement a means to supply the alternate text to those devices.
>>>>>>>>
>>>>>>>> My *personal standpoint* is that *all* standards should promote and insist upon accessibility... and *for me* that doesn't mean making it optional or leaving it as somebody else's problem or decision.
>>>>>>>> Accessibility works best when it is a hard recommendation and clear benefits to all parties can be seen. The inclusion of alternative text for images has benefits to users of image based documents far beyond accessibility. For example... It can be used in QC... a font selection error could result in images that are incorrect for the input text... but how would you know by examining just the images? Again, it is trivial to include this information during the creation of a primarily image based document track.
>>>>>>>>
>>>>>>>> Further, applications cannot spontaneously 'create' an additional separate Text Profile document track... that would have to be created (by choice) by the content provider... and that's the disconnect for the user who needs the alternative representation.
>>>>>>>>
>>>>>>>> Insisting upon only supporting use cases where this content must exist as a separate track creates new issues of asset management, and (as has been raised by you or Mike?) raises the complexity for processors that seek to be more accessible by providing alternative text... why should an accessible processor implementation be so penalised?
>>>>>>>>
>>>>>>>> It also increases dramatically the likelihood that this information will not be provided by content providers... and therefore massively increases the likelihood that users who need text alternatives are disenfranchised.
>>>>>>>>
>>>>>>>> I very much struggle to see the foundation for the objections to including this alternative text information:
>>>>>>>> Insisting upon a rigid logical separation of content by categories into separate tracks has not been religiously applied (see forcedDisplayMode)... so what other basis is there?
>>>>>>>> Existing implementations might not support it? So what... I haven't ever asked for it to be mandatory...
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> John
>>>>>>>>
>>>>>>>> John Birch | Strategic Partnerships Manager | Screen Main Line :
>>>>>>>> +44
>>>>>>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile :
>>>>>>>> +44
>>>>>>>> 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv
>>>>>>>> | www.screensystems.tv | https://twitter.com/screensystems

>>>>>>>>
>>>>>>>> Visit us at
>>>>>>>> Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
>>>>>>>> 5E4-01
>>>>>>>>
>>>>>>>> P Before printing, think about the environment-----Original
>>>>>>>> Message-----
>>>>>>>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
>>>>>>>> Sent: 17 June 2014 16:42
>>>>>>>> To: John Birch
>>>>>>>> Cc: Michael Dolan; Timed Text Working Group
>>>>>>>> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image
>>>>>>>> profile needs to permit text equivalent [TTML IMSC 1.0]
>>>>>>>>
>>>>>>>>> However,  I would suggest that a ‘useful’ implementation might
>>>>>>>>> make the text available to another process or output device whilst also still decoding the images.
>>>>>>>>
>>>>>>>> An application that wish to make text available to an output device for use by a user can provide a separate Text Profile document. I do not see a reason to introduce another means of delivering Timed Text to the user.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> -- Pierre
>>>>>>>>
>>>>>>>> On Mon, Jun 16, 2014 at 8:33 AM, John Birch <John.Birch@screensystems.tv> wrote:
>>>>>>>>> I find it difficult to reconcile a design decision with a
>>>>>>>>> requirement… unless the original CFF(?) use case explicitly
>>>>>>>>> demanded a single document…(which is not clear from below) ;-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regardless… I understand the desire to simplify the implicit
>>>>>>>>> requirements on a notional processor to only loading, decoding
>>>>>>>>> and rendering a single document and therefore I do generally support the forcedDisplayMode concept.
>>>>>>>>>
>>>>>>>>> For me this is the inclusion of two logical streams of
>>>>>>>>> (connected) content within a single document. Further, I do
>>>>>>>>> see this as setting a precedent. J
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With regards to adding text to the image profile, the proposal
>>>>>>>>> was only ever to consider the text as ‘alternative content’.
>>>>>>>>> However, I would suggest that a ‘useful’ implementation might
>>>>>>>>> make the text available to another process or output device whilst also still decoding the images. (e.g.
>>>>>>>>> support text output to a braille display simultaneously to image rendering).
>>>>>>>>> I agree that the text should not be considered ‘normal TTML text’
>>>>>>>>> as (under that specification) it would need to be displayed.
>>>>>>>>> Instead I suggest that the (equivalent) alternative text
>>>>>>>>> should be included as an attribute of the image… and thus could not have an independent existence from an image?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ideally I would like this to be a change to the current IMSC specification.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> John Birch | Strategic Partnerships Manager | Screen Main Line :
>>>>>>>>> +44
>>>>>>>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile :
>>>>>>>>> +44
>>>>>>>>> 7919 558380 | Fax : +44 1473 830078
>>>>>>>>> John.Birch@screensystems.tv | www.screensystems.tv |
>>>>>>>>> https://twitter.com/screensystems

>>>>>>>>>
>>>>>>>>> Visit us at
>>>>>>>>> Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
>>>>>>>>> 5E4-01
>>>>>>>>>
>>>>>>>>> P Before printing, think about the environment
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: Michael Dolan [mailto:mdolan@newtbt.com]
>>>>>>>>> Sent: 12 June 2014 14:21
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To: 'Timed Text Working Group'
>>>>>>>>> Subject: RE: ISSUE-309 (Image profile fails WCAG 1.2): Image
>>>>>>>>> profile needs to permit text equivalent [TTML IMSC 1.0]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In this case, it is less about whether we agree.  I am
>>>>>>>>> clarifying what the requirements are in the liaison. The
>>>>>>>>> design for a single document with forcedDisplayMode was
>>>>>>>>> developed by a collection of movie subtitle authoring
>>>>>>>>> companies, and a collection of device manufacturers.  Us
>>>>>>>>> debating alternative designs doesn’t change the requirements.
>>>>>>>>> If W3C designs something else that requires simultaneous multiple document decoding and merged presentations, that would fail to meet the requirements.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regarding adding text to the image profile:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> “…including text in image profile documents would be an
>>>>>>>>> acceptable solution to you.”
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, as long as it is not required, and it is clearly signaled
>>>>>>>>> as “alternative” text in some manner.  It would be incorrect
>>>>>>>>> to include normal TTML text since that would have to be
>>>>>>>>> displayed and thus result in totally incorrect output.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                 Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>>>>>>>> Sent: Thursday, June 12, 2014 5:51 AM
>>>>>>>>> To: Michael Dolan; 'Timed Text Working Group'
>>>>>>>>> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image
>>>>>>>>> profile needs to permit text equivalent [TTML IMSC 1.0]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I understand the argument but I don't agree. This may come
>>>>>>>>> down to a 'system model' difference.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> They are both schemes in which multiple conceptually different
>>>>>>>>> content streams need to be made available, and the
>>>>>>>>> presentation of one or or more from the group is conditional
>>>>>>>>> on settings in the decoder, perhaps defined by the user.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> One could equally well generate a solution in which for 'forced display'
>>>>>>>>> content the content provider must provide two or more
>>>>>>>>> documents and ensure that the combined content of the group
>>>>>>>>> never exceeds the constraints of a single document, in complexity, overlapping regions, xml identifiers etc.
>>>>>>>>> Then the decoder must select the content from the appropriate
>>>>>>>>> documents and combine them client-side for display, which
>>>>>>>>> could be a defined 'pre-processing' task.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If necessary we could even signal within documents 'this forms
>>>>>>>>> part of a group that may be combined for collective presentation'
>>>>>>>>> with a new 'group identifier'. Documents with different group
>>>>>>>>> identifiers would offer no guarantee that they may successfully be combined in this way.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A solution like this would be extensible for live streams in
>>>>>>>>> which a group of temporally consecutive documents could be
>>>>>>>>> assigned the same group identifier and successfully combined
>>>>>>>>> for presentation – in that case they would probably be exclusive to each other temporally rather than spatially.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By the way, Mike, I note that you've previously indicated that
>>>>>>>>> including text in image profile documents would be an acceptable solution to you.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nigel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/06/2014 12:34, "Michael Dolan" <mdolan@newtbt.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> They are not the same.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> forcedDisplayMode text is embedded in a single document since
>>>>>>>>> otherwise a decoder would have *simultaneously* decode two
>>>>>>>>> documents (one with forced content and one with non-forced
>>>>>>>>> content) and merge the output over the visual object.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The desire to force the image profile to contain alternate
>>>>>>>>> text is solved with a text profile document.  Only one or the
>>>>>>>>> other document is decoded and presented since they each produce substantively the same visual results.
>>>>>>>>> And, even if it is desirable to decode both simultaneously,
>>>>>>>>> they would not have to be merged onto the visual object.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                 Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>>>>>>>> Sent: Thursday, June 12, 2014 4:10 AM
>>>>>>>>> To: 'Timed Text Working Group'
>>>>>>>>> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image
>>>>>>>>> profile needs to permit text equivalent [TTML IMSC 1.0]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've updated this issue with the following note:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The proposed resolution to this is not consistent with the
>>>>>>>>> approach taken for forcedDisplay (see also Issue-312). In the
>>>>>>>>> latter case it is stated that the two types of content must be
>>>>>>>>> provided in the same document. In this case it is stated that
>>>>>>>>> the content provider may optionally provide multiple documents.
>>>>>>>>>
>>>>>>>>> A simple resolution to this would be to permit text to be
>>>>>>>>> included in the image profile.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nigel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This message may contain confidential and/or privileged information.
>>>>>>>>> If you are not the intended recipient you must not use, copy,
>>>>>>>>> disclose or take any action based on this message or any
>>>>>>>>> information herein. If you have received this message in
>>>>>>>>> error, please advise the sender immediately by reply e-mail and delete this message.
>>>>>>>>> Thank you for your cooperation. Screen Subtitling Systems Ltd.
>>>>>>>>> Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
>>>>>>>>>   ­­
>>>>>>>>
>>>>>>>> This message may contain confidential and/or privileged information.
>>>>>>>> If you are not the intended recipient you must not use, copy,
>>>>>>>> disclose or take any action based on this message or any
>>>>>>>> information herein. If you have received this message in error,
>>>>>>>> please advise the sender immediately by reply e-mail and delete this message.
>>>>>>>> Thank you for your cooperation. Screen Subtitling Systems Ltd.
>>>>>>>> Registered in England No. 2596832. Registered Office: The Old
>>>>>>>> Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6
>>>>>>>> 0EQ
>>>>>>>
>>>>>>> This message may contain confidential and/or privileged information.
>>>>>>> If you are not the intended recipient you must not use, copy,
>>>>>>> disclose or take any action based on this message or any
>>>>>>> information herein. If you have received this message in error,
>>>>>>> please advise the sender immediately by reply e-mail and delete this message.
>>>>>>> Thank you for your cooperation. Screen Subtitling Systems Ltd.
>>>>>>> Registered in England No. 2596832. Registered Office: The Old
>>>>>>> Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
>>>>>>
>>>>>> This message may contain confidential and/or privileged information.
>>>>>> If you are not the intended recipient you must not use, copy,
>>>>>> disclose or take any action based on this message or any
>>>>>> information herein. If you have received this message in error,
>>>>>> please advise the sender immediately by reply e-mail and delete
>>>>>> this message. Thank you for your cooperation. Screen Subtitling
>>>>>> Systems Ltd. Registered in England No. 2596832. Registered
>>>>>> Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich,
>>>>>> Suffolk, IP6 0EQ
>>>>>
>>>>> This message may contain confidential and/or privileged information.
>>>>> If you are not the intended recipient you must not use, copy,
>>>>> disclose or take any action based on this message or any
>>>>> information herein. If you have received this message in error,
>>>>> please advise the sender immediately by reply e-mail and delete
>>>>> this message. Thank you for your cooperation. Screen Subtitling
>>>>> Systems Ltd. Registered in England No. 2596832. Registered Office:
>>>>> The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk,
>>>>> IP6 0EQ
>>>> John Birch | Strategic Partnerships Manager | Screen Main Line :
>>>> +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile
>>>> : +44 7919 558380 | Fax : +44 1473 830078
>>>> John.Birch@screensystems.tv | www.screensystems.tv |
>>>> https://twitter.com/screensystems

>>>>
>>>> Visit us at
>>>> Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand
>>>> 5E4-01
>>>>
>>>> P Before printing, think about the environment
>>>>
>>>> This message may contain confidential and/or privileged
>>>> information. If you are not the intended recipient you must not
>>>> use, copy, disclose or take any action based on this message or any
>>>> information herein. If you have received this message in error,
>>>> please advise the sender immediately by reply e-mail and delete
>>>> this message. Thank you for your cooperation. Screen Subtitling
>>>> Systems Ltd. Registered in England No. 2596832. Registered Office:
>>>> The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk,
>>>> IP6 0EQ

This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ