mod_accessibility for Apache 2

Introduction

Jakob Nielsendiscusses accessibility in terms of dimensionality.  He points outthat an important difference between visual and non-visual presentationsis that the former is inherently two-dimensional, whereas the latteris limited to one dimension.  He argues that this is altogethermore fundamental than the issue of inherently visual contents(such as images), which can in most cases be omitted or replaced byALT texts without substantial loss.  He concludes that optimalusability for users with disabilities requires new approachesand user interfaces to overcome the limitations of a one-dimensionalview.

It is probably pure coincidence that this article's publication dateis 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 accessibilityin the manner pioneered by the BBC "Betsie" program, but more importantlyin generates fundamentally _different_ views, including metadatacomparable to the table-of-contents, index and references in traditionalpublishing, all available at-a-keyclick to the user.  But unliketraditional publishing, mod_accessibility does not require proactivecooperation from authors.  And unlike many accessibility-enhanced browsers,mod_accessibility places no financial or technological burden on thedisabled user.  Only the web server or proxy administrator need beconcerned with it.

HTML Accessibility

HTML (including XHTML, which for the purposes of this article is thesame thing) is fundamentally an accessible medium.  At its heart istext.  Coupled to that, it supports navigation (hyperlinks),multimedia content (<img>, <object>, etc), interactive systems andcontrols (forms and script) and presentational detail.  Thefundamental principle of HTML accessibility is graceful fallback:narrative text is accessible, and in situations where other content isproblematic (eg for a range of disabled users - most obviously theblind), non-textual content can be presented as simple text withoutsubstantial loss to contents, functionality or navigation.

However, there are some common problems regarding Web accessibility:

 
• Missing contents.  In some of the worst cases, there is nothing  meaningful in HTML; only Flash content, a Word document, or a series  of images.  At worst this is inaccessible at any price, and at best it  relies on the user having expensive specialist equipment available.
 
• Poor markup that fails to use, or indeed actively abuses, HTML  structure.  This is widespread and happens for a number of reasons,  including defective authoring and publishing software, ignorance  amongst developers, and problems of communication between developers  and their managers or clients.
 
• Markup that is unavoidably compromised to work around limitations of  the HTML medium or popular browsers.  A typical example arises where  navigational devices (like a toolbar) are embedded in page contents.  Further examples can be found in layout tables and clientside scripts.
 
• Contents that are inherently challenging.  A complex document may  never be accessible to a person without the relevant educational  background, but can nevertheless be improved by presenting a good  overview and navigation.
 
• Limitations in the abilities of web browsers to present the information  available in webpages effectively to users.

Automated Transformation of Markup

One technique that may help improve accessibility is automatic on-the-flytransformation of markup.  This can be implemented anywhere in theWeb processing chain: at publication, on the Server, at a Proxy, orin a Browser.  For example:

 
• At publication: static documents may be processed from a common  repository through a tool such as AccessValet or Tidy.  Compliance  with WCAG is a good outcome.
 
• In a browser, any document will be parsed and presented according to  the needs of its users and the capabilities of the medium (visual,  text, audio, etc).
 
• A program on a server or proxy can transform markup.  This approach  was pioneered by the BBC "Betsie", a CGI program to linearise  documents and strip presentational markup.  Another such program  was this author's Accessibility Proxy, an experimental service  that ran for several months at Site Valet.

The key advantage of processing for accessibility at a server or proxyis that the benefits become available to users of any browser, includingthose affordable to the economically disadvantaged.  A secondadvantage is that it can perform operations that would bedisproportionately expensive for a browser, and share the resultsbetween all users.

mod_accessibility

mod_accessibility is designed as a fully-automatic drop-in solution tomany of the problems of HTML accessibility.  It cannot do anythingabout missing contents, but it serves to deal effectively with theother problems discussed above in a wide range of cases.  It sitsbetween the server and the user, offering the latter a choice ofpresentations of web contents.  Each presentation is implementedwith emphasis on different accessibility and usability techniques.Presenting the user with such a choice means that when a page causesproblems in one view, there is always an instant switch to another option.It is not limited to serving users with special needs, but may alsoimprove usability for able-bodied users with full-featured desktop browsers.

