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

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

Received on Wednesday, 22 February 2017 16:51:37 UTC