Re: PFWG review of SCXML

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: PFWG review of SCXML

Jim Barnett-5

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 Consensus to send as PF
comments is archived at
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
  * 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
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 [hidden email] <mailto:[hidden email]>
Information Page <>