Technically, mod_accessibility works as an output filter for theApache webserver.  That means it has no effect on the productionof the page, and it is automatically compatible not only withstatic pages, but also with dynamic contents such as CGI, PHP orXML/XSLT.  It is controlled by the user through their browser,and optionally rewrites and enhances HTML contents asit 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 mostefficient way to process markup, and scales to handle large documentswithout increasing memory requirements for processing.  It meansmod_accessibility is not subject to the performance and scalabilitylimitations of a tool such as Betsie, which loads an entire documentinto memory and uses Perl generic text manipulation to process it.The downside to this decision is that processing based on documenttree scanning, lookahead or backtracking is not possible.

The Basic Philosophy

Much of the developer's previous work has involved markup analysis andreporting, including tools for formal validation, WCAG and Section508compliance testing.  He is therefore extremely familiar with thetechniques and problems involved.  However, mod_accessibility takesa different approach: it is based on the spirit rather than theletter of accessibility.  Its processing makes no direct referenceto any accessibility guidelines beyond the requirement to avoiddeprecated and bogus presentational markup (which it strips out).

In summary, it addresses the practical question "What *can* we do within the contstraints on us?" rather than the more utopian "What *should* we do in an ideal world?"

Bearing this in mind, mod_accessibility can do four things:

1. Transform contents in ways likely to improve accessibility.
2. Offer users a choice of fundamentally different transforms.
3. Offer the user summary details: automatic TOC and navigation help.
4. Collect relevant external data and present them to the user.

The first three capabilities of course overlap somewhat with browserfunctions.  But browsers that offer significant similar capabilitiesimpose a serious technical and economic burden on the end-user, whichmay be acceptable in an office environment (where an employer bearsthe costs on behalf of employees), but not on the Web at large.The fourth would make little sense in a browser, as the overheadof collecting data can only really be justified when data will beshared between the (many) users of a server or proxy.

The mod_accessibility Views

In an ideal world, all web contents would be fully accessible,structured and indexed, and of course searchable.  In the realworld, we have to work with a range of markup, from the well-structured through to the purely presentational.  Broadlyspeaking, accessibility is best served by leaving well-structuredmarkup as-is, and transforming presentational markup to plain text.A fully-automated processor therefore has to make difficult judgementsabout the nature of the material it is processing, knowing that mostreal-world markup falls somewhere between the two extremes.

To take a case in point, consider HTML tables.  It is widely acceptedthat structural tables should be preserved while layout tables arebest linearised.  It may be possible to guess what category atable falls into heuristically by examining it for structural elements,but such techniques will never be 100% reliable.  Betsie simplylinearises all tables.  Mod_accessibility instead gives users thechoice: the "betsie" view linearises all tables, while other viewsleave them untouched.  So you can switch between tabular and linearviews at a single click (or equivalent).

Extending this principle of user choice, mod_accessibility offersa menu of different views, according to what has been enabled bythe administrator.  The user is presented with a menu of views,though not with the level of confusing detail that would requirea specific decision about particular elements such as tables!The recommended default view (called "Asis") leaves markupmostly untouched, except for cleaning up in a manner comparableto Tidy or AccessValet's cleanup options.  Other options linearisetranscluded content (frames), and can insert TITLE attributes intoall links to improve navigation.

In addition to the "views", mod_accessibility offers meta-views:a Page Outline built from important structural elements (headingsand tables), and a links list.  The first of these (duplicated insome browsers) is particularly useful for navigating long and complexbut structured pages, such as many of those at www.w3.org, asit overcomes the problems of a one-dimensional presentation innavigating 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, asit can provide more data than a browser without excessive costby retrieving and presenting page titles from links.

Perspectives on mod_accessibility

• The End User
• The Content Provider
• The Server or Proxy Administrator
• The Manager
• The ISP

Server Administrator Perspective

In reviewing different perspectives on mod_accessibility, we'll startwith the server administrator, who is responsible for installing andconfiguring mod_accessibility.  This may be the least directlyinteresting, but the administrator's choices determine the details ofhow everyone else is affected.

At the most basic level, all the administrator needs to do is to adda directive to the Apache configuration file to load mod_accessibility.There are then several configuration options to choose, such as whatviews are enabled on the server, whether they will be accessible byAccessKey and/or Tabindex to end users, whether and where mod_accessibilityshould present its own toolbar on pages, and whether authors should beable 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_accessibilityshould be made optional!  A typical configuration for this is to createtwo virtual servers:

