- 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>
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