Re: [webvtt] APA Comments on TimedText/WebVTT

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