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

Re: [imsc1.1] Comments from APA

From: Janina Sajka <janina@rednote.net>
Date: Tue, 30 Jan 2018 12:17:00 -0500
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: "public-tt@w3.org" <public-tt@w3.org>, Accessible Platform Architectures Administration <public-apa-admin@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>
Message-ID: <20180130171700.GI16383@rednote.net>
Thank you, Nigel. We look forward to doing our best to be helpful going
forward.

Janina

Nigel Megitt writes:
> 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
> >>
> >>
> >
> >
> 

-- 

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 17:18:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 30 January 2018 17:18:07 UTC