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:14:42 +0000
To: 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: <D6963C18.53A34%nigel.megitt@bbc.co.uk>
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-col
>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:16:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 30 January 2018 15:16:14 UTC