Re: [webvtt] APA Comments on TimedText/WebVTT

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

Received on Wednesday, 31 January 2018 19:08:30 UTC