At Thu, 12 Apr 2001 05:39:21 +0200, tvalusek at vs.inext.cz (Tomas Valusek) 
wrote:

>
>Hello,
>
>is it possible to create applications in Squeak without using a mouse,
> ie.
>using only the keyboard? How to use a speech synthesizer from Squeak 
>in
>Windows?
>
>Tomas Valusek

I have been giving a bit of thought to accessibility in Squeak. Initially 
I thought I would address the issue of making the documentation that we 
produce in Squeak accessible to visually impaired users. At the moment I 
am very much a Squeak beginner so if some of the points that I make are 
wrong please correct me.

At the moment I see that there are four main documentation methods associated 
with Squeak: HTML, Swiki, Text and BookMorph. I think that HTML and Swikis 
should be accessible using an accessible web browser (has Scamper been hooked 
up to the Squeak text-to-speech engine?). Within the Squeak image Text and 
BookMorphs seem to be the dominant documentation method. Would I be correct 
in suggesting that the current trend seems to be to move towards using BookMorphs 
with TextMorphs?

So perhaps a question to address is how to make BookMorphs accessible to 
visually impaired users? I guess there are two methods. Firstly, create 
an accessible interface within Squeak for accessing BookMorphs. I think 
for this it might be a good idea to consider experiences with Hypercard,
 unfortunately I have used it very little. Was there any work done on making 
Hypercard accessible to visually impaired users? Secondly, create code that 
will translate a BookMorph into a format, such as HTML, that is accessible 
using other existing software.

It seems to me that a barrier to doing this is the fact that Morphs and 
Text are very physically based - to represent a heading one selects a large 
font and perhaps bright colour. Using physical cues for structural information 
makes it very hard to express the documentation in a non visual means such 
as speech. A related problem is one of physical layout. One can postion 
many TextMorphs on a BookMorph page and it is not easy to write an algorithm 
to determine the reading order if one wants to convert the page to HTML.

There are also other reasons for storing structural information in text 
other than for accessibility. Storing structural, or semantic, information 
makes the document much more amenible to machine processing. For example 
if headings are tagged as being such it is easy to automatically generate 
a table of contents.

So, what are potential solutions?

1. Use HTML for structural tagging and integrate with BookMorphs.

This could be done by creating an HTMLMorph. Something that stores HTML 
internally but which renders itself as a TextMorph (using style sheets?). 
We could also write WYSIWYG HTML editing code.

2. Make something like Text which stores structural information rather than 
physical.

'main heading' rather than 'large font'.

3. Adopt a structural documentation system and write translators to BookMorphs

For example

Perl POD, LaTeX, Texinfo, Docbook.

So one would create documentation in Docbook for example and use a Docbook2BookMorph 
translator. The problem with this approach is integrating Morphs into such 
documentation which I guess is a definite goal.

My feeling is that it would be nice to settle on a standard documentation 
method for Squeak so that the documentation is consistent, for example like 
Perl using POD and GNU using Texinfo. I think that it would be nice if that 
documentation was accessible to visually impaired users.

Simon.

Free, encrypted, secure Web-based email at www.hushmail.com