W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > October 2011

Speech-enabled form filling example

From: Charles Hemphill <charles@everspeech.com>
Date: Wed, 26 Oct 2011 23:24:42 -0700
To: <public-xg-htmlspeech@w3.org>
Message-ID: <03a101cc9471$217c20a0$647461e0$@everspeech.com>
Hi Everyone,


On the last call I mentioned that we have an example that shows
speech-enabled form filling.  This is a 60-second Flash demo at


A few quick notes:

.         This is only one of many possible approaches for interacting with
a speech-enabled form.

.         This demo addresses a commercial rather than a consumer
application with the focus on direct, rapid data entry with high accuracy.

.         The user's hands are busy operating equipment while entering data.

.         This demo is approaching 10 years old and has gone through several
implementation approaches.

.         This started with a JavaScript API and has morphed into a fully
declarative tag-based API.

.         Tags are used for the <input type="text"> boxes to associate the
appropriate grammars.

.         Grammars are activated/deactivated by the User Agent as focus

.         Most other elements require no modification, but it is possible to
influence vocabulary and pronunciation as needed.

.         I apologize in advance for this demo if you're a vegetarian!


The "Day 2 Procedure" page has a good sampling of HTML elements.  The markup
for "Kidney Fat" follows:


            <label for="KIDNEY_FAT_id">Kidney Fat</label>
              <input type="text" size="6" maxlength="4"
                     name="KIDNEY_FAT" id="KIDNEY_FAT_id" value=""
                     onchange="validateField(this, true);" />


This is obviously isomorphic to approaches that we've discussed.  The
grammar here is builtin/generated, but could be any SRGS.  The JavaScript
here is for text-input validation and could be removed given HTML5
validation mechanisms.


We also support the "for" attribute to relate a grammar to an <input> tag
given an ID.  The wrapping approach supports a direct association.  When
cut-and-paste is used, this avoids bugs if a developer forgets to match the
value of the "for" attribute with the new ID.  This also keeps symmetry with
the existing <label> tag so developers can always know that the "for"
attribute is optional with wrapping.


This is a relatively simple, yet fully useful example.  The point is that
many cases can be covered with a declarative tag.  The most recent proposals
support this approach, but there was a desire to see a use case.


We have more complex Web applications that are also fully declarative from a
markup perspective.   The JavaScript used to change visibility and focus for
the GUI naturally affects the current speech context.  No extra code is
needed to track a state model or keep speech in synch with the GUI.


Of course more can be done with a JavaScript speech API, but it gets
relatively complex quickly and is needed much less than one might think.


Best regards,


Received on Thursday, 27 October 2011 06:24:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:51 UTC