RE: R29. Web application may only listen in response to user action

Yes, you  could do that, but then the application wouldn't be hands-free. 
Now probably isn't the time to start talking about approaches that would
enable us to address both requirements, I'm just pointing out that we should
be aware of a potential conflict. I think we should actually classify both
requirements as "should address", but note that there's an issue in our
requirements document. 

> -----Original Message-----
> From: Satish Sampath [mailto:satish@google.com]
> Sent: Friday, October 22, 2010 9:43 AM
> To: Deborah Dahl
> Cc: Bjorn Bringert; Dan Burnett; public-xg-htmlspeech@w3.org
> Subject: Re: R29. Web application may only listen in response to user
action
> 
> One possibility for R24 is that the end user performs an action on page
load
> and from then on using continuous speech input they can interact with the
> application in a hands-free mode. This could be a click on a button or
some
> other accessibility-friendly gesture.
> 
> Cheers
> Satish
> 
> 
> 
> On Fri, Oct 22, 2010 at 2:39 PM, Deborah Dahl <dahl@conversational-
> technologies.com> wrote:
> 
> 
> 	I see a possible conflict between requiring user action to enable
> speech
> 	recognition and R24. "End user should be able to use speech in a
> hands-free
> 	mode" if "user action" means doing something that requires use of
> the hands.
> 	I think both requirements are important but satisfying them both
> might
> 	require some thought.
> 
> 	From: public-xg-htmlspeech-request@w3.org
> 	[mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Satish
> Sampath
> 	Sent: Friday, October 22, 2010 7:24 AM
> 	To: Bjorn Bringert
> 	Cc: Dan Burnett; public-xg-htmlspeech@w3.org
> 	Subject: Re: R29. Web application may only listen in response to
user
> action
> 
> 
> 	User experience studies have also shown that end users have got
> used to
> 	clicking away any popup dialogs that come up when they are
> browsing the
> 	web.. common ones include phishing/malware warnings, download
> notifications
> 	etc. This is one of the reasons why browser vendors are moving
> towards
> 	in-page notifications for some of these where applicable, and
> requiring
> 	explicit user action for others. So I think this is a good
requirement to
> 	have.
> 
> 	The other side of this is that the web page should not be allowed to
> 	automatically initiate speech input/audio capture via an API call.
> 
> 	Cheers
> 	Satish
> 
> 	On Fri, Oct 22, 2010 at 12:18 PM, Bjorn Bringert
> <bringert@google.com>
> 	wrote:
> 	This requirement was motivated by privacy concerns. If the web
> 	application can start speech recognition at any time, it can
eavesdrop
> 	on a user.
> 
> 	An alternative to requiring user action would be to have a
permission
> 	dialog of some kind. As far as I understand, browser implementors
> 	would not like a proliferation of permission dialogs annoying their
> 	users.
> 
> 	/Bjorn
> 
> 	On Fri, Oct 22, 2010 at 1:06 AM, Dan Burnett <dburnett@voxeo.com>
> wrote:
> 	> Group,
> 	>
> 	> This is the first of the requirements to discuss and prioritize
based
> on
> 	our
> 	> ranking approach [1].
> 	>
> 	> This email is the beginning of a thread for questions, discussion,
> and
> 	> opinions regarding our first draft of Requirement 29 [2].
> 	>
> 	> After our discussion and any modifications to the requirement, our
> goal is
> 	> to prioritize this requirement as either "Should Address" or "For
> Future
> 	> Consideration".
> 	>
> 	> -- dan
> 	>
> 	> [1]
> 	> http://lists.w3.org/Archives/Public/public-xg-
> htmlspeech/2010Oct/0024.html
> 	> [2]
> 	>
> 	http://lists.w3.org/Archives/Public/public-xg-
> htmlspeech/2010Oct/att-0001/sp
> 	eech.html#r29 <http://lists.w3.org/Archives/Public/public-xg-
> htmlspeech/2010Oct/att-0001/sp eech.html#r29>
> 	>
> 	>
> 
> 
> 	--
> 	Bjorn Bringert
> 	Google UK Limited, Registered Office: Belgrave House, 76
> Buckingham
> 	Palace Road, London, SW1W 9TQ
> 	Registered in England Number: 3977902
> 
> 
> 
>

Received on Friday, 22 October 2010 15:08:22 UTC