Inclusive Design Research Centre

Read more ...

Read more ...

From time to time, I get the urge to flesh out some of my ideas and see where they lead. The collection of documents here is the outcome of scratching that itch. In all honesty, the frequency with which I publish something here is low; but check back to see if there is anything to your fancy.

Table of Contents

Here is a list of links to the documents, and a brief description of each:

Web-4-All

Web-4-All is a project sponsored by Industry Canada, a ministry of the government of Canada. Industry Canada has its own web site describing Web-4-All, but, to me, it describes the web service end of the project more than the client side. The majority of my work on the project has been on the smartcard/work-station end. So, I thought I would write up a brief description of that end of things.

Accessibility, and Separating Form from Content

This truly is a musing, in the sense that I wrote it on a whim. Eventually, it was presented at the W3C's October, 2000 workshop on web device independent authoring . Gregory Rosmaita presented it on my behalf (thanks again Gregory!).

On the other hand, this is remarkably old news -- haven't you heard yet? If not, here are the main points of the message:

1. HTML is not a formatting language.
2. You should use style sheets to handle formatting.
3. If you do, you will make your web pages more accessible.

Events

This began as a presentation, on behalf of the ATRC, for one of its corporate partners. The partner wanted an explanation of user interface events and their role. I volunteered to talk about two event systems, namely Java's, and the Macintosh model (by now the Classic Macintosh). I started with the Java event system, and then decided that was enough.

As I reached the end of my notes on Java events, I noticed a new theme emerging. That theme was that even though events, such as mouse clicks, key presses, and so on, are triggers for some change in the user interface, there is almost always a function that the event calls upon to effect the change. At least this appears to be the case with respect to Java.

I think this is terribly important from the point of view of accessibility. In the past, and even today in some cases, adaptive technology achieves its goals by simulating events. To be concrete: if users save a document by typing "control-s", then the adaptive technology achieves the same result by simulating the control-s key press. To be even more concrete: suppose the user employs a voice recognition system as their adaptive technology. The user intones "save document", and the voice recognition device turns around and simulates the appropriate key press so that save-document functionality is engaged in the word processor it is controlling.

This is silly -- if the point is to save a document, then invoke the application's save function. Similarly, for other functions of the application. Now, this is not the fault of people who develop adaptive technology. It has worked this way, because, in general, it had to. There was no direct access to an application's functionality.

This is improving -- witness the Java platform. From a distance, you can think of adaptive technology as a kind of scripting. If applications published their capabilities for outside agents to use, then the agents can direct the application through means other than a mouse and keyboard. The agents no longer simulate events to manage the application. They simply tell the application what to do.

Copyright © 2002 Adaptive Technology Resource Centre, University of Toronto.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.