W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2003

Re: JAWS for Windows for FREE? Lets give a try!

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Tue, 2 Sep 2003 17:50:44 -0500
To: w3c-wai-ig@w3.org
Cc: Daniel Dardailler <danield@w3.org>
Message-ID: <OFA246A1A5.EB1BE280-ON86256D95.00781725-86256D95.007D9596@us.ibm.com>





Matt wrote:
> ...Web authors need the _output_ of JAWS.
>
> Instead of asking screen reader and voice browser vendors
> to give away the farm, why not ask them to create a Web-based
> service to emulate what their tool speaks to the user?
> You don't need the text-to-speech engine or the user
> interface; in fact, it would probably hinder you, since
> reading is faster for most people than speech. You need a
> textual representation of what JAWS or Window-Eyes or
> Home Page Reader puts out.
>
> As long as these folks don't consider what goes into their
> text-to-speech engine to be a trade secret, I think this
> is a reasonable (and minimally-invasive) request to make.

Matt, a screen reader is made up of several main parts, namely the
text-to-speech engine, the screen reading engine and the user interface.
What the screen reader does to create the string of text that goes to the
text-to speech engine is the key value of the screen reader.  It is the
largest part of the value of the product.  It is the part that does have
many patents - not the actual text, but the algorithms that process the
DOM, MSAA, and/or off-screen model and then creates the strings of text.
All of these strings of output also depend on the user's input, which
navigation keys they just pressed, what mode or configuration they are in,
where did they just come from, etc.  So it's not as simple as your post
implies.  Yes we should consider making the text-to-speech engine optional,
but the user interface and screen reading engine are required.

For example, IBM Home Page Reader does work (shows all text spoken) without
turning on the speakers.  And HPR has an option to save the text view of
the page.  What HPR would speak if the page is just read - which is very
similar to what Lynx would show, is what is saved to the text file.  But if
you tab from form field to input filed, you will * also * see and hear the
label read;   if you navigate the table, you will * also * see and hear the
appropriate column and row heading information, neither of which you would
see in the plain text view of the page.  It's kind of just in time
information that is the job of the browser/screen reader to render.  We
wouldn't always want tool tips turned on all the time would we?   They
should only show up when moving the mouse or asking for additional
contextual information.

> But I can assure you none of them are going to give away thousands of
copies of their software.

Actually the screen reader vendors do basically that, in time-out versions.
These are full function versions of JAWs, WindowEyes, and IBM HPR that many
employed and paid web developers are using, temporarily, for testing.  I
know that some are buying copies of IBM Home Page Reader so they avoid the
hassle of time out versions.  I will also take back the idea of a
non-speaking version of IBM HPR (minus the text-to-speech engine) that
might even be less expensive for developers.

However, to make the web page/application truly accessible and meet
standards - I need a free screen reader, a free web accessibility checker,
a free web accessibility repair tool, and still time to do some manual
rendering in some of the popular free browsers and players.

What I think is needed more than free screen readers are example web pages
(test suites) that screen reader vendors, authoring tool manufactures, web
accessibility checkers/repairers, and web developers can compare against.
The techniques are a start, just too small of fragments.  We need page
examples of a few different versions of navigation, forms, tables and
combinations of these that make up web applications used on today's sites.
What I don't see is a model (business incentive) for anyone to produce or
contribute it to the W3C.  Maybe the W3C could charge screen reader
vendors, authoring tool manufacturers, web accessibility checkers, and web
developers a fee for accessing such a standard test suite to recoup the
cost of producing it.  Anyway, an idea that is now off thread.

Regards,
Phill Jenkins
Received on Tuesday, 2 September 2003 18:50:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:10 GMT