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