- 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 http://www.everspeech.com/demos/FormFillingAnnotated/. 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 changes. . 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> <evsp:grammar src="evsp:GrmInteger?min=0;max=0;minDec=2;maxDec=2" type="application/srgs+xml"> <input type="text" size="6" maxlength="4" name="KIDNEY_FAT" id="KIDNEY_FAT_id" value="" onchange="validateField(this, true);" /> </evsp:grammar> 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, Charles
Received on Thursday, 27 October 2011 06:24:46 UTC