W3C home > Mailing lists > Public > public-tt@w3.org > January 2018

Re: [imsc1.1] Comments from APA

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Tue, 30 Jan 2018 15:38:47 +0000
To: Nigel Megitt <nigel.megitt@bbc.co.uk>, Janina Sajka <janina@rednote.net>, "public-tt@w3.org" <public-tt@w3.org>
CC: Accessible Platform Architectures Administration <public-apa-admin@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>
Message-ID: <D696414A.53A48%nigel.megitt@bbc.co.uk>
Dear Janina,

Following this, I have raised each comment individually for tracking
purposes at:

https://github.com/w3c/imsc/issues/315

https://github.com/w3c/imsc/issues/316

https://github.com/w3c/imsc/issues/317

https://github.com/w3c/imsc/issues/318

https://github.com/w3c/imsc/issues/319

https://github.com/w3c/imsc/issues/320

https://github.com/w3c/imsc/issues/321


You (and all) are welcome to follow and participate in the discussion
there, otherwise we will discuss the issues, arrive at a WG disposition
for each comment and request your comments on those dispositions.

Kind regards,

Nigel




On 30/01/2018, 15:14, "Nigel Megitt" <nigel.megitt@bbc.co.uk> wrote:

>Dear Janina,
>
>Thank you for sending these review comments. I will file each comment as a
>separate issue on our GitHub repository w3c/imsc for the purpose of
>continuing the conversation.
>
>Kind regards,
>
>Nigel
>
>(Chair, TTWG)
>
>
>On 30/01/2018, 14:55, "Janina Sajka" <janina@rednote.net> wrote:
>
>>Colleagues:
>>
>>The Accessible Platform Architectures (APA) Working Group has reviewed
>>your FPWD and offers our comments below.
>>
>>According to APA process, the formal APA decision on these comments is
>>logged at:
>>http://lists.w3.org/Archives/Public/public-apa-admin/2018Jan/0008.html

