Re: [webvtt] APA Comments on TimedText/WebVTT

The W3C has been using various issue/bug tracking systems for decades; to be usable or get addressed, these comments need to be filed in the appropriate issue tracker against the appropriate existing (or new, if the comment is new) issues. Previously we used W3C issue tracking, then BugZilla, and now like most groups, we use GitHub issues.  Could you disentangle these and file the comments in the appropriate place, please?

Thanks

> On Jan 30, 2018, at 7:55 , Janina Sajka <janina@rednote.net> wrote:
> 
> Colleagues:
> 
> As requested here:
> https://lists.w3.org/Archives/Member/w3c-archive/2017Dec/0107.html
> 
> And further logged at:
> https://www.w3.org/wiki/TimedText/WebVTT_Wide_Review#Messages_sent_requesting_review
> 
> The Accessible Platform Architectures (APA) Working Group has reviewed
> TimedText/WebVTT and offers the following comments.
> 
> According to APA process, the formal APA decision on these comments is
> logged at:
> http://lists.w3.org/Archives/Public/public-apa-admin/2018Jan/0009.html
> 
> Janina Sajka, APA Chair
> 
> <Begin 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 pleased 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 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
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 30 January 2018 17:35:52 UTC