- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 31 Jan 2018 12:53:32 -0600
- To: David Singer <singer@apple.com>
- Cc: Janina Sajka <janina@rednote.net>, public-tt@w3.org, Accessible Platform Architectures Administration <public-apa-admin@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>
- Message-ID: <CAKdCpxys8LuVhYO04wuat4YpDG=be-5VakrWWUAdoR5YViuiww@mail.gmail.com>
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 18:57:11 UTC