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

Received on Tuesday, 17 June 2014 16:50:30 UTC