http://www.example.com/

   content served as-is without mod_accessibility

http://access.example.com/

   content processed on demand by mod_accessibility

This offers the best of both worlds to both authors and users.

Content Provider Perspective

The content provider is concerned with presenting contents and functionalityto the user.  Content providers are often also concerned with the fine-detailof the visual presentation to a class of readers regarded as normal ortypical.  Reconciling this with accessibility concerns may beconsidered an additional burden that is not always welcome.

A key design goal of mod_accessibility is that authors need noteven be aware of it, and can safely ignore its existence.However, as ever things can be improved by using the available toolsproactively, and the author may usefully take advantage ofmod_accessibility.

A filter that transforms webpages could have various implicationsfor 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 workin the browsing situations "supported".  Recommended practice forauthors is to go ahead and develop their sites, and simply treatmod_accessibility as an "accessible version" of the site, with asimple 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 seeexactly what the author wrote without interference, whereas users whofollow the Accessibility Options link enjoy its benefits.

An author having mod_accessibility available can actively take advantageof it in limited ways.  At the simplest level, viewing pages throughmod_accessibility may serve to highlight in a visual browser whereaccessibility 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 withaccessibility standards, where mod_accessibility brings a page intocompliance.  Areas where this may be feasible include use of deprecatedpresentational markup such as frames, layout tables, fonts and colours.Since mod_accessibility offers a range of navigational aids, authorsmay also sometimes be able to reduce the amount of effort they devoteto it.  In using mod_accessibility in this way, it is important not tolose sight of the basic principles, or treat mod_accessibility as apanacea: it can of course never substitute for good, well-structuredcontent, 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 sincemod_accessibility parses outgoing markup, it can with no extracost perform variable substitutions, for example, to insert asite-toolbar into every page.  This is directly equivalent toServer-Side Includes (SSI), and although it does not currentlysupport all SSI directives, future versions are likely tomove towards full emulation.  The reason for this is purelypractical: both mod_accessibility and mod_ssi parse outgoingdocuments, and if we have to use both of them, we double theprocessing overhead by parsing it twice!

End-User Perspective

For the end user, we must make some distinctions.  Firstly, betweenthe two distinct cases:

 
• The "intranet" situation, where mod_accessibility is known to be  available on the server(s).  The user is fully in control, and can  switch to or from mod_accessibility and between the different views  at any time simply by following a link.
 
• Browsing the Web at large, where mod_accessibility may be available  but there is no expectation of it.  The user may select or unselect  a mod_accessibility-enabled proxy, but this is now a browser  configuration option and loses the convenience of simply following  a link.  Users wanting accessibility-enhanced browsing will see  everything through mod_accessibility.  The different views are  of course still always available.

Secondly, the user may have a Smart Client or a conventional browser.With a conventional browser, mod_accessibility presents options tousers as an additional menu in each page (the presentation of thismenu is determined by the server configuration and page authors).A smart client is one that supports HTTP negotiation using additionalheaders defined by mod_accessibility, and can present themod_accessibility options to the user in its own way - for example aright-click or hotkey menu.  When this is available, the mod_accessibilitymenu can be suppressed from pages served, so it appears to the useras an additional function of the browser.

Manager Perspective

The manager has two primary concerns.  Firstly, an organisation's ownweb-based systems should be accessible, for all the usual businessand legal reasons.  Secondly, an organisation's employees, includingdisabled employees, should be able to carry out thier work effectively.These concerns will have to be reconciled with other issues suchas corporate branding, and met without excessive cost.

We have already discussed how deploying mod_accessibility on theserver helps improve the accessibility of pages served.  Deployingit on a proxy may bring greater benefits, particularly whereemployees may need to access the 'net at large.  And unlikespecialist browsers (which meet the needs of one user only),just a single mod_accessibility installation gives unlimitedservice to all users.

ISP Perspective

The ISP is under no obligation to offer an "accessibility enhanced"experience to users.  However, mod_accessibility may be deployed ona proxy as a value-added service, in the manner of spam filtering,family filters, mail-by-web, and other services of interest tosome section of the population.

‍

‍

Support Our Work

If you found this article useful, then please consider supporting our work and sharing this page.

‍