Eyes (by alaric)
A lot of current software is rather badly written from that perspective. For a start, anything that uses on a GUI is currently almost certainly going to be inaccessible. The blind people I've corresponded with online have all tended been using command line interfaces - DOS and UNIX - with a speech synthesiser instead of a monitor, reading out what the computer outputs.
The Web's accessibility is patchy. A properly written site should ber perfectly usable, unless it is inherently graphical; a site like HOT or NOT depends upon people voting on the contents of images, so somebody who cannot view the images will be unable to use it - and there's not a lot that can be done about it. Fair enough.
But there are plenty of sites which could be useful to the blind, but the designers of the site have relied on JavaScript or Flash for core parts of the site (such as navigation), or placed text in image files without an ALT tag (which tells the browser a string of text that can be used instead of the image, for people with images disabled - or for whom the page is being read out with a speech synthesiser). Or taking the "Give all images an ALT tag" mantra too far without thinking about why they are doing it, and writing a page that, when read out, sounds like "Upper left hand corner of border. Top of border. Logo. Upper right hand corner of border. Divider line. Welcome to Example.com. Small logo..."
The underlying problem is that people generally have a poor understanding of the declarative nature of HTML; almost everyone seems to think in terms of what they want the resulting page to look like - thereby assuming that it looks like something. They carry over the mental model of designing a brochure, and it doesn't really apply, as anybody who's been saddled with the task of making a web site look like the page design somebody's drawn for them in all browsers will tell you.
In actual fact, when you write an HTML page, you say "Here is a sequence of headings, lists, paragraphs, images, and tables, with all the text marked out as emphasised or strong, or as a link to somewhere". You then write a separate CSS file which says "On screen, the page should have a light blue background; the first heading in the page should be in such and such a font, or anything sans-serif if that font's not available, and 24 points high, and black. Tables should have a one-pixel black border and...".
Note that the CSS file says should not must, since the browser is free to ignore it; partially sighted users might override the colour and font sizes to make everything high-contrast and large.
This model, separating content and design, has been explcitly designed to allow for the same HTML page to be viewed on a small monochrome screen or a large colour screen, or to be read out, or printed onto paper, or indeed any other future human interface technologies that may be developed (direct memory injection, perhaps?).
Graphical user interface applications (from full desktop applications to Javascript and Flash applets), however, are written with a much less flexible model. The GUI toolkits tend to inexorably expose the gritty details of a two-dimensional colour pixel display, with a mouse and keyboard, to the application. This means that programmers write applications or applets that have to assume such hardware is available, and so, the software cannot be interacted with via other interfaces, unless a special interface for it is written.
A typical GUI toolkit will give the programmer the ability to create windows with a given width and height, and fill it with controls such as buttons and text fields and so on, each given positions relative to a designated corner of the window and widths and heights of their own, and - the worst of all - custom controls such as the document view area in a word processor or spread sheet. For a custom control, the toolkit just tells the application about all mouse or keyboard activity while the cursor is over the control, while allowing the application to draw lines, images, filled polygons, text, and so on at specified positions within the custom control.
Clearly, a keyboard and speech synthesiser interface for the blind would have no way of meaninfully interfacing between a human being and an application written in terms of positioning text at specified places on a screen, while being fed coordinates of mouse clicks.
It would be good if off-the-shelf application user interface toolkits, as the norm rather than the exception, worked more like HTML; the application specifies a 'mental model' of the document to the toolkit (a grid of cells, a list of paragraphs, etc), a list of actions that can be performed on each part of the model (document, cell, paragraph, word, character, ...), and a 'stylesheet' giving hints for how to display this nicely on a monitor, another one for presenting it via a very small screen, etc. This way, the same application will at least work on just about any interface hardware available, and it'll work well on any interface hardware for which there's a stylesheet (for that class of device, if not that precise model).
Obviously, applications like image editors will have to fall back on something like the 'custom control'; a mental model which assumes the existence of a graphical display. But fair enough - I can't imagine an easy way of making an image editor work via a speech synthesiser, and it can still benefit from the stylesheets to provide different interfaces for small and large screens. We'll want to support mental models which only work with certain types of hardware, for applications that truly demand it, but it's important to make it easier to write software that doesn't need such intimate connection with the hardware as an abstract model plus stylesheets. That's crucial, since programmers are lazy - their managers rarely want them spending any extra time making the software more accessible, when they could be shoving in more features (to put more bullet points in the marketing materials) or getting it out sooner (ahead of the competition).
I've seen situations where people have added 'accessability' to a system, by adding the ability for application developers to provide extra information about their applications that can be used by the user interface to better support people with hearing problems or partial sight, or difficulty in using a mouse; information like tab ordering for controls in a window so they can be navigated by the keyboard, for example.
Such accessability extras, by nature of their optionality, are an unappealing proposition to software developers; it's important that, like the Web (where standard HTML is usally at least passably accessible to screen readers and the like unless somebody has gone to the extra effort of writing client-side scripts, but NOT gone to the second level of effort required to make their application still work without the scripts), it be easier to make accessible applications than not.
I've not seen it used as an accessability feature, but AppleScript interests me because it's an interface by which applications can expose a 'mental model' along with actions that can be performed on that model. It's intended for scripting - letting advanced users write little programs that can automate repetitive tasks - but an interactive AppleScript command line hooked up to a speech synthesiser could, it strikes me, allow a blind person to use any Mac OS application which has bothered to include an AppleScript interface. But because scriptability is a bullet-point feature that could be of use to any user, it's something they're likely to be given time to do.
And it points out an interesting point - use of an application by other pieces of software is another legitimate example of an alternative interface. I've seen 'macro' systems that try to do roughly what AppleScript does by simulating the application's "native" mouse clicks and keystrokes interface, faking a mouse click on a button to trigger an action, and they break when used by somebody who has their toolbars positioned differently, or who has the window small so the buttons or menus wrap onto two lines.
Needless to say, I have some ideas how accessability might be handled in an ARGON GUI (should one every be developed), which roughly boils down to something like the HTML+CSS model - but that's a topic for another post.
Pages: 1 2
Tue 26th Dec 2006 10:49 pm 
Subscribe
By Alex Blok, Thu 28th Dec 2006 @ 3:15 am
I only learned of this via Sarah. Ouch. Re GUIs, with gonumber.com, if we have Title tags for each icon, then they could be spoken by a speech synthesizer as the pointer moved over the icons, and then, when the actual data behind the icon was 'viewed', it could be spoken too. If images have Alt and Title tags in them, would that not help too? And what about streaming audio on the site too? We could have an audio playback icon. Business owners could record podcasts.