W3C home > Mailing lists > Public > public-apa@w3.org > February 2018

Decision on CfC: Standing permission to publish Working Drafts of COGA Gap Analysis

From: Janina Sajka <janina@rednote.net>
Date: Tue, 20 Feb 2018 03:45:08 -0500
To: Accessible Platform Architectures Administration <public-apa-admin@w3.org>
Cc: W3C WAI Accessible Platform Architectures <public-apa@w3.org>
Message-ID: <20180220084508.GM2410@rednote.net>

Only messages of support for this proposal have been received. It is
therefore agreed to as a consensus decision of APA.

The head of thread for this CfC can be found here:



Janina Sajka writes:
> Colleagues:
> This is a Call for Consensus (CfC) to the Accessible Platform
> Architectures (APA) Working Group on a request from our Cognitive and
> Learning Disabilities (COGA) Task Force for standing permission to
> publish updated working drafts of their Gap Analysis. The FPWD of this
> documented is here:
> https://www.w3.org/TR/2017/WD-coga-gap-analysis-20171207/
> Note that the standing permission being requested applies only to
> updated Working Drafts of this document. COGA understands it will need
> explicit authorization from AG and APA before finalizing this document
> as a W3C Note.
> COGA has further agreed to produce a list of substantial changes
> to each version of the document published under this standing permission grant.
> Please also recall that the COGA Task ForceF is a joint Task Force of AG-WG
> and APA. A parallel CfC was conducted in the Accessible Guidelines
> (AG-WG) Working Group, though we failed to conduct our APA CfC on this
> question in the same timeframe as AG-WG--as had been our intent.
> https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/1126.html
> APA members who are also AG members and who responded to the AG CfC on
> this question should ALSO respond here.
> *       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, Sunday 18 February.
> Janina
> ------------------------------------------------------------------------------
> 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.
>    </draft-feedback>
>    Best regards,
>    Gottfried
>    -----Ursprüngliche Nachricht-----
>    Von: Accessible Platform Architectures Working Group Issue Tracker
>    [mailto:sysbot+tracker@w3.org]
>    Gesendet: Mittwoch, 18. Oktober 2017 09:29
>    An: public-apa@w3.org
>    Betreff: apa-ACTION-2152: Review ttml profiles for internet media
>    subtitles and captions 1.1 https://www.w3.org/tr/ttml-imsc1.1/
>    apa-ACTION-2152: Review ttml profiles for internet media subtitles and
>    captions 1.1 [5]https://www.w3.org/tr/ttml-imsc1.1/
>    [6]http://www.w3.org/WAI/APA/track/actions/2152
>    Assigned to: Gottfried Zimmermann
> References
>    1. https://www.w3.org/TR/ttml-imsc1.1/
>    2. https://www.w3.org/TR/ttml2/
>    3. https://www.w3.org/TR/ttml2/
>    4. https://www.w3.org/WAI/WCAG20/quickref/#visual-audio-contrast-without-color
>    5. https://www.w3.org/tr/ttml-imsc1.1/
>    6. http://www.w3.org/WAI/APA/track/actions/2152


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, 20 February 2018 08:46:29 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:03 UTC