An article to help you understand mod_accessibility for Apache 2.
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 (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:
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:
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 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.
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).
Bearing this in mind, mod_accessibility can do four things:
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.
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.
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:
content served as-is without mod_accessibility
content processed on demand by mod_accessibility
This offers the best of both worlds to both authors and users.
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:
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!
For the end user, we must make some distinctions. Firstly, betweenthe two distinct cases:
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.
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.
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.
If you found this article useful, then please consider supporting our work and sharing this page.