[gui-talk] Ray Kurzweil teams with Baker & Taylor on new E-book reader

James Pepper b75205 at gmail.com
Fri Oct 23 20:09:11 UTC 2009


It takes time to do all of this, the hard part was inventing it and writing
the patent.  So the next step is to have it tested across platforms using
different screen readers, devices, and demonstrating the process
by independent blind experts and thats why I sent it to the AFB so they can
test it.  Sorry no timeline; this stuff is very new.   Sorry I am not a big
company that can roll this out on the spot, it is just me.

I have a big problem with the checklist software because they are after the
fact, where you change an existing document after it is made.  For instance
checking the alt text of buttons. Adobe and other software companies include
placeholder text in its buttons, and in Dreamweaver this placeholder
text which reads as "Button 1," will pass an accessibility test because it
is content that is placed in alt text location of a button. The webmaster is
supposed to change this text but they do not do it.  It describes the
button, so under the law it would be considered accessible.  But everyone
here who has confronted the countless number of "button ones" knows that it
is useless.

Checklists miss content, they are a diagnostic process after the document is
made.  You have to correct for accessibility when it would save everyone a
lot of time and trouble to just make it accessible as a fundamental part of
the program while you authoring the document.  I know there is a whole
industry to do this type of work after the document is made, but that adds
costs to the process and so accessibility is expensive.

Also those checklists make you go back and rewrite content over again when
you already wrote it once. If you make people write content over and over
again they are not going to do it.  You need to make content once, that is
accessible to all.  And if we are going to really make things accessible we
need for ordinary people who are not skilled in accessibility to make
content accessible and the only way to do that is to build it into the
system.

Sorry but in my process, JAWS is just another text to speech engine. In
fact, compensating for JAWS's unique instructions makes things more
complicated. The user using my process has control over their position in
the document, so they are not stuck using a screen reader like an 8 track
tape, they can move all around the document. So it adds that functionality
to a standard text to speech engine.  True, JAWS has more features right
now, but you will have to decide if the more features are worth it to you to
purchase JAWS in the future. Certainly it will take time to implement this
across platforms but JAWS needs some competition and I believe the goal of
accessible design is to create a world where you do not need JAWS, where
accessibility is the norm and not something unusual.

Also checklists miss content.  The only way to prove a document is
accessible is to actually use a screen reader and read the content. If
screen readers are free then people will use them to check their content.
Right now they cost a fortune and the learning curve is too much to check
their content.  Authors need to hear their content so they learn to write
better.  You need to check what you write so you can communicate to people
who are using screen readers and that has to be learned through
experience. This is not a technical issue, this is just writing. You and
I have skills in writing because of our experience with blindness, but most
people do not have that experience and that is a learning curve that must be
overcome!  So a free screen reader will help that process. English teachers
will have a field day!

And of course this works in any language that has a text to speech engine,
so we can do this worldwide. I tested it in French and Spanish and I am
laying it out to work in over 200 languages.  Technically it doesn't matter
which language is used, it is only limited by the translation efforts of
screen readers. I am having a bit of trouble with Malayalam, Oriya and
Farsi, but otherwise it is doing well.  Also, this will preserve culture
because we can do this in any language for the blind and for literacy.

This partial accessibility has been a big problem, where parts or even one
item on the page is accessible, it is deemed accessible and yet content is
missed!  I have seen this in person, where government officials claim a
document is accessible because you can enter your last name on a form and
yet the rest of the content is completely inaccessible. They just don't get
it!

Is a document legally valid if you cannot read all of it?  Is there a
contract?  Could you say that most government correspondence is not valid
because the blind cannot read all of the document? What about those tiny
fonts that you cannot scan?  Why is it your responsibility to determine what
is on the page when you are the receiver of the document, you didn't author
it, what if you did not comprehend the meaning?

The Social Security lawsuit is just the first step, we should demand that
all government documents be functionally accessible where all of the content
is read.  Partial accessibility should not be tolerated because there is no
meeting of the minds.  Partial Accessibility is Plessy V. Fergusson in
practice!

As I proceed I will keep you all updated.

James Pepper



More information about the GUI-Talk mailing list