Re: 48-Hour Call for Consensus (CfC): TV Remote Control API Comments

Sorry I missed the call. I had a conflict

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Wed, 22 Feb 2017 18:53:43 +0200 Janina Sajka<janina@rednote.net> wrote ---- 

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<janina@rednote.net> 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 
> > 
> > <Begin Draft Comment> 
> > 
> > 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-video-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-requirements-equipment#block-menu-block-4 
> > 
> > <End Draft Comment> 
> > 
> > * 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 Architectures    http://www.w3.org/wai/apa