|
|
© ACM, 2006. This is the author’s version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in W4A: Proceedings of the 2006 international cross-disciplinary workshop on Web accessibility (W4A), 1-59593-281-X, May 2006. http://doi.acm.org/10.1145/1133219.1133222
Abstract
This paper discusses extensions to the previously developed “essentiality and proficiency” approach to increasing usability and accessibility of websites. The existing approach is introduced, as is a new application in the processing of DocBook XML documents. The current principles are extended to make them more appropriate for increasing the usability of long documents. Techniques for allowing organisations to efficiently disseminate information based on the proposed application are discussed—increasing productivity for both non-disabled and disabled users.
Keywords: Accessibility, DocBook, Essentiality, Proficiency, Usability, Web, XML
Categories:
A significant amount of research has been carried out into providing access to websites for computer users with disabilities (such as sight loss). Some of this research [7, 9] focuses on finding ways to provide the user with only the information they need, in the format that is most suitable for them. This “universal design” [12, 13] style of approach is applicable to providing access for non-disabled users who are, for example, using embedded devices or simply do not have time to view anything but the essential information a website has to offer.
We present some new applications of and extensions to this research that are relevant to both on and offline document access (via integration with the DocBook XML typesetting system). Utilising this approach will allow corporations and educational institutions to provide websites, training material and manuals that can be automatically filtered and rendered to meet the needs of users in various roles. This will negate both the cost of transcribing such materials into alternative formats and that of maintaining the transcribed versions. It will also allow new methods of enhancing productivity for non-disabled users.
Dhiensa et al [6] point out that the problems of web access (which is equally applicable to offline electronic documents in web formats) is three-fold:
Research on solving these problems has been targeted at different points within the lifecycle of websites. Mohamad et al [11] presents a solution that highlights standards-compliance and accessibility problems so that they can be fixed by site developers. Hanson and Richards [9] modify existing sites on-the-fly—enabling users to have sites rendered in their chosen format.
The Disability Rights Commission Report [8] shows that websites are 35% easier to use for everyone if they are accessible1. This tells us that accessibility is a valid metric by which we can estimate the usability of websites for all people. This implies that organisations adapting the ideas presented here should be able to improve the productivity of all people wishing to access their website and web-based documents.
To solve the problems discussed above, work carried out by Dhiensa [7] lead to the creation of the “Essentiality and Proficiency Tool”. The basic concepts of this tool are:
The rest of the work in this paper adapts and subsequently builds on these concepts.
The tool requires input in the form of a profile and essentiality markup on the pages it is to filter and transform. Therefore the process involved with its use is split into separate activities for page authors and users of the tool.
Authors are required to indicate the essentiality levels of elements within the pages they create. Originally, tags had to be added manually to the source code of pages. An example web page with some essentiality markup is shown in figure 1.
Recently a Mozilla Firefox plugin was created [5] that allows this task to be completed via a GUI interface. Tags are still added to the document’s source, but this process is hidden from the author—making it usable by a wider range of authors.
|
|
The GUI interface allows authors to obtain feedback on their markup in the following ways:
It should be noted that the adoption of essentiality tags by the World Wide Web Consortium (W3C) is an ultimate goal of the project. Before this happens, however, the use of microformatting3 has been used to ensure that pages are still regarded as valid. This technique will not be required by the process for marking up DocBook XML documents.
The system is designed to make its use as transparent as possible. In the current prototype, the user visits a web page where they can select and tailor their profile. The profile records their preferred levels of essentiality and proficiency settings.
From the profile page, the user can enter a URL to visit in a textbox. The system then retrieves and transforms that page, finally presenting it to the user. For more information, please consult the previous work [7].
This system enables content producers to maintain only one version of their website—there is no longer a need to create separate “accessible” or text-only variants. The Essentiality and Proficiency Tool automatically adapts sites to users’ needs with more flexibility than such alternative versions have historically provided—and at significantly lower cost.
Additionally, the work of Cheng provides a friendly, cross-platform, GUI-based method for authors to mark up their content.
The extensions and techniques proposed in later sections of this paper inherit the process model and general approach used by Dhiensa et al, but implement them in the context of automatic translation of documents written in the DocBook XML typesetting system.
Two main limitations of the current system are currently being investigated. These are:
This paper is mainly concerned with the latter of these limitations, which will be revisited shortly.
So far the work described has been applied to make websites accessible. However, it could equally be applied to documents that use web standard formats. DocBook XML is a Document Type Definition (DTD) and set of output filters designed for the creation of technical documentation. It is employed by many companies and institutions in the creation of their internal and external documentation.
The ethos of DocBook is to:
What makes DocBook particularly suitable, as far as Essentiality and Proficiency is concerned, is its close integration with web and on-the-fly translation technologies.
Previous work ([2] and the use of DocBook for creating accessible lecture notes) found that DocBook provided a means to generate output in a number of useful formats from one source file. Most notably: the effort required to customise the existing XSLT code that produced (X)HTML output, in order to improve accessibility, was minimal. PDF and RTF output can also be produced easily.
Before we propose extensions to the existing approach, we will describe how it was implemented for DocBook documents. This demonstrates how useful the principles can be when applied in this way and provides a stepping stone for extending them. A very simple DocBook document is shown in figure 3. “Essentiality” is currently a one-dimensional grading of importance, as shown in figure 1.
|
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/ \ 4.4/docbookx.dtd"> <book lang="en"> <bookinfo> <title>Very Simple Book</title> <keywordset> <keyword>Example</keyword> </keywordset> </bookinfo> <part id="intro"> <title>Introduction</title> <chapter id="intro-background"> <title>Background</title> <para>Some text...</para> <section> <title>Nested Section</title> <para>Some more text...</para> </section> </chapter> </part> </book>
|
In a simplistic essentiality-filtering algorithm, the essentiality level of the <essn> tag is checked against the user-defined filter level. The idea is that all elements which have an equal or higher rating to that selected by the user should be displayed (i.e. we create a high-pass filter). The content bounded by the <essn> tags should be displayed only if this condition is met.
However, we must beware of the situation where a more essential piece of information is nested inside a less essential section. If the essentiality level of a given element is not sufficient to get through the filter, but it contains a nested element that would get through the filter, we must display the nested element.
A further issue is that of information being taken out of context due to the way it has been filtered. Consider the situation where one vitally important sentence has been displayed that was in the middle of a less important paragraph. If the parent paragraph is filtered but the sentence is displayed (due to the situation described above), then it could be taken out of context and have potentially serious ramifications—see figure 4 for an example.
| The following DocBook source could produce misleading output:
<essn level="7">
<para>Under no circumstances must any employee:</para> </essn> <essn level="5"> <itemizedlist> <listitem> <para> Stay in the building after the alarm has sounded. <essn level="9">Leave the building immediately if there is a fire.</essn> </para> </listitem> . . . </itemizedlist> </essn>
Sample output from the above source (if user-specified essentiality level is 6-9):
<p>Under no circumstances must any employee:</p>
<ul> <li>Leave the building immediately if there is a fire.</li> . . . </ul>
|
There are two ways to ensure this does not happen:
Adapting the ideas of essentiality and proficiency to the world of DocBook documentation could further improve the accessibility and usability of such documents. However, the scalability of the current system can limit its usefulness, especially when long documents, aimed at people in multiple roles, are concerned.
We propose extending the current tags to create a number of tracks through the document; each denoting how important the information is for people of different roles and/or groups of people. Figure 5 shows a simple example of the tags that may be used for this.
|
<essn track="manager" level="3">
<p>...</p> </essn> <essn track="developer" level="4"> <p>...</p> </essn>
|
In the case that a certain element, or set of elements may be of interest to multiple roles, they can be marked up with nested <essn> tags. This does not affect the formatting of the document and is semantically equivalent to marking the essentiality up in parallel6
Detecting if a sub-tree of an <essn> tag should be processed in a multitrack document is slightly more involved than for the single-track documents discussed above. An example algorithm is given in figure 6. The algorithm contains a test to ensure that the <essn> tag is concerned with the track that the user chose and includes extra code to deal with contextual breaks as described in section 5.1.
|
ProcessEssnTag(tag) is
begin if tag track == global track if tag level >= global level display elements inside tag else if nested tag print ‘Context Break’ ProcessEssnTag(nested tag) print ‘Context Break Finished’ end if end if else if nested tag ProcessEssnTag(nested tag) end if end if end
|
The extensions proposed above have been informally tested, however further improvements may be necessary before the system could be deployed for very large documents. This section lists some further improvements that should be considered in future work.
Figure 7 gives an example of how the first two suggestions above may be expressed in terms of document markup. It presents a more intuitive way of marking up an element or sub-tree’s essentiality across different tracks—simple <essn> tags have to be nested; <grade>s can be applied in parallel.
|
<book>
<bookinfo> <title>Essentiality Tracks Example</title> ... </bookinfo> <essninfo> <tracks> <track id="manager" display="Manager"/> <track id="dev" display="Developer"/> <track id="user" display="User"/> <track id="qa" display="Quality Assurance"/> <track id="test" display="Tester"/> </tracks> <groups> <group id="testgroup"> <member>test</member> <member>qa</member> </group> </groups> </essninfo> ... <chapter> <title>...</title> ... <essn track="manager" level="3"> <para>...</para> </essn> <essn> <essngrades> <grade track="manager" level="4"/> <grade track="developer" level="9"/> <grade group="testgroup" level="6"/> </essngrades> <section> <title>...</title> <para>...</para> <essn> <essngrades> <grade track="manager" level="6"/> <grade track="user" level="3"/> </essngrades> <para>...</para> </essn> <para>...</para> <para>...</para> </section> </essn> ... </chapter> ... </book>
|
As discussed, DocBook is designed with customisation in mind. It is trivial to edit the XSLT code so that truly accessible (X)HTML output is produced7 so this will not be discussed further.
Following basic accessibility improvements, proficiency may be implemented by further enhancing the stylesheets to enlarge the fonts, choose user and/or device-compatible colours and reorder navigation links according to the values specified in the user’s profile.
Adding support for our extended essentiality tags involves editing the DocBook DTD8. As the DTD itself is an XML document this is also a relatively easy task. However, it should be borne in mind that adding elements to a DTD (as opposed to taking them away) results in incompatibility with the original format because the new standard is a superset of the original one. This is not a problem when an organisation uses a format internally, but it is still important to submit these changes for inclusion in future versions of the standard if they are to be widely promoted and used.
As discussed, many different output formats can be generated from a DocBook document. This may be done both on and offline, via the use of XSLT and other related technologies9. As an example of where on-the-fly processing may be useful, consider an organisation publishing the documentation for some software it has developed for its employees.
In such an example, people in many different job roles could be interested in the documentation; ranging from managers to users and developers. There would likely be a number of essentiality tracks in the source files of the document. It is very likely that users would have different proficiency requirements too. If we consider the combination of essentiality track, filter level and proficiency requirements, we realise that a vast amount of output would have to be developed to cater for the needs of everyone in advance.
An efficient way to disseminate this documentation would be to have readers fill in a (very) short webform such as that shown in figure 8. This would select the parameters for the transformation, which would then occur in real time, generating (X)HTML (or PDF/RTF) output for the reader’s chosen essentiality track, level and proficiency profile. There may be good reasons for having this generation take place either on a server running Apache Cocoon or within the user’s web browser.
Though they promise great benefits (almost no modification necessary on client machines, centralised administration and upgrades), traditional proxy services may run into problems. Some popular criticisms (including those highlighted by Hanson and Richards [9] and Mohamad et al [11]) are:
These problems are not present (or are averted) within the proposed DocBook transformation system for the following reasons:
The proposed approach works because an organisation would have control over the standards and transformations in use at all stages—this is rarely the case when trying to improve the accessibility of third-party websites.
Use of essentiality tracks and the above techniques for transformation are proposed as an efficient and effective method for organisations such as companies and educational institutions to disseminate their materials10. There is still a lot of potential for future work, however:
The ideas proposed so far are being formally tested. The community of AGRIP [3] is participating in these tests as (a) a large amount of DocBook documentation is already used within this project and (b) as most users are blind, the effects on accessibility as well as general productivity could be assessed. So far, informal user feedback has yielded positive results.
Additionally, our future research will be touching on some of these areas.
This work was made possible by the sponsorship of the Grundy Educational Trust and Loughborough University.
[1] Apache Software Foundation. Apache Cocoon, 2003.
[2] Matthew T. Atkinson. AGRIP Documentation Project, 2004.
[3] Matthew Tylee Atkinson and Sabahattin Gucukoglu. Accessible Gaming Rendering Independence Possible, 05 2003.
[4] Hal Berghel. Cyberspace 2000: dealing with information overload. Commun. ACM, 40(2):19–24, 1997.
[5] Yangfan Cheng. Essentiality Mark-Up Editor to Address the Issue of Inaccessibility Using XUL. Master’s thesis, Department of Computer Scicne, Loughborough University, September 2005.
[6] Jatinder Dhiensa, Colin Machin, Francesca Smith, and Roger Stone. Optimizing the user environment: Leading towards an accessible and usable experience. In Accessible Design in the Digital World Conference, volume BCS Workshops in Computing, August 2005.
[7] Jatinder Dhiensa, Colin Machin, and Roger Stone. Assistive technology: Going beyond the disability. In Proceedings of Include 2005. Helen Hamlyn Research Centre, Royal College of Art, London, UK, April 2005.
[8] Disability Rights Commission. Formal investigation report: web accessibility. http://www.drc.org.uk/library/, April 2004.
[9] Vicki L. Hanson and John T. Richards. A web accessibility service: update and findings. In Assets ’04: Proceedings of the 6th international ACM SIGACCESS conference on Computers and accessibility, pages 169–176, New York, NY, USA, 2004. ACM Press.
[10] Starr R. Hiltz and Murray Turoff. Structuring computer-mediated communication systems to avoid information overload. Commun. ACM, 28(7):680–689, 1985.
[11] Yehya Mohamad, Dirk Stegemann, Johannes Koch, and Carlos A. Velasco. imergo: Supporting Accessibility and Web Standards to Meet the Needs of the Industry via Process-Oriented Software Tools, Lecture Notes in Computer Science, volume 3118, pages 310–316. Springer-Verlag GmbH, 01 2004.
[12] NC State University. What is universal design?, 04 1997.
[13] Trace Centre. General concepts, universal design principles and guidelines, 1971.
[14] Web Accessibility Initiative. Web Content Accessibility Guidelines (WCAG) 1.0, May 1999.
1i.e. compliant with accessibility [14] and other web standards
2Rendering transformations may include the removal of pictures for blind users, use of high-contrast colours for the vision-impaired and truncation of pages for display on mobile/embedded devices.
3This is the practise of marking up the essentiality levels of document elements using their CSS “class” property, instead of using a dedicated essentiality tag. This ensures that the page is still regarded as valid and (ironically?) passes accessibility checks.
4It is theorised by the authors that there are two main type of script-generated information: facts gleaned from a database and prose gleaned from a content management system (which could also be resident in a database, but this is incidental). Any prose may be treated in the same way as the current static content is (i.e. must be marked up as it is written). Facts (such as a price list) may contain entirely essential information and thus another way of navigating them must be developed. Research into these issues is ongoing.
5“Procedure documentation” refers to the type of documentation that is created within corporations to describe business processes, health and safety guidelines, software test procedures and so on. It often targets roles at different levels within an organisation, so finding relevant information in them can be difficult.
6Suggestions on how this situation could be made more intuitive are given later.
7Replacing all layout tables with CSS2, as the AGRIP Documentation Project have done, for example.
8In the experiments conducted for this paper, the DTD was not edited and the “-novalid” option was passed to the XML processor to disable validity checks. This allows quick tests to be made but is not as robust as editing the DTD.
9There is an older SGML standard and DSSSL stylesheets, but we do not consider them here
10Though in the case of lecture notes and similar material, the tool should be used to improve general accessibility, not to give students direct answers (thus reducing their ability to think critically)—research into the balance between these effects should be carried out.
