Jakob Nielsen discusses accessibility in terms of dimensionality. He points out that an important difference between visual and non-visual presentations is that the former is inherently two-dimensional, whereas the latter is limited to one dimension. He argues that this is altogether more fundamental than the issue of inherently visual contents (such as images), which can in most cases be omitted or replaced by ALT texts without substantial loss. He concludes that optimal usability for users with disabilities requires new approaches and user interfaces to overcome the limitations of a one-dimensional view.
It is probably pure coincidence that this article's publication date is only just over a month after one such approach went live. mod_accessibility addresses the the problem by offering different "views" onto web content. It can transform web contents for accessibility in the manner pioneered by the BBC "Betsie" program, but more importantly in generates fundamentally _different_ views, including metadata comparable to the table-of-contents, index and references in traditional publishing, all available at-a-keyclick to the user. But unlike traditional publishing, mod_accessibility does not require proactive cooperation from authors. And unlike many accessibility-enhanced browsers, mod_accessibility places no financial or technological burden on the disabled user. Only the web server or proxy administrator need be concerned with it.
HTML (including XHTML, which for the purposes of this article is the same thing) is fundamentally an accessible medium. At its heart is text. Coupled to that, it supports navigation (hyperlinks), multimedia content (<img>, <object>, etc), interactive systems and controls (forms and script) and presentational detail. The fundamental principle of HTML accessibility is graceful fallback: narrative text is accessible, and in situations where other content is problematic (eg for a range of disabled users - most obviously the blind), non-textual content can be presented as simple text without substantial loss to contents, functionality or navigation.
However, there are some common problems regarding Web accessibility:
One technique that may help improve accessibility is automatic on-the-fly transformation of markup. This can be implemented anywhere in the Web processing chain: at publication, on the Server, at a Proxy, or in a Browser. For example:
The key advantage of processing for accessibility at a server or proxy is that the benefits become available to users of any browser, including those affordable to the economically disadvantaged. A second advantage is that it can perform operations that would be disproportionately expensive for a browser, and share the results between all users.
mod_accessibility is designed as a fully-automatic drop-in solution to many of the problems of HTML accessibility. It cannot do anything about missing contents, but it serves to deal effectively with the other problems discussed above in a wide range of cases. It sits between the server and the user, offering the latter a choice of presentations of web contents. Each presentation is implemented with emphasis on different accessibility and usability techniques. Presenting the user with such a choice means that when a page causes problems in one view, there is always an instant switch to another option. It is not limited to serving users with special needs, but may also improve usability for able-bodied users with full-featured desktop browsers.
Technically, mod_accessibility works as an output filter for the Apache webserver. That means it has no effect on the production of the page, and it is automatically compatible not only with static pages, but also with dynamic contents such as CGI, PHP or XML/XSLT. It is controlled by the user through their browser, and optionally rewrites and enhances HTML contents as it leaves the server or proxy.
An important design decision was the use of a SAX-based parser. This means documents are parsed in a single pass from start to end, and never loaded into memory. SAX is (by far) the fastest and most efficient way to process markup, and scales to handle large documents without increasing memory requirements for processing. It means mod_accessibility is not subject to the performance and scalability limitations of a tool such as Betsie, which loads an entire document into memory and uses Perl generic text manipulation to process it. The downside to this decision is that processing based on document tree scanning, lookahead or backtracking is not possible.
Much of the developer's previous work has involved markup analysis and reporting, including tools for formal validation, WCAG and Section508 compliance testing. He is therefore extremely familiar with the techniques and problems involved. However, mod_accessibility takes a different approach: it is based on the spirit rather than the letter of accessibility. Its processing makes no direct reference to any accessibility guidelines beyond the requirement to avoid deprecated and bogus presentational markup (which it strips out).
Bearing this in mind, mod_accessibility can do four things:
The first three capabilities of course overlap somewhat with browser functions. But browsers that offer significant similar capabilities impose a serious technical and economic burden on the end-user, which may be acceptable in an office environment (where an employer bears the costs on behalf of employees), but not on the Web at large. The fourth would make little sense in a browser, as the overhead of collecting data can only really be justified when data will be shared between the (many) users of a server or proxy.
In an ideal world, all web contents would be fully accessible, structured and indexed, and of course searchable. In the real world, we have to work with a range of markup, from the well- structured through to the purely presentational. Broadly speaking, accessibility is best served by leaving well-structured markup as-is, and transforming presentational markup to plain text. A fully-automated processor therefore has to make difficult judgements about the nature of the material it is processing, knowing that most real-world markup falls somewhere between the two extremes.
To take a case in point, consider HTML tables. It is widely accepted that structural tables should be preserved while layout tables are best linearised. It may be possible to guess what category a table falls into heuristically by examining it for structural elements, but such techniques will never be 100% reliable. Betsie simply linearises all tables. Mod_accessibility instead gives users the choice: the "betsie" view linearises all tables, while other views leave them untouched. So you can switch between tabular and linear views at a single click (or equivalent).
Extending this principle of user choice, mod_accessibility offers a menu of different views, according to what has been enabled by the administrator. The user is presented with a menu of views, though not with the level of confusing detail that would require a specific decision about particular elements such as tables! The recommended default view (called "Asis") leaves markup mostly untouched, except for cleaning up in a manner comparable to Tidy or AccessValet's cleanup options. Other options linearise transcluded content (frames), and can insert TITLE attributes into all links to improve navigation.
In addition to the "views", mod_accessibility offers meta-views: a Page Outline built from important structural elements (headings and tables), and a links list. The first of these (duplicated in some browsers) is particularly useful for navigating long and complex but structured pages, such as many of those at www.w3.org, as it overcomes the problems of a one-dimensional presentation in navigating a long text (and extra data such as navigation bars, where it provides a "skip navigation" function as a by-product). The second is particularly well-suited to a proxy or server, as it can provide more data than a browser without excessive cost by retrieving and presenting page titles from links.
In reviewing different perspectives on mod_accessibility, we'll start with the server administrator, who is responsible for installing and configuring mod_accessibility. This may be the least directly interesting, but the administrator's choices determine the details of how everyone else is affected.
At the most basic level, all the administrator needs to do is to add a directive to the Apache configuration file to load mod_accessibility. There are then several configuration options to choose, such as what views are enabled on the server, whether they will be accessible by AccessKey and/or Tabindex to end users, whether and where mod_accessibility should present its own toolbar on pages, and whether authors should be able to override the administrators defaults by means of .htaccess files.
The above is ample for a proxy, and sufficient for a server. However, an additional step is recommended for most servers: mod_accessibility should be made optional! A typical configuration for this is to create two virtual servers:
This offers the best of both worlds to both authors and users.
The content provider is concerned with presenting contents and functionality to the user. Content providers are often also concerned with the fine-detail of the visual presentation to a class of readers regarded as normal or typical. Reconciling this with accessibility concerns may be considered an additional burden that is not always welcome.
A key design goal of mod_accessibility is that authors need not even be aware of it, and can safely ignore its existence. However, as ever things can be improved by using the available tools proactively, and the author may usefully take advantage of mod_accessibility.
A filter that transforms webpages could have various implications for authors. On the plus side, the basic purpose of mod_accessibility: it can enhance accessibility and usability for users. As against that, it risks disrupting the author's painstaking presentational work in the browsing situations "supported". Recommended practice for authors is to go ahead and develop their sites, and simply treat mod_accessibility as an "accessible version" of the site, with a simple pair of navigation links of the form:
<a href="http://www.example.com/">Main Site</a>
<a href="http://access.example.com/">Accessibility Options</a>
Majority users - those with no wish for accessibility help - will see exactly what the author wrote without interference, whereas users who follow the Accessibility Options link enjoy its benefits.
An author having mod_accessibility available can actively take advantage of it in limited ways. At the simplest level, viewing pages through mod_accessibility may serve to highlight in a visual browser where accessibility problems are likely to arise. In particular, the "betsie" view, an emulation of the transforming done by the BBC "Betsie" program, gives a fully linearised presentation of the page.
More controversially, an author may be able to relax compliance with accessibility standards, where mod_accessibility brings a page into compliance. Areas where this may be feasible include use of deprecated presentational markup such as frames, layout tables, fonts and colours. Since mod_accessibility offers a range of navigational aids, authors may also sometimes be able to reduce the amount of effort they devote to it. In using mod_accessibility in this way, it is important not to lose sight of the basic principles, or treat mod_accessibility as a panacea: it can of course never substitute for good, well-structured content, nor for due care and attention on the part of an author.
Finally, authors may use it as a component in a publishing system. This is rather different from its primary purpose, but since mod_accessibility parses outgoing markup, it can with no extra cost perform variable substitutions, for example, to insert a site-toolbar into every page. This is directly equivalent to Server-Side Includes (SSI), and although it does not currently support all SSI directives, future versions are likely to move towards full emulation. The reason for this is purely practical: both mod_accessibility and mod_ssi parse outgoing documents, and if we have to use both of them, we double the processing overhead by parsing it twice!
For the end user, we must make some distinctions. Firstly, between the two distinct cases:
Secondly, the user may have a Smart Client or a conventional browser. With a conventional browser, mod_accessibility presents options to users as an additional menu in each page (the presentation of this menu is determined by the server configuration and page authors). A smart client is one that supports HTTP negotiation using additional headers defined by mod_accessibility, and can present the mod_accessibility options to the user in its own way - for example a right-click or hotkey menu. When this is available, the mod_accessibility menu can be suppressed from pages served, so it appears to the user as an additional function of the browser.
The manager has two primary concerns. Firstly, an organisation's own web-based systems should be accessible, for all the usual business and legal reasons. Secondly, an organisation's employees, including disabled employees, should be able to carry out thier work effectively. These concerns will have to be reconciled with other issues such as corporate branding, and met without excessive cost.
We have already discussed how deploying mod_accessibility on the server helps improve the accessibility of pages served. Deploying it on a proxy may bring greater benefits, particularly where employees may need to access the 'net at large. And unlike specialist browsers (which meet the needs of one user only), just a single mod_accessibility installation gives unlimited service to all users.
The ISP is under no obligation to offer an "accessibility enhanced" experience to users. However, mod_accessibility may be deployed on a proxy as a value-added service, in the manner of spam filtering, family filters, mail-by-web, and other services of interest to some section of the population.