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

So, we can schedule a time to discuss. You'l recall we meet Wednesdays
at Noon Boston. Our next call is 8 March due to the fact that we're
taking a CSUN break.

Do you want to schedule a conversation on the 8th?

Janina

Lisa Seeman writes:
> 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 
>  
>  
> 
> 
> 
> 
> 
> 

-- 

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 Thursday, 23 February 2017 14:54:29 UTC