Re: PFWG review of SCXML

Thank you for your comments on the SCXML specification.  We agree that the accessibility requirements that you present are desirable in applications, but doubt that they can be built in to a general-purpose control language like SCXML.  For example, you suggest that there be a standardized digit sequence for reaching a human operator.  However, SCXML is used in contexts where there is no user and no concept of operator.   For example, we have received feedback from someone who was using it for physics simulations.  The concept of transferring to an operator certainly makes sense in certain applications that can be built with SCXML,  and the language certainly allows for it to be implemented,  but it is no more part of the core language than it would be part of Java or C++.

The standards for transferring to an operator and for easy error recovery seem to us to belong in a set of guidelines for application developers.  These guidelines would hold for telephony interface applications in general, whether they were written in Java, C++, or SCXML.   All that we can require of the underlying languages is that they make it possible to follow such guidelines, and we are confident that SCXML does.

Please let us know if this response is satisfactory to you.  If we do not hear from you by Nov 8, we will assume that it is.

Thank you
Jim Barnett



Below are comments prepared by the Protocols and Formats Working Group

on "State Chart XML (SCXML): State Machine Notation for Control

Abstraction" Last Call Working Draft of 1 August 2013

http://www.w3.org/TR/2013/WD-scxml-20130801/. Consensus to send as PF

comments is archived at

https://www.w3.org/2013/10/16-pf-minutes.html#item02.



This is an unusual review as we are not talking about accessibility as a

specific "this is an inaccessible feature" however, but the issues,

although more global, are just as important. Overall we are concerned

with how people with hearing, speech and cognitive impairments are going

to be affected by these applications and what requirements are necessary

so that they can be used by people with different user scenarios. For

example, speach trigered applications will need an option to type text

etc. In the mean time we suggest the following:

*

Issue one.* We would like to see a standard way to reach a human

operator for additional assistance and accessibility support.

Many people a struggle with critical services and help because of

complex phone answering systems. People with even mild hearing, speech

or cognitive challenges are especially disadvantaged and can be excluded

from these services.



As many emergency and critical services are now using these automated

answering systems, we need to make them as easy as possible to use on

any phone. Further, people abilities vary and deteriorate at times

stress or of ill health. People therefore need to be familiar and

comfortable with a standard way to reach an operator, so that they can

easily get service in times of stress or panic. We therefore propose to

standardize how a user can reach a human on all phone systems. We

believe this would make automated phone systems usable by as many people

as possible.



We propose that a digit or combination (such as the "zero" digit) be

standardize for reaching a human operator on all phone systems with

automatic menus. On any answering system, pressing a "0" would take you

to a human operator.



For example if the zero digit was standardized to reach a human, then in

any conformant system:



  * a, At any time on any system "0" will take the user to a human

    operator,

  * b, the "zero" digit can not be assigned for anything else and hence

    can not support a follow on menu, and

  * c, in every system file there is a default extension for the "zero"

    digit identified, without which the file is invalid and will not

    work at all.





Anecdotal evidence: Places that I have not managed to reach a human

operator after five attempts include the police and my doctors

office.Typically it takes me three of four attempts to reach the right

extension at my health service!



*Issue two*. We suggest standardizing error recovery from the user

perspective.

With these systems often people with disabilities are more likely to

make errors. We then get thrown off the line (see above ) and need to

start again. There should be a easy way to recover from an error, such

as when ever there is an error the user has an option to either



  * return to the main menu ,

  * the previous menu or

  * a human operator for help (most important)



FYI we are putting together a task force to addressees accessibility and

cognitive disabilities. If this is of interest to any of your members

please let us know!

--



Michael Cooper

Web Accessibility Specialist

World Wide Web Consortium, Web Accessibility Initiative

E-mail cooper@w3.org<mailto:cooper@w3.org?Subject=Re%3A%20PFWG%20review%20of%20SCXML&In-Reply-To=%3C525EBB5A.20105%40w3.org%3E&References=%3C525EBB5A.20105%40w3.org%3E> <mailto:cooper@w3.org<mailto:cooper@w3.org?Subject=Re%3A%20PFWG%20review%20of%20SCXML&In-Reply-To=%3C525EBB5A.20105%40w3.org%3E&References=%3C525EBB5A.20105%40w3.org%3E>>

Information Page <http://www.w3.org/People/cooper/>