>>
>>
>>Janina Sajka, APA Chair
>>
>><Begin comment>
>>
>>1.	While we appreciate that TTML Profiles for Internet Media Subtitles
>>and Captions 1.1 <https://www.w3.org/TR/ttml-imsc1.1/>  is depending on
>>Timed Text Markup Language 2 (TTML2) <https://www.w3.org/TR/ttml2/> , it
>>should still include an introduction that guides the reader to a better
>>understanding of its content.  Such an introduction could respond to the
>>following questions:
>>
>>a.	Why are profiles needed for text-only and image-only
>>captions/subtitles?
>>b.	What are typical use cases for a image-only captions/subtitles?
>>c.	What is the purpose of a presentation processor, and a transformation
>>processor?
>>
>>2.	There is a general issue with the way that an author specifies layout
>>characteristics of captions and subtitles, such as font size, font
>>family, line height, background and positioning.  The spec describes the
>>approach of the author specifying a 昆fixed layout昌 for captions and
>>subtitles that the user cannot change.  However, it must be possible for
>>the user to overwrite the author易s choice of font size, or background
>>color, for example. This is necessary for accessibility reasons, in the
>>same way that browsers allow the user to change font size and background
>>color.  How can we find a good solution for these conflicting interests
>>between author and user?  We would like to get into a discussion with you
>>on this issue. 
>>
>>3.	Section 2 Documentation Conventions (applies also to Timed Text Markup
>>Language 2 (TTML2) <https://www.w3.org/TR/ttml2/>  section 2.3). For
>>accessibility of the spec, information such as whether an element is
>>deprecated or obsoleted should not be indicated by color (or background
>>color) alone (cf. WCAG 2.0 SC 1.4.1
>><https://www.w3.org/WAI/WCAG20/quickref/#visual-audio-contrast-without-co

>>l
>>or> ). 
>>
>>4.	Section 5.1 General. The method of associating a text profile document
>>instance with an image profile document instance should be specified for
>>interoperability reasons, and not be left open to the specific
>>implementation.  Also, the association should be in both ways, i.e. also
>>from the image profile document instance to the text profile document
>>instance.
>>
>>5.	Section 6 Supported Features and Extensions. All font-related features
>>are prohibited for the image profile. This seems to be an unnecessary
>>restriction if the image profile contains images in SVG format which
>>could be rendered differently based on the author易s choice of font
>>characteristics.
>>
>>6.	Section 7.7.3 itts:forcedDisplay. This seems like a temporary
>>solution. Wouldn易t it be better to define semantic layers of information
>>that each could be made visible and invisible at runtime as appropriate
>>for the user?  For example, the user may want to see either speech-only
>>(subtitles), narration speech only (parts of subtitles), foreign-language
>>speech-only (parts of subtitles) or any combination of them.
>>
>>7.	Section 7.7.4 itts:altText.  While we see this feature as useful for
>>accessibility purposes, it should be mandatory for images rather than
>>recommended only. As mentioned in the spec, one could take the pertaining
>>text passage from the text profile document instance 〝 but (1) an
>>accompanying text profile is not required, and (2) the alternative text
>>for the image could be different from the textual caption. Therefore, the
>>itts:altText element should always be specified, but it should be empty
>>for decorative images (not clear if a 昆decorative image昌 used as a
>>caption makes sense anyway). By requiring an itts:altText for every
>>image, but allowing for an empty element in case of a decorative image,
>>we would align it with the alt attribute in HTML5 for images.
>>
>><End Draft Comment>
>>
>>*       ACTION TO TAKE
>>
>>This CfC is now open for objection, comment, as well as statements of
>>support via email. Silence will be interpreted as support, though
>>messages of support are certainly welcome.
>>
>>If you object to this proposed action, or have comments concerning this
>>proposal, please respond by replying on list to this message no later
>>than 23:59 (Midnight) Boston Time, Tuesday 23 January.
>>
>>Janina
>> 
>> APA Tracking Notes
>>
>>apa-ACTION-2152:
>> Assigned to: Gottfried Zimmermann
>>https://www.w3.org/tr/ttml-imsc1.1/

>>
>>Draft comments by Gottfried:
>>http://lists.w3.org/Archives/Public/public-apa/2017Nov/0008.html

>>
>>
>>-------------------------------------------------------------------------
>>-
>>----
>>
>>Janina Sajka
>>
>>Linux Foundation Fellow
>>Executive Chair, Accessibility Workgroup:	http://a11y.org

>>
>>The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
>>Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

>>
>>> > 
>>   Here is my proposed feedback to the Timed Text Working Group:
>>
>>
>>   <draft-feedback>
>>
>>
>>    1. While we appreciate that [1]TTML Profiles for Internet Media
>>       Subtitles and Captions 1.1 is depending on [2]Timed Text Markup
>>       Language 2 (TTML2), it should still include an introduction that
>>       guides the reader to a better understanding of its content.  Such
>>       an introduction could respond to the following questions:
>>
>>    a. Why are profiles needed for text-only and image-only
>>       captions/subtitles?
>>    b. What are typical use cases for a image-only captions/subtitles?
>>    c. What is the purpose of a presentation processor, and a
>>       transformation processor?
>>
>>
>>    2. There is a general issue with the way that an author specifies
>>       layout characteristics of captions and subtitles, such as font
>>       size, font family, line height, background and positioning.  The
>>       spec describes the approach of the author specifying a 昆fixed
>>       layout昌 for captions and subtitles that the user cannot change.
>>       However, it must be possible for the user to overwrite the
>>author易s
>>       choice of font size, or background color, for example. This is
>>       necessary for accessibility reasons, in the same way that browsers
>>       allow the user to change font size and background color.  How can
>>       we find a good solution for these conflicting interests between
>>       author and user?  We would like to get into a discussion with you
>>       on this issue.
>>
>>
>>    3. Section 2 Documentation Conventions (applies also to [3]Timed Text
>>       Markup Language 2 (TTML2) section 2.3). For accessibility of the
>>       spec, information such as whether an element is deprecated or
>>       obsoleted should not be indicated by color (or background color)
>>       alone (cf. [4]WCAG 2.0 SC 1.4.1).
>>
>>
>>    4. Section 5.1 General. The method of associating a text profile
>>       document instance with an image profile document instance should
>>be
>>       specified for interoperability reasons, and not be left open to
>>the
>>       specific implementation.  Also, the association should be in both
>>       ways, i.e. also from the image profile document instance to the
>>       text profile document instance.
>>
>>
>>    5. Section 6 Supported Features and Extensions. All font-related
>>       features are prohibited for the image profile. This seems to be an
>>       unnecessary restriction if the image profile contains images in
>>SVG
>>       format which could be rendered differently based on the author易s
>>       choice of font characteristics.
>>
>>
>>    6. Section 7.7.3 itts:forcedDisplay. This seems like a temporary
>>       solution. Wouldn易t it be better to define semantic layers of
>>       information that each could be made visible and invisible at
>>       runtime as appropriate for the user?  For example, the user may
>>       want to see either speech-only (subtitles), narration speech only
>>       (parts of subtitles), foreign-language speech-only (parts of
>>       subtitles) or any combination of them.
>>
>>
>>    7. Section 7.7.4 itts:altText.  While we see this feature as useful
>>       for accessibility purposes, it should be mandatory for images
>>       rather than recommended only. As mentioned in the spec, one could
>>       take the pertaining text passage from the text profile document
>>       instance 〝 but (1) an accompanying text profile is not required,
>>       and (2) the alternative text for the image could be different from
>>       the textual caption. Therefore, the itts:altText element should
>>       always be specified, but it should be empty for decorative images
>>       (not clear if a 昆decorative image昌 used as a caption makes sense
>>       anyway). By requiring an itts:altText for every image, but
>>allowing
>>       for an empty element in case of a decorative image, we would align
>>       it with the alt attribute in HTML5 for images.
>>
>>   </end comments>
>>
>>
>>-- 
>>
>>Janina Sajka
>>
>>Linux Foundation Fellow
>>Executive Chair, Accessibility Workgroup:	http://a11y.org

>>
>>The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
>>Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

>>
>>
>
>

Received on Tuesday, 30 January 2018 15:40:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 30 January 2018 15:40:06 UTC