Re: [webvtt] APA Comments on TimedText/WebVTT

> On Feb 2, 2018, at 6:01 , John Foliot <john.foliot@deque.com> wrote:
> 
> 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.

New GH issues would seem to be needed, with forward pointers from BugZilla and back-pointers from GH

BugZilla:  “Continued on GH In issue #xxx (linked)”
GH: “continuation of the discussion in BugZilla at <link>”

Thanks, much 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

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 2 February 2018 16:15:11 UTC