Subject: RE: [Speechsc] Re: I-D ACTION:draft-ietf-speechsc-reqts-04.txt

From: "Daniel Burnett" <[email-masked]>
Date: Wed, 16 Jul 2003 07:28:49 -0700

Guido,

Maybe I don't understand this completely, but are you suggesting that an application using SPEECHSC would be acceptable if the organization deploying it also had a non-speech equivalent but not otherwise?  Although most organizations deploying speech already have web (graphical) access, a company focused on telephony-only access as their business might find this requirement overly restrictive.

This is not a protocol issue, but a protocol use issue.  Does it really belong in the definition of the protocol?

-- Dan Burnett
Nuance Communications

> -----Original Message-----
> From: Guido Gybels [mailto:[email-masked]]
> Sent: Friday, June 13, 2003 5:35 AM
> To: [email-masked]
> Cc: James Hamlin; Mike Spanner; [email-masked]
> Subject: [Speechsc] Re: I-D ACTION:draft-ietf-speechsc-reqts-04.txt
> 
> 
> All,
> 
> <<A New Internet-Draft is available from the on-line 
> Internet-Drafts directories. This draft is a work item of the 
> Speech Services Control Working Group of the IETF.>>
> 
> <<Filename	: draft-ietf-speechsc-reqts-04.txt>>
> 
> Based on the previous discussions, can I suggest we replace 
> 3.9 with the following:
> 
> "3.9 Users with disabilities
> 
> The SPEECHSC framework must have sufficient capabilities to 
> address the critical needs of people with disabilities. In 
> particular, the set of requirements set forth in RFC3351 [4] 
> MUST be taken into account by the framework. It is also 
> important that implementers of SPEECHSC clients and servers 
> be cognizant that some interaction modalities of SPEECHSC may 
> be inconvenient, or simply inappropriate for disabled users. 
> Hearing-impaired individuals may find TTS of limited utility. 
> Speech-impaired users may be unable to make use of ASR or 
> SI/SV capabilities. Therefore, systems employing SPEECHSC 
> MUST provide alternative interaction modes or avoid the use 
> of speech processing entirely."
> 
> And some spelling issues:
> 
> Page 3, justbefore 2.1: replace "decompostion" with "decomposition"
> Page 14, 9.3, replace "vulnerabilties" with "vulnerabilities" 
> 
> Best regards,
> 
> Guido
> 
> 
> 
> Guido Gybels
> Director of New Technologies
> 
> RNID, 19-23 Featherstone Street
> London EC1Y 8SL, UK
> Tel +44(0)20-7294 3713
> Fax +44(0)20-7296 8069
> 
> 
> 
> 
> **************************************************************
> **********
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom they are addressed. Any views or opinions expressed
> are solely those of the author and do not necessarily represent
> RNID policy.
> 
> If you are not the intended recipient you are advised that any
> use, dissemination, forwarding, printing or copying of this
> email is strictly prohibited.
> 
> If you have received this email in error please notify the RNID
> Helpdesk by telephone on: +44 (0) 207 296 8282.
> 
> The Royal National Institute for Deaf People  
> Registered Office 19-23 Featherstone Street 
> London EC1Y 8SL No. 454169 (England)
> Registered Charity No. 207720
> **************************************************************
> **********
> 
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Guido Gybels <[email-masked]>
Date: Wed, 16 Jul 2003 15:47:07 +0100

Daniel,

<<Maybe I don't understand this completely, but are you 
suggesting that an application using SPEECHSC would be 
acceptable if the organization deploying it also had a non-
speech equivalent but not otherwise?>>

First of all, the wording I suggested was quite mildly 
formulated. I'm not going to get into a lengthy debate 
here, but I respectfully point to both the ADA in the US 
and the DDA in the UK: if you, as a service provider, 
create services/products, you have a *legal* obligation to 
make reasonable adjustment to make that accessible to 
people with disabilities. The fact that few people in the 
industry are aware of this obligation doesn't change it.

<<This is not a protocol issue, but a protocol use issue.  
Does it really belong in the definition of the protocol?>>

There have been some questions about this, and I'm open to 
options, but it seems to me that what we are saying here, 
i.e. that if you implement this protocol to deliver 
services to people, you are well advised to take into 
consideration the needs of people with disabilities does 
not look out of scope to me. If you have a better solution 
for where to put this, by all means do suggest it.
I sure hope the suggestion is not to just ignore people 
with disabilities.

Guido

Guido Gybels