This page attempts to present a plausible rationale for creating AxAp,
as well as the (rather convoluted) approach we're taking to do so.
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?
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
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.
More generally, accessibility support is balkanized by
, content formats
, operating systems
For example, the JAWS
and NVDA screen readers
only run on Microsoft Windows
only runs on Apple
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
makes it an increasingly attractive target for digital content.
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.
There is a huge amount of open source software that we might find useful.
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.
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!