Rationale

This page attempts to present a plausible rationale for creating AxAp, as well as the (rather convoluted) approach we're taking to do so.

Motivation

Access to digital information is important to any computer user, but it is especially important to computer professionals. In order to do their jobs, they must examine many forms of information, including books and papers, code and data files, documentation, spreadsheets, and web pages.

A variety of GUI-based applications have been written to assist in this process. Each application will have its own peculiarities, but casual use is typically pretty painless. Double-clicking a document brings up the appropriate app, which displays the information in some default format. Settings can then be adjusted to suit the user's preferences.

However, this approach doesn't work well for blind computer users. They are unable to see the displayed information or the controls, of course, but that isn't the only problem. More perniciously, each application's user interface presents a new set of obstacles to navigation and use.

Even if the content is nominally accessible, getting to the desired information can be a challenge. With practice, sighted users become very good at scanning text, using the document's layout to guide their search. For example, sighted users can scan section headings very rapidly.

The blind reader is at a severe disadvantage here. Textual information can be scanned visually at many times the speed of a speech-based interface, let alone a one-line braille display. And, although keyword searching and similar technologies can be useful, the reader has to know and specify what she is trying to find.

Making matters worse, many kinds of digital content aren't accessible at all. For example, images are commonly used in documents and web pages, even when the original content is textual in nature. How is the blind user supposed to know whether an image might be of interest, let alone what information it is supposed to convey?

Technology

Assistive technology can address some of these issues, but it is far from being a complete solution. In an ideal world, for example, blind users could access any form of information using a single application. However, current offerings provide only limited approximations to this.

For example, Emacs and Emacspeak are OS-independent, as well as extremely powerful and extensible. However, their range of supported document formats is largely limited to text documents (including text content from web pages).

In addition, Emacs has a substantial learning curve: it uses a large number of key bindings for navigation and operation and customization requires a passing knowledge of Emacs Lisp. So, although Emacs and Emacspeak work very well for some blind users, they are not suitable for everyone.

Balkanization

More generally, accessibility support is balkanized by application software, content formats, data sources, operating systems, etc. For example, the JAWS and NVDA screen readers only run on Microsoft Windows, while VoiceOver only runs on Apple's iOS and OSX.

Even if our blind user can find a mutually-compatible set of software and hardware to perform the desired functions, she must learn how to navigate a plethora of graphical user interfaces (GUIs). Obviously, this is neither efficient nor fun.

Use the Web, Luke!

Fortunately, many of these document formats can be converted into web pages. Also, accessibility is a long-standing goal of the World Wide Web Consortium (W3C). In particular, their Web Accessibility Initiative (WAI) has been working for two decades on guidelines, standards, etc.

As a result, the combination of a web browser and a screen reader is often the blind user's preferred way to access information. This combination's long-standing support for WAI-ARIA, coupled with the addition of semantic elements in HTML5, makes it an increasingly attractive target for digital content.

Browser Plugins

Our initial notion was to write a browser plugin that retrieves arbitrary content and converts it to semantic, accessible HTML. Indeed, F123 Access takes just this approach. However, there are several issues that make this inappropriate for our needs.

First, there are severe limitations on the things that browser plugins are allowed to do. For reasons of security, access to local resources (e.g., devices, files) is very restricted. So, for example, it might be difficult to interact directly with a braille display.

Second, plugins must be written in (or converted to) JavaScript. There is a huge amount of open source software that we might find useful. However, most of it isn't written in JavaScript, so it would be difficult, at best, to incorporate into a browser plugin.

Finally, each browser has its own API, distribution system, and packaging format for plugins. Supporting these variations would be a substantial burden. And, because some browsers are closed platforms, collaborative development efforts could be hampered.

Personal Servers

Fortunately, by creating a personal web server, we can step around these issues:

  • The server code can run as normal OS processes,
    using any desired programming language(s).

  • The server can be given access to local resources.

  • Client-side code (e.g., plugins) can provide access,
    if need be, to the dynamic state of the browser.

  • Docker, a multi-OS deployment tool, can facilitate
    convenient, efficient, flexible, and safe distribution.

Of course, the devil is in the details. See our other pages for supplementary information.


This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r16 - 02 Feb 2017, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email