- From: David Singer <singer@apple.com>
- Date: Wed, 31 Jan 2018 11:10:17 -0800
- To: John Foliot <john.foliot@deque.com>
- Cc: Janina Sajka <janina@rednote.net>, Public TTWG List <public-tt@w3.org>, Silvia Pfieffer <silviapfeiffer1@gmail.com>, Accessible Platform Architectures Administration <public-apa-admin@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>
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