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

Decision on CfC: Comments on WebVTT

From: Janina Sajka <janina@rednote.net>
Date: Tue, 30 Jan 2018 09:35:51 -0500
To: Accessible Platform Architectures Administration <public-apa-admin@w3.org>
Cc: W3C WAI Accessible Platform Architectures <public-apa@w3.org>
Message-ID: <20180130143551.GD15026@rednote.net>

Only messages in support of this CfC have been received. Consequently,
it is agreed as a consensus decision of APA, and our comments will now be

The head of thread for this CfC is at:


Janina Sajka writes:
> Colleagues:
> This is a Call for Consensus (CfC) to the Accessible Platform
> Architectures (APA) Working Group on our review of the WebVTT
> specification as requested at:
> https://lists.w3.org/Archives/Member/w3c-archive/2017Dec/0107.html
> Please note these are comments following on work in response to PF-WB
> comments from 2015.
> Please note also that the draft comments below cover some similar issues present in our current
> CfC on TTML Profiles:
> http://lists.w3.org/Archives/Public/public-apa-admin/2018Jan/0000.html
> <Begin draft comments>
> *Item #1 Users of Magnification:*
> The bug-tracker indicates the following response(s):
>   * Snap to flag (assumption: snap-to-lines flag)
>      -> Concern: the concern is likely that if text is explicitly
> positioned on certain lines, there is potential that enlarging the text may
> lead to text growing outside the rendering area (e.g. text positioned in
> the top-most line), or successive lines may grow into each other.
>      -> Reply: First we have to understand that when content is enlarged,
> the video is typically enlarged together with the text. Therefore, the
> occurrance of this problem is rare. Secondly, there is a conflict between
> authoring requirements and rendering limitations. The browser rendering
> algorithm will [adjust?] as well as it can, but once text breaks out of the
> video rendering boundaries, there is not much it can do.
>      -> APA Response: APA recognizes the technical constraints noted here
> with regard to rendering limitations. Authoring Guidance recommendations
> should nonetheless indicate the potential of this problem, and urge content
> authors to strive to have captions (etc.) be no greater than 50% of the
> default width of the viewport (which would allow for a text increase of
> roughly 200% without clipping). APA notes that for low-vision users, even
> at full-screen, those users may still need to enlarge the caption text to
> meet their reading needs.
>   * Sizing of the captions rendering area
>      -> Concern: the concern is likely that the display area of captions is
> limited to the background area of the video element it is rendered onto and
> that with magnification the captions may go outside this rendering area.
>      -> Reply: The area outside the video element is no usable to render
> captions onto (think about full-screen mode, or if the video is on a Web
> page there is other content around the video element). Therefore, after
> having done all it can to try and retain visibility of all caption text,
> the browser will hit the limit of what it can do.
>      -> APA Response: APA again recognizes the technical constraints noted
> here with regard to rendering limitations. We once again recommend good
> authoring guidance to ensure that content authors are aware of the
> potential issue raised, so that authoring decisions regarding line-lengths
> and amount of caption text rendered on screen at any single instance can be
> made with this knowledge.
>   * Visibility of captions when text is zoomed
>      -> Concern: the concern is likely about what happens when the text is
> zoomed, but the video isn't.
>      -> Reply: If there are tools that do this, then you will hit the
> issues of overlapping text and disappearing text when hitting the
> boundaries of the rendering area faster than normal. However, it is
> unlikely that a tool would exist that zooms just the text and not the video
> element on screen. Normally, all content on a Web page is zoomed when
> magnification or zooming tools are in use.
>      -> APA Response: It was APA's understanding that one of the benefits
> of WebVTT was that it could be further styled by the content author using
> CSS. User stylesheets today provide the ability for users to modify and
> enlarge onscreen text, and tools and browser extensions exist today to
> accomplish this task.
> The presumption that video content would be zoomed to the same level of
> caption text is, from APA's perspective, unfounded and incorrect, and the
> emergent WCAG 2.1 specifically will have a new Success Criteria (Success
> Criterion 1.4.12 Text spacing -
> http://rawgit.com/w3c/wcag21/master/guidelines/index.html#text-spacing)
> which currently notes that caption files (when supplied as stand-alone
> time-stamped documents) are covered by this SC. Please also see:
> https://rawgit.com/w3c/wcag21/text-spacing/understanding/21/text-spacing.html
> > Normally, all content on a Web page is zoomed when magnification or
> zooming tools are in use.
> Respectfully, this is factually incorrect. Browser-based zoom traditionally
> operates like this, however other Assistive Technology tools may only zoom
> a part of the whole web page, or may only apply zoom to text (and/but not
> imagery). Some user-agents and platforms also allow for end-user font
> magnification (for example, on the Android platform, individual users can
> choose from different default font sizes, that are applied to all on-screen
> content.
> APA again recognizes the technical limitations noted here with regard to
> rendering limitations, and strongly recommends that appropriate authoring
> guidance to address all 3 related issues noted here be included (directly)
> in the Recommendation.
> ----------
> *Item #2: The spec should include feature explanations in plain language*
>      -> Reply: no change, we rely on external documents to provide an
> authoring guide.
>      -> APA Response: There are actually 2 responses here.
> The first is related to an on-going request from APA that W3C Technical
> Recommendations also include, when and where necessary, prose summaries in
> "plain english" that explain features and functions of the various parts
> of any given spec. The intent here is to explain what is happening with the
> technology in lay terms, rather than explain how to create content using
> the technology. (i.e.: don't just show an API [sic], explain it.) This
> remains an important request from APA, but is not a blocking issue.
> The second response is related to Authoring Guidance documents (referenced
> in your reply). Following up on the Bug Tracker, it shows a link to an
> authoring guidance document (
> https://docs.webplatform.org/wiki/concepts/VTT_Captioning), yet that URL
> returns a 404 today.
>    - Has this document been relocated elsewhere? If yes, can we please have
>    the reference URL. If no, does the WG plan on updating/recreating this
>    document? (This also ties-back to Item #1)
>    - The current WebVTT Working Draft (https://www.w3.org/TR/webvtt1)
>    currently has 'editorial guidance' as part of the normative specification
>    addressing privacy and security, and APA's request is that editorial
>    guidance for accessibility considerations also be provided in the same
>    fashion (i.e. directly in the Rec, as opposed to linking out.)
> APA would be please to assist in the review of any authoring guidance that
> emerges from the WebVTT WG.
> ----------
> *Item #3: Captions on the audio element*
>      -> Reply: fixed, explanations added.
>      -> APA Response: Thank you.
> APA trusts this meets your request, and we are happy to further elaborate
> on any of these issues as required.
> <End Draft Comments>
> *       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, Monday 29 January.
> APA Tracking Notes
> These comments reiterate requirements published in the W3C Note: Media
> Accessibility User Requirements (MAUR):
> http://www.w3.org/TR/media-accessibility-reqs/#captioning
> Inasmuch as similar comments to TTML have been Under an APA CfC, that TTML CfC will now be extended to expire with this CfC:
> http://lists.w3.org/Archives/Public/public-apa-admin/2018Jan/0000.html
> The WebVTT comments in this CfC were drafted for APA by John Foliot and are in sync with our
> TTML comments referenced above:
> http://www.w3.org/WAI/APA/track/actions/2162
> Further APA discussion is logged at:
> http://www.w3.org/2018/01/24-apa-minutes.html#item05
> 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, 30 January 2018 14:38:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:46 UTC