- From: Janina Sajka <janina@rednote.net>
- Date: Wed, 22 Feb 2017 13:38:44 -0500
- To: "White, Jason J" <jjwhite@ets.org>
- Cc: "lisa.seeman" <lisa.seeman@zoho.com>, Accessible Platform Architectures Administration <public-apa-admin@w3.org>
I should add that I believe Lisa's concerns, were they to be addressed by API, are not specific to this particular API, but would impose some kind of feature requirement on all W3C API work. I'm personally not convinced that API specifications are the correct vehicle to solve the identified problem, but I'm certainly open to discussing the concept. Meanwhile, we have an API specification which does not appear to address existing consensus a11y requirements, e.g. support for captions and for video descriptions. It strikes me we should communicate this message now, even as we take up the question of scoping W3C API specifications. Janina White, Jason J writes: > I think this can all be done (and more effectively) at the user interface level. I do not think APIs need to provide this information, as it can be inferred by the user interface designer who is building an adaptive interface. > > I do not support APA's making such requests in the absence of strong reasons for meeting these needs at the API level rather than in the design of specialized user interfaces for people with learning and cognitive disabilities, which the API already facilitates. > > > -----Original Message----- > > From: Janina Sajka [mailto:janina@rednote.net] > > Sent: Wednesday, February 22, 2017 11:54 AM > > To: lisa.seeman <lisa.seeman@zoho.com> > > Cc: Accessible Platform Architectures Administration <public-apa- > > admin@w3.org> > > Subject: Re: 48-Hour Call for Consensus (CfC): TV Remote Control API Comments > > > > OK, Lisa. Please come on a call so we can discuss. > > > > Lisa Seeman writes: > > > Hi Janinathat is not the use case i want > > > > > > > > > I want the API to include a place to say the common role/concept of a control. > > > For example - higher and lower > > > > > > > > > I also want for there to be a way to identify the 2 - 5 most critical > > > features > > > > > > > > > then AT THE USER END an application can simplify or adapt the > > > interface to make it understandable to coga usegroups > > > > > > > > > I see this as absolutely crucial > > > > > > All the best > > > > > > Lisa Seeman > > > > > > LinkedIn, Twitter > > > > > > > > > > > > > > > > > > ---- On Wed, 22 Feb 2017 16:35:53 +0200 Janina > > > Sajka<janina@rednote.net> wrote ---- > > > > > > Hi, Lisa: > > > > > > I'm befuddled trying to understand your point. Please help me out here. > > > > > > Is the following correct? > > > > > > You want to represent the concept of adjusting audio volume higher or > > > lower using some kind of symbology that doesn't use the very common > > > English remote control term: "Volume Control." I think I can > > > understand how there would be use cases for representing that concept > > differently. > > > For one thing it would need to be represented in the world's various > > > languages. > > > > > > Assuming the above is correct, I still don't see how that becomes a > > > comment on the API. It's not the role of the API to provide > > > alternative dictionaries of terms and symbols. Rather, it's the role > > > of Volume Control in this API to allow for audio volume to be raised > > > or lowered by some kind of user agent, in our case likely software > > > associated with a browser (or using browser technology) inasmuch as > > > we're talking about the www. > > > > > > If you want to get into how these concepts are standardized across > > > different symbol systems, I should probably point you to ISO where > > > they do exactly those kinds of standards for hardware devices. > > > > > > > > > So, what am I missing here? > > > > > > Janina > > > > > > > > > Lisa Seeman writes: > > > > Hi JaninaI might be missing something but I can not see how we can > > adapt something like volume control or temperature control and give it a symbol > > or text that the user understands. > > > > In other words i do not see that COGA's needs are met. Until then people > > will need assisted living or live in help much earlier then they would otherwise > > becauseof these gaps. > > > > > > > > > > > > Can you explain that use case if I am missing it? > > > > > > > > > > > > All the best > > > > > > > > Lisa Seeman > > > > > > > > LinkedIn, Twitter > > > > > > > > > > > > > > > > > > > > > > > > ---- On Tue, 21 Feb 2017 16:16:43 +0200 Janina > > > Sajka&lt;janina@rednote.net&gt; wrote ---- > > > > > Colleagues: > > > > > > > > This is a Call for Consensus (CfC) to the Accessible Platform > > > > Architectures (APA) Working Group on our review of the TV Remote > > > Control > API specification as detailed below. > > > > > > > > I have endeavored to incorporate such API related comments as > > > we've > recieved on an earlier draft comment beginning at: > > > > > > > > http://lists.w3.org/Archives/Public/public-apa/2017Feb/0019.html > > > > > > > > &lt;Begin Draft Comment&gt; > > The Accessible > > > Platform Architectures (APA) Working Group makes the > following > > > comments on the draft TV Control API specification at: > > > > > > > > https://www.w3.org/tr/tvcontrol-api/ > > > > > > > > We appreciate that an API for TV remote control could be utilized > > > for > enabling accessible alternative Web applications to provide > > > radio and TV > services to users with disabilities who may find it > > > difficult or > impossible to operate any user interface supplied > > > with a particular > hardware device. This is an inherent > > > accessibility strength for any API > that provides for sufficient > > > feature support. Regretably, we believe the > current TV Remote > > > Control API as currently defined lacks required > accessibility feature > > support. > > > > > > > > * alternative media support > > > > > > > > We would draw your attention to the multiple alternative media > > > formats > that are used by persons with disabilities as set forth > > > in our W3C Note > publication: "Media Accessibility User > > > Requirements (MAUR)" available > at: > > > > > > > > http://www.w3.org/TR/media-accessibility-reqs > > > > > > > > Our reading of the Tv Control API draft finds no way for users to > > > learn > of the presence of any MAUR identified alternative media > > > with any > particular TV content, nor any means to request display > > > of alternative > content. This is a fundamental accessibility > > > requirement on TV Controls > and we believe it must be factored into this > > specification. > > > > > > > > * Alternative Media on Second Screen Devices > > APA's > > > predecessor Working Group, Protocols and Formats WG provided use > > > > cases and requirements to the Second Screen Working Group on how > > > > alternative media might be directed to second screen devices. We > > > believe > support for directing alternative video, audio, and/or > > > text to secondary > devices, as described in the MAUR, is a > > > fundamental accessibility > requirement on TV Controls and should be > > supported in this API. > > > > > > > > * Legal Requirements > > > > > > > > The Federal Communications Commission (FCC) in the U.S. has > > > explicit > requirements on how alternative media are to be exposed to > > consumers. > > > > Developers should be flagged most especially on the requirement > > > that > captioning must be enableable by top level controls. These > > > FCC > requirements implement provisions of a U.S. law known as the > > > > "Twenty-First Century Communications and Video Accessibility Act" > > > as > explained by the FCC at: > > > > > > > > > > > https://www.fcc.gov/general/twenty-first-century-communications-and-vi > > > deo-accessibility-act-0#block-menu-block-4 > > > > > > > > The FCC's regulations pertinent to this specification were > > > published in > December 2016 in the document: "Accessibility > > > Requirements for > Television and Set-Top Box Controls, Menus, and > > Program Guides" > > > > available at: > > > > > > > > PDF: > > > https://apps.fcc.gov/edocs_public/attachmatch/DA-16-1416A1.pdf > > > > MS-Word: > > > https://apps.fcc.gov/edocs_public/attachmatch/DA-16-1416A1.docx > > > > > > > > Also relevant is the document "Display of Captioning on Equipment > > > Used > to View Video Programming" available at: > > > > > > > > > > > https://www.fcc.gov/consumers/guides/closed-captioning-display-require > > > ments-equipment#block-menu-block-4 > > > > > > > > &lt;End Draft Comment&gt; > > * ACTION TO TAKE > > > > > This CfC is now open for objection, comment, as well as > > > statements of > support via email. Silence will be interpreted as > > > support, though > messages of support are certainly welcome. > > > > > > > > If you object to this proposed action, or have comments > > > concerning this > proposal, please respond by replying on list to > > > this message no later > than 23:59 (Midnight) Boston Time, Tuesday 28 > > February. > > > > > > > > Janina > > > > > > > > > > > > -- > > > > > > > > Janina Sajka, Phone: +1.443.300.2200 > > > > sip:janina@asterisk.rednote.net > Email: janina@rednote.net > > > > > 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 > > > > > > > > > > > > > > > > > -- > > > > > > Janina Sajka, Phone: +1.443.300.2200 > > > sip:janina@asterisk.rednote.net > > > Email: janina@rednote.net > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Janina Sajka,Phone:+1.443.300.2200 > > sip:janina@asterisk.rednote.net > > Email:janina@rednote.net > > > > Linux Foundation Fellow > > Executive Chair, Accessibility Workgroup:http://a11y.org > > > > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) > > Chair, Accessible Platform Architectureshttp://www.w3.org/wai/apa > > > > > ________________________________ > > This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. > > > Thank you for your compliance. > > ________________________________ -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net 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
Received on Wednesday, 22 February 2017 18:39:15 UTC