- From: Michael Dolan <mdolan@newtbt.com>
- Date: Thu, 19 Jun 2014 08:40:10 -0700
- To: "'Timed Text Working Group'" <public-tt@w3.org>
I concur with John. Although SMPTE contemplated composite rendering of text and images (hence the source of the attribute name), the IMSC profile contributed by DECE explicitly forbids it. The main reason is that it notably complicates the rendering and decoder model, requires new control features, etc. The IMSC image profile does not support "background" images (despite the name of the SMPTE attribute that served the needed purpose). If there is another TTML application that needs compositing of text and image content, that is another profile, not this one. If there is an accessibility purpose solved by "alt", I support that as an optional element/attribute. But we should not conflate accessibility support with a major new feature such as compositing. For clarity the image extent is supposed to match the div extent. No scaling. No clipping. No black bars. Regards, Mike -----Original Message----- From: John Birch [mailto:John.Birch@screensystems.tv] Sent: Thursday, June 19, 2014 8:05 AM To: Nigel Megitt; Pierre-Anthony Lemieux 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 Nigel, A quick response while I work on modifying my proposed prose! Comments in line JB>> 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: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] Sent: 19 June 2014 10:48 To: John Birch; Pierre-Anthony Lemieux 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] I would add the following constraints to guide the edits to the extra wording: * The 'alt' data should be processable as TTML text (with IMSC text profile constraints) by implementations that can not present the graphics, e.g. because the external resource can not be fetched, or because an accessible representation is needed. >>JB I strongly disagree. The alt text is not intended to result in a visual representation. The alt text is intended to support an alternative presentation of the intention (meaning) of the text to those who cannot access a visual reproduction. * There should be sufficient information for the processor to resolve the author's preference for either image or text compared to the processor's capabilities and user preferences, and to present one or the other representation, or if we need to support a background image being used genuinely as the name suggests, being rendered behind foreground text, then to present both representations. >> JB Not applicable as dual presentation (on the same display) is never possible. Note as per my previous comments a simulataneous presentation of the image and the alt text through a non visual device (e.g. braille reader or text to speech reader) might be considered 'useful' so that sighted and non-sighted audience members can access the same presentation simultaneously (e.g. both 'watching' television together). ** If background images with foreground text drawn in front are to be supported the z-order must be computable, for example from implied or initial values. >> JB Again N/A. ** If background images with foreground text drawn in front are to be supported we will need to understand how this affects the HRM. >> JB Again N/A. I note in going through this thought process that the attribute name backgroundImage is almost certainly inappropriate since the intention is that it is the complete rendered background and foreground for a region. This is something we should address in TTML2 and IMSC2. >> JB Yes, I believe the name is inappropriate for both IMSC and SMPTE-TT. Pierre, to your point, yes, this is a parallel means of delivering text content, but should be subject to the same constraints as IMSC text profile. Otherwise anyone wanting to create an accessible presentation of subtitles/captions using IMSC would have to create two mechanisms, one for the text profile and one for the image profile, which is something we should avoid - we're trying to lower the barriers to accessible content not to erect new ones. >> JB Yes, but within the constraints of *not* supporting dual rendering... a constraint that I support. I've also spotted that there's also an editorial issue with 6.2.1 and 6.3 which apparently differ: 6.2.1 says that "the image is a div element ... that does not extend beyond the presented region", whereas 6.3 says that "the width and height of the region ... SHALL be equal to the width and height of the image..." - the first of these seems to suggest that the image can be smaller than the region whereas the latter clarifies that it shall not so. >> JB Not seen that but it does seem to imply a slight contradiction... Kind regards, Nigel On 19/06/2014 09:24, "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 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
Received on Thursday, 19 June 2014 15:40:51 UTC