Re: [webvtt] APA Comments on TimedText/WebVTT

Greetings David and Silvia,

The three responses provided originated from Bugzilla Issues tracked here:
https://www.w3.org/wiki/TimedText/WebVTT_Wide_Review#Messages_sent_requesting_review_internally_to_the_W3C.2C_of_the_FPWD

and specifically:

   - Issue 1 - *Users of Magnification*:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=28509
   - Issue 2 - *The spec should include feature explanations in plain
   language*: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28510
   - Issue 3 - *Captions on the audio element*:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=28511

Silvia, I'm not seeing corresponding Issues in GitHub, so I can either a)
Create new GH issues, and load them up with what I have, or b) respond to
the original Bugzilla Issue (which apparently looks "live" still).

Hoping to clear this task from my desk today, your preference here is
greatly appreciated.

JF

On Wed, Jan 31, 2018 at 1:10 PM, David Singer <singer@apple.com> wrote:

> 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.
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion