Re: [webvtt] APA Comments on TimedText/WebVTT

Since our response was in an issue, I assume we can trace forward from there. All the issues that were moved from BugZilla have a forward link into the GH issue (I think).

Yes, the request for review was in email, but the summary is in a wiki, and the discussions in issue/bug trackers…


> On Jan 31, 2018, at 11:07 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> 
> Hi John, Janina, David,
> 
> The issues should go into https://github.com/w3c/webvtt/issues with
> links back to any older issues that you may be referencing.
> 
> Thank you so much for helping sort through this - I too find the
> response a little difficult to decipher - please add as many links to
> the issues and specs you're reffering to, so we can get the issues
> resolved. Note that the latest version of the spec is at
> https://w3c.github.io/webvtt/ .
> 
> Kind Regards,
> Silvia.
> 
> 
> On Thu, Feb 1, 2018 at 5:53 AM, John Foliot <john.foliot@deque.com> wrote:
>> Hi David,
>> 
>> Happy to take up that task, while also noting that your request for
>> comment/review never indicated a specific response mechanism, and came to
>> APA as an email request
>> (https://lists.w3.org/Archives/Member/w3c-archive/2017Dec/0107.html), and so
>> we (I) responded to that email.
>> 
>> Does your WG have a preferred location for those responses? Would you like
>> me to respond to existing issues in your GitHub repro (pointer(s) please),
>> or create new issues? A bit of focused guidance here would be helpful, and
>> I'll get this taken care of ASAP.
>> 
>> Thanks!
>> 
>> JF
>> 
>> On Tue, Jan 30, 2018 at 11:34 AM, David Singer <singer@apple.com> wrote:
>>> 
>>> 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.
>>> 
>>> 
>> 
>> 
>> 
>> --
>> John Foliot
>> Principal Accessibility Strategist
>> Deque Systems Inc.
>> john.foliot@deque.com
>> 
>> Advancing the mission of digital accessibility and inclusion

David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 31 January 2018 19:13:00 UTC