Accessible web documents with cascading style sheets.

Accessible web documents with cascading style sheets.

[HREF1] Hugh McCracken, Lecturer, Information Systems and Technology, School of Information Science and Humanities, The Open Polytechnic of New Zealand [HREF2], Private Bag 31914, Lower Hutt, New Zealand. mcchug@topnz.ac.nz.

Abstract

A case study website: http://www.baldwin-steam.org.nz/ [HREF3] uses a combination of cascading style sheets (CSS) and presentation markup to define styles and layout of web documents. CSS provides the mechanism for complete removal of presentational markup from document structure. It would provide consistent styles throughout the site and ease site maintenance and development. CSS had been used with caution, as older browser versions had either not supported or only provided partial support for the CSS specification. Browser support for CSS has improved since first release, with latest browser versions implementing the CSS1 specification. An evaluation of current browser statistics shows that browser types and versions that do not support CSS are a minor proportion of those in use. User agents other than browsers are also used to access web documents.

CSS in conjunction with extensible hypertext markup language (XHTML) improves web document accessibility to all users, irrespective of user agent, environmental constraint or disability. The World Wide Web Consortium (W3C) CSS specification refers authors to the W3C Web Content Accessibility Guidelines (WCAG), and in turn to the Access Board Section 508 guidelines for important accessibility recommendations. The web documents were revised, removing presentational markup from the document structure. A variety of techniques were used to check for accessibility, including validation tools, manual checks with a different user agents and alternative style sheets to simulate a common colour-blindness condition.

Analysis of the population of users who might access a web document shows that the proportion of those with disabilities far outweighs the proportion with older versions of browsers. Application of the W3C WCAG recommendations to a web document will result in enhanced accessibility for the majority of users, whilst still supporting the use of older browsers and ensuring future compatibility with user agents that have not yet been released.

Introduction

The case study website, http://www.baldwin-steam.org.nz/ [HREF3] is a web site presenting specific railway locomotive information, primarily aimed at enthusiast and preservationist readership. Styles have been applied using external style sheets and presentational markup. Nested tables are used to position textural and image content, in addition to tabular data. Maintenance and development of the site is a complicated process, requiring editing of the external style sheet and inline presentational markup.

Bos et al [HREF4] recommends complete removal of presentational markup from document structure. However, older browsers will not support the use of CSS and content will be displayed without author-defined presentation. This paper will examine whether there is sufficient justification to place compete reliance on CSS for presentation of web documents despite the lack of CSS support in older browsers.

Presentation markup

It is important to make the distinction between content, structure and presentation, as these terms apply to web documents. Chisholm et al [HREF5] define content as being information that is being communicated to the user. Structural markup includes content and also metadata relating to content [HREF5]. The logical structure of web documents is defined by W3C including document type definitions and schemas for HTML, XHTML, XML and CSS [HREF5]. Conformance to the document types is important as they have been designed and revised with a view to ensure that web documents are accessible [HREF6].

Chisholm et al [HREF5] describe presentation as being the way in which a user agent renders web document content. In addition to the familiar browser family of user agents, other media types can be used to access web documents, including mobile devices, voice browsers, television and Braille readers. It follows then that user agents process web document content and make it available to the user's senses of sight, hearing or touch (Gunderson et al 2001 [HREF7]). The user agent parses the component parts of a web document into memory, by decoding and interpreting the markup and producing a document tree. Style sheets may be used to process the document tree and produce a formatted structure, which is transferred to the target medium and the user (Bos et al 1998 [HREF4]). In the absence of an author or user-defined style sheet, the user agent will use or simulate the use of a default style sheet.

In general, author-defined styles are applied in precedence to user-defined styles, which are in turn applied in preference to user-agent styles. This ordering of application of styles is the basis of the term "cascade". The final style applied to a given element may be a combination of styles from a number of sources, applied according to a cascading order of rules. User-defined styles can be set to take precedence over all other styles, recognising that it is important that users can specify how they wish to access and receive content (Bos et al 1998 [HREF4]).

Bos et al (1998) [HREF4] describes how styles may be defined for specific media groups. If a media type is not specified then the type of "all" is defaulted to. Styles specific to media types or groups can be set, presenting content in a manner thought best suited for that media type, including visual, tactile and aural styles. Specific selection techniques may be employed to best suit a media type, modifying the display of content to best advantage for that type, displaying alternative content, omitting some content or perhaps generating content where required.

What browser versions support CSS?

CSS has been supported or partially supported since Internet Explorer version 3, Netscape Navigator version 4 and Opera version 3 (Meyer (undated) [HREF8]). Support for the 1998 CSS2 specification has improved with recent version releases of browsers [HREF9], particularly Netscape 6 and Opera 5. Internet Explorer version 6 lacks support for some CSS2 features, notably the "fixed" style for positioning of boxes relative to the browser window, and some table properties. Critically important styles must be tested in the recent versions of Internet Explorer to ensure that the document displays as intended. If a critical style is not supported then alternative style strategies must be employed. Alternatively, if a non-critical style gives supplementary accessibility improvements with a selection of browser types, over and above what is otherwise provided, then it should be used.

User agents

Bos et al (1998) [HREF4] defines nine media groups that categorise user agents that can access web documents. Screen media type user devices, commonly referred to as browsers are familiar to most web authors, as might be print, projection and handheld media types. Other groups encompass less familiar user devices, including aural, Braille, embossed, tty and tv media types (Bos et al 1998 [HREF4]). There is no restriction on the list of media types, as new device types may appear at any time. Providing screen media type-specific presentational markup within web document structure may place restrictions on the accessibility of the document by other media types. This forms the rationale behind the W3C Web Accessibility Initiative guideline to separate structure from presentation [HREF5].

The Microsoft browser Internet Explorer is the dominant screen media type user agent, as shown in table 1. Netscape has a significantly smaller market share, and other browsers do not individually have significant usage. Browser statistics will vary from site to site, according to the manner in which data is collected, and the user population attracted to a site.

Table 1. Browser type statistics.
Internet Society European Co-ordination Council accesses, Sept 2001 to Jan 2002 [HREF10] Engineering Workstations WWW server, University of Illinois, accesses Jan 2002 [HREF11]
Internet Explorer 76% 85%
Netscape 14% 12%
Other 10% 3%

A large proportion of users possess a recent user agent version. For example, close to 30% of Microsoft Internet Explorer users visiting the Engineering Workstations WWW server at the University of Illinois used the latest version: 6.0, with the majority (67%) having a version 5 browser [HREF11]. Netscape users presented slightly different statistics, with an overwhelming majority (73%) possessing version 4.5+, and a smaller proportion (15%) using version 5 or 6 browsers.

Table 2. Browser version use statistics.
Browser
Version Internet Explorer Internet Explorer, % of total users Netscape Navigator Netscape Navigator, % of total users
6 29.4% 24.9% 9.7% 1.2%
5 66.8% 56.8% 4.9% 0.6%
4.5+ n/a n/a 73.1% 8.8%
4 3.5% 3.0% 9.3% 1.1%
3 0.2% 0.2% 2.5% 0.3%
Other 0.0% 0.0% 0.5% 0.1%
Totals 100.0% 84.9% 100.0% 12.1%

Source: Engineering Workstations WWW server, University of Illinois, Jan 2002 [HREF11]

Table two presents data confirming that the most popular browser is Microsoft Internet Explorer, with a recent version (version 5 or later) being used by 82% of hosts accessing the Engineering Workstations server [HREF11]. Netscape is significantly less used, and is more likely to be of less current version. Usage of older browser versions that do not support CSS is insignificant.

Users

Almost 20% of New Zealanders surveyed in a nationwide household survey of disability have a long-term disability that affects them each day (Macaskill [HREF12]). The most common form of disability quoted in New Zealand was mobility 66%, followed by sensory, including eyesight and hearing at 43% of adults with disabilities. These figures are similar to that determined by a survey conducted by the United States Census Bureau in 1997, of 208 million Americans aged 15 years and older which found that 23% of individuals had a disability, 14.8% severe (U.S. Census Bureau [HREF13]).

More specific figures to consider relating to potential web users in New Zealand include the following: that 8% of Caucasian populations are colour-blind [HREF14]; 8% of New Zealand population has an eyesight or hearing disability and 13% of the New Zealand population has a mobility disability [HREF12]. A significant proportion of the population has a disability that can be addressed by conforming to the W3C WAI guidelines [HREF5].

Accessibility

Chisholm et al [HREF5] state that web content may be termed ""accessible" if it can be accessed by all users, including those with disabilities. Users may have deficiencies or limitations in their vision, hearing or other senses; they may have cognitive deficiencies; they may use different mechanisms to interface with a computer which may be due to physical disability or environmental constraints; be using older browsers, or alternative devices to access web documents; and may have system or connection constraints. Nielsen (2000) and Chisholm et al [HREF5] contend that web documents should be capable of being rendered by all possible user devices for users of all abilities in all environmental considerations. Language needs to be clear, simple and concise to suit all possible cognitive levels and lesser reading efficiency associated with some media types [HREF5]. Clear navigational mechanisms that conform to popular convention need to be provided so that users can easily locate and access web content (Nielsen 2000).

A number of scenarios where people with disabilities attempt to access and use web documents are presented and discussed in Brewer [HREF15]. A technique commonly used through the scenarios was the application of user-defined style sheets. Brewer suggests that the success of this technique depended largely on web document authors separating presentation from structure, providing wide accessibility to web content through this process.

Web Accessibility Initiatives

The World Wide Web (W3C) Consortium has reviewed web technologies to produce a comprehensive set of Web Accessibility Initiative (WAI) resources including guidelines, checklists, techniques, validation and case studies (Nielsen 2000; Brewer 2002 [HREF16]). Chisholm et al [HREF5] have produced a W3C recommendation identifying fourteen key accessibility guidelines for web authors, discussing the implications for users of accessible web design. Checkpoints are listed for each guideline, each assigned a priority weighting from Priority 1 through to Priority 3, denoting the relative importance of the checkpoint. For example, Guideline 2 states that a web document author shall "ensure that text and graphics are understandable when viewed without colour" (Chisholm et al [HREF5], Section 6. web content accessibility guidelines). Two checkpoints follow: the first to "ensure that all information conveyed in colour is also available without colour" given a priority 1 weighting; a second checkpoint ensuring that there is sufficient contrast between foreground and background colours, whether viewed in black and white or by a user with colour deficient vision.

Three hierarchical "Web Content Accessibility Conformance" levels have been set, including: Conformance Level "A", where all Priority 1 checkpoints have been met; Conformance Level "Double-A", where all Priority 1 and 2 checkpoints have been met; and Conformance Level "Triple-A", with all Priority 1, 2 and 3 checkpoints having been met. Conformance Levels are best explained in terms of the consequences of not meeting the checkpoints. For example, if Priority 1 checkpoints are not met then "one or more groups will find it impossible to access information in the document" (Chisholm et al [HREF5], Section 4. Priorities). Priority 2 checkpoints cover areas that present significant barriers; Priority 3 checkpoints cover other areas that are of lesser significance, that pose some restriction on accessibility. Conforming web documents may display icons and/or text proclaiming one of the three WAI Conformance Levels, a useful indication of the relative accessibility of site content.

Techniques that may be employed to conform to the accessibility guidelines are discussed in separate documents, with links provided. Accessibility techniques particular to CSS are listed along with illustrative examples in Chisholm et al [HREF17]. Techniques are categorised from a CSS perspective, including a checkpoint priority weighting, and a link to the relevant accessibility checkpoint.

The United States Federal Government's Architectural and Transportation Barriers Compliance Board (Access Board) [HREF18] produced a set of accessibility guidelines commonly referred to as Section 508, requiring all U.S. government electronic information to be accessible to users with disabilities. A number of checkpoints are stated in subsection 1194.22, specifically targeting "web-base intranet and internet information and applications" [HREF18]. The W3C accessibility guidelines adequately cover all but a few Section 508 checkpoints, the more important exceptions include requirements for a mechanism for users to skip past repetitive links to access document content, and the provision of a textural equivalent of content or interfaces that are provided with scripts.

Although Section 508 guidelines apply specifically to information made available to users in the United States, compliance would improve accessibility of a web document irrespective of nation of origin.

Removing presentation from document structure

The case study web documents were revised to comply with the W3C Web Content Accessibility Guidelines. Presentational markup was removed from the document structure using techniques discussed by Chrisholm et al (2000b) [HREF19]. The transitional XHTML 1.0 document type declaration (DTD) was selected for the documents as the DTD provides excellent backward and forward browser compatibility. Older browsers recognise the markup, yet the documents are valid XML structures (Bartlett [HREF20]).

Divisions and spans were used to delineate major sections of the documents. Styles may be inherited by child elements contained within the divisions; media-specific styles can be applied, for both layout and presentation in visual media (Sklar 2001). Division and span section class selectors were given a descriptive, natural language attribute value, for example "content", "navigation" or "links", as shown in figure 1. Structural elements available in XHTML 1.0, for example headings, paragraph and link elements are used appropriately in the document [HREF19].

The structured document is much simpler to author, maintain and revise than the previous mix of presentational and structural markup, and accurately represents the structural hierarchy of the content. Importantly, the document makes sense when viewed without a style sheet.

screen shot of web document structure template, containing: a title division at the top of the page; a navigation division below and to the left 20%; remainder being the content division. The content division contains further items and divisions, including: breadcrumbs navigation; left and right divisions and a bottom links division.

Figure 1. Presentation of divisional structure using cascading style sheets for positioning.

A full collection of metadata was added to the document. The principal language used in the document was identified, as this may be referred to by speech browsers and indexing agents [HREF5]. Links were added to the document header, including references to next, previous and main documents in the collection, used by some user agents [HREF21]. Where images have been included in the document, image size attribute values are included, within both the immediate containing <img> element and the containing division, as illustrated in table 3. A specified-width containing division for an image provides a mechanism for including a caption that wraps to the same width as the image in visual media. Alternative text that describes the function, meaning or contribution of the image in the context of the document is provided in an "alt"attribute value [HREF5], and where required, a "longdesc" attribute value linking to content in an alternative media type.

Table 3 Image-containing division.

<div class="right" style="width: 300">
<img src="images/coalcreek292.jpg" width="300" height="205" alt="Remains of Wb 292 beside Coal Creek" />
<p class="caption">Remains of Wb 292 beside Coal Creek, Seddonville, West Coast of the South Island, New Zealand PHOTO: Hugh McCracken.</p>
</div>

Links, whether providing navigation within the current document, the collection or external collections of documents are important accessibility and navigational features of a web document (Nielsen 2000). Link text was revised to ensure that it provides a clear description of the linked resource, with a "title" attribute value included as supplementary information, as illustrated in table 3. Link titles display in recent browsers during on-hover events, and can also be selected for display in other user devices (Bos et al 1998 [HREF4]). This technique can be used to enhance the accessibility of linked resources for specific media types. Non-link, printable characters such as pipe, forward slash or square brackets separate adjacent links so that speech browsers and users can distinguish where one link ends and another begins [HREF5]. Collections of links, including the navigation bar are grouped within a <map> element, identified with an appropriate "id" attribute value [HREF19].

A link to main content of the document is provided at the top of the page, allowing users accessing the document with speech browsers or older browsers to skip over links or title elements [HREF19]. Divisions containing supplementary navigational links have been located at the end of the document structure, to ensure that content is encountered before navigational links when the document is rendered without a style sheet. A minimalist "breadcrumbs" hierarchical navigation list is provided at the start of the content division, to provide a simple yet effective mechanism of displaying both the context of the current document and links to higher levels of the site document collection (Nielsen 2000). A "next-page" navigational aide is included below the page content, providing a trail through the web document collection, which Nielsen has identified as a preferred navigational method for some users.

Markup and styles have been used wherever possible, rather than using images to convey content [HREF5]. The title division of the document consists of a level-1 heading containing the organisation's name, an image of a locomotive and a search form. The level-1 heading contributes to indexing of the document, is highlighted as a navigational item by aural user agents, and is rendered with appropriate emphasis in browsers that either do not support CSS or render only text. A common user practise is to skip-read through web document headings (Nielsen 2000), therefore the provision of appropriate levels of heading structure will improve document accessibility and usability. An image combining both the logo and heading could have been used, but by using a styled level-1 heading the hierarchy of the content is best represented in the web document structure. Although substitute "alt" text is available should the image not be displayed, this would present a level-1 heading to the user.

Table 4 CSS and XHTML navigation division code fragments.

div.navigation {
position: absolute;
top: 5em;
background-color: #cccccc;
color: #000000;
width: 18%;
left: 0em;
padding-top: 1em;
padding-left: .5em;
padding-bottom: 4em;
}
.navigation p {
font-size: 70%;
}
.navigation h1 {
margin-top: -0.5em;
margin-bottom: 1em;
}
(abridged)

<div id="navigation">
<h2><acronym title="New Zealand Railways">NZR</acronym> Baldwin Locomotives</h2>
<map id="navigation">
<p class="current-link">Wb 2-6-2T of 1898</p>
<p><a href="wd.html">Wd 2-6-4T of 1901</a>.</p>
(abridged)

Table 5 deprecated HTML navigation table code fragment.

<table border="0" width=100% cellspacing="0">
<tr><td width=20% valign="top" bgcolor=silver>
<table border="0">
<tr>
<td>&nbsp;</td>
<td class="nav-folder"><font color=black>NZR Baldwin Locomotive classes</font></td>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td valign=top class="nav-section"><font color=gray>&#149; </font></td>
<td valign=top class="nav-section"><a href="wb.html">Wb 2-6-2T of 1898</a></td>
</tr>
<tr>
<td valign=top class="nav-current"><font color=gray>&#149; </font></td>
<td class="nav-current">Wd 2-6-4T of 1901</td>
</tr>
(abridged)

Table markup had been used to position elements for presentational purposes, as illustrated in table 4. The revised documents use CSS for layout and positioning, as illustated in table 5. Tables are used solely to provide structure to tabular data. Table structure has been improved and extended, to provide and contain table caption, head and body data. Data structured in this way can improve accessibility to tabular data; for example, the table head element may be used to provide repeating table header rows in paged media [HREF5]. Chisholm et al [HREF5] recommend that table data cells are not used for presentational effects, which precludes use of the non-breaking space entity (&nbsp;) to ensure that table borders display. The 'empty-cells' style property for tables can be used to show borders for empty table data cells (Bos et al 1998 [HREF4]). The latest versions of Netscape and Opera support the style, although Internet Explorer does not (refer figures 2 and 3). The loss of presentational effect on empty table data cells in this user agent is preferable to populating cells with an entity.

Some elements and attribute values specified in the XHTML grammar are not yet widely supported, but should still be used [HREF19]. For example, expanded titles for abbreviations may be provided for using the <abbr> element and "title" attribute. Browsers Netscape 6 and Opera 5 support the element, title text displaying during on hover events. Netscape 6.2 provides additional support, with a dotted line underlining the abbreviation and a question mark displaying with the cursor on hover in addition to title text. Additional information can be provided to users where user devices provide support, a forward compatibility feature that is built into the XHTML grammar. Aural media-specific styles can also be used to specify how an abbreviation or acronym is pronounced, an important consideration for aural media (Jacobs et al [HREF22]. Support for the <abbr> element should not be used as a substitute for full explanation of an abbreviation when first encountered in a web document, rather it provides additional information whenever the abbreviation occurs, where supported by the user agent.

To ensure that web documents are accessible they must be well structured and conform to a W3C document type definition. XHTML provides a wealth of markup to describe and contain web document content, each portion of the document able to be selected for presentation in a way that best suits each of a number of different media types. Defining style rules for presentation of the structured web document is the next task for the web author.

Designing style sheets for accessibility

A single external CSS style sheet was developed to provide presentational styles and layout for display of the structured web document [HREF17]. Styles were developed to position major document divisions according to conventions that have recently developed for screen media (Nielsen 2000). The title division was placed at the top of the screen, search facilities at top right. Local navigation was placed in a slim column to the left of the screen, high-level links provided at the bottom. Content takes up the majority of the screen, towards the centre and right hand side. The visual perception of the screen layout is that local navigation appears alongside the content, despite of its position in the document structure. These styles were assigned to screen and projection media types.

User agents other than browsers may access the web document, including aural, handheld and print media types. Styles can be designed that best provide access for each of these media types. Some styles may be suitable for a more than one media type, and may be grouped to avoid repetition in the style sheet. Some portions of the web document may be omitted for specific media types. Media-specific styles have been developed for printing the web document, omitting navigational and link divisions so that the content division is predominantly displayed (figure 2). Font styles may be specified for print media, and may differ to those used for screen and projection.

Screen shot of web page in print preview mode. Tabular data is rendered in black Times New Roman font on a white background. Navigational and title divisions are hidden when rendered with print media styles.

Figure 2. Web document rendered with print media specific styles.

Presentation of a web document cannot be specified so that it will be rendered exactly the same way to all users. The web author can direct or suggest how a document might be displayed in a particular user device, but the final result may be a combination of styles, including those originating from the author, the user device or the user. A style sheet may be defined by a user to present web content according to user preferences or accessibility requirements. This may include style rules marked as "!important" that cannot be overridden by the author, CSS2 reversing the priorities assigned in CSS1 in recognition of the importance of user accessibility requirements (Bos et al 1998 [HREF4]). It follows then that presentation designed and optimised for the author's screen may display quite differently in the users screen (Nielsen 2000). Rather than specify exact measurement for font size, positioning of elements, margins and padding, Chisholm et al [HREF17] recommend the use of relative units such as percentages and "em", a unit that relates to the font size in current use These measurements display content relative to media resolution and other styles specified in author and user style sheets. Display will change to suit available window dimensions, text will wrap as required and blocks will expand in height in accommodation.

One exception to the use of relative units has been identified, where absolute dimensions have been specified for blocks that contain images. The absolute pixel dimensions describe the area required to display the image, and can be treated as metadata, rather than presentational markup.

Screen shot of web page as viewed in Internet Explorer 6.0. Tabular data is rendered in black Verdana font on a white background. Navigational and title divisions are visible when rendered with screen media styles.

Figure 3. Completed web document displayed in Internet Explorer 6.0 using CSS for presentation.

Where colour has been specified in the style sheet to highlight information, it is used in addition to emphasis otherwise provided in the document structure [HREF19]. Colours were chosen from the 216 colour web-safe palette that display with a reasonable degree of separation at low colour depth settings over different platforms (Sklar 2001). Colour names, although providing more readable style statements, have been deprecated in favour of numeric colour values, which can be expressed as either hexadecimal, integer or percentage Red-Green-Blue values [HREF17]. Names can be included as comments alongside style statements to improve readability of the document, for example, a web-safe colour (#990099), close to the commonly default visited-link colour purple (#800080), can be referred to as "Dark Faded Magenta" (Stein 2001 [HREF23]).

Wolfmaier [HREF14] recommends that web safe colours be selected ensuring that there is sufficient lightness contrast between them, as viewed by users with normal vision, and users with different colour vision deficiencies. Style for both foreground colours, as applied to text, and background colours need to be specified to avoid the possibility of content being rendered in an unreadable fashion. User-defined and author-defined styles may contribute to those finally selected for presentation, and may result in the same or similar colours being specified (Chisholm et al [HREF17]).

Combinations of colours specified in style sheets must be checked for accessibility by users with normal vision, those users with colour-deficient vision and when viewed in a black and white monitor [HREF5]. Rigden [HREF24] provides a table presenting the 216 web-safe colours as users with any of three colour vision deficiencies might view them. Hexadecimal colour values can be selected from the table for a specific vision type, e.g. deutanopia, and used to check how web documents may appear to a colour-deficient user. Alternative external style sheets can be designed with substitute colour values for specific vision types, and applied to web documents to check the accessibility of the specified colours.

It is especially important to check that standard link colours: unvisited, active or visited, can be discerned by colour-deficient users when viewed against specified background colours. Standard link colours should not be changed, as these are important navigational conventions (Nielsen 2000). It follows, then that background colours must be altered to ensure that all users can discern link colours.

Validation tools

A number of tools and checklists were used to check the new document structure before and during the revision of the external style sheet. XML Spy 4.0, an integrated development environment for XML and related technologies [HREF25]. The development environment enables a web author to validate XHTML documents directly to a W3C XHTML grammar, ensuring the validity of authored web documents.

XHTML was validated using the online W3C HTML validation service (Oskoboiny [HREF26]) checking the document for well formedness and validity to a specified document type: XHTML 1.0 Transitional. Document structure was revised to correct errors and omissions highlighted by the validation service until a valid document was obtained.

The external style sheet was checked in similar fashion using the online W3C CSS validation service (Le Hégaret & de Jong [HREF27]). Validation results are categorised as errors, warnings or valid CSS information. Le Hégaret & de Jong state that a style sheet must be used with valid HTML in order to function correctly, which reinforces the importance of testing styles and document structures as a inter-related couple.

Bobby Worldwide [HREF28] is an online accessibility-checking program provided by The Center for Applied Special Technology (CAST). Web documents that are available online may be tested against either the W3C Web Accessibility Initiative (WAI) content accessibility guidelines or the Section 508 guidelines of the U.S. Federal Government's Architectural and Transportation Barriers Compliance Board (Access Board). A report is generated that highlights accessibility checks, triggered by document mark up. Some checks can be identified directly as an error; others are flagged as requiring manual attention. If tested against the W3C WAI guidelines, the report lists priority 1, 2 and 3 accessibility user checks in separate sections. Bobby provides links to detailed information as to how to rectify accessibility checkpoints, the reason for the checkpoint and provides accessibility guideline references for both W3C and Section 508 guidelines as appropriate. If all priority 1 checkpoints raised in the report are dealt with, the report for the revised page should indicate that the page is granted: "Bobby approved" status, in similar fashion to W3C WAI conformance levels.

Checkpoints

W3C Web Content Accessibility guidelines [HREF5] were followed during the revision of the web documents, particular attention given to priority 1 and 2 checkpoints. An appendix to the guidelines lists accessibility checkpoints ranked by priority weighting, which can be used as a questionnaire to ensure that all checkpoints have been satisfied. Conformation to each checkpoint is important to consider, as validation by scripted tool, whilst efficient, cannot be guaranteed to highlight all accessibility considerations. The guidelines include links to techniques for each checkpoint. Techniques specific to XHTML [HREF19] and CSS [HREF17] are provided; examples illustrate accessibility improvements possible with either technology.

Testing with user agents

Web documents were viewed with a variety of user devices, including a number of different browsers and versions. These included Internet Explorer versions 5.0 and 6.0; Netscape versions 3.01, 6.01 and 6.2; Opera 5.02; Lynx viewer textural browser and the IBM home page reader.

In addition to excellent CSS support the Opera browser [HREF29] has a feature that enables the user to switch between document and user mode (figure 4). Provided the user has not specified a style sheet, the browser default style sheet is used to render and display the web document. This is a useful substitute for viewing web documents in older browsers, and can be used whilst redesigning a web document to check how the revised structure will display, with or without an author-defined style sheet.

Screen shot of web page as viewed in Opera 5.02 in user mode with image display turned off. Previously hidden jump links are displayed, alternative text displays in place of images. The page is rendered with default styles.

Figure 4. Web document displayed in Opera 5.02, in user mode with images turned off.

The Lynx textural browser [HREF30] provides a useful view of a web document, displayed without images or styles. Lynx may be downloaded and installed, or alternatively, a Lynx viewer can be used to obtain a text-browser view of web documents that are available online [HREF31]. Viewing a web document in this way will quickly show any deficiencies in the web document structure.

The revised web documents were browsed with the IBM home page reader to check accessibility of the web document with an aural media type user agent [HREF32]. This highlights potential problem areas of the document structure, particularly divisions, tab order of links and whether succinct language has been used in the document. On receiving a web document the user is primarily interested in accessing the content. Web document content can be difficult to access with an aural user agent, therefore it is important to place content towards the top of the document structure, or if this is not possible then at least provide a same-page link to the content at the top of the document. A further test is to switch off the monitor and attempt to access content, listen to alternative text statements for images and attempt to use the links provided for navigation.

Conclusion

Providing accessible web documents with cascading style sheets conforming to the W3C web content accessibility guidelines [HREF5] requires careful revision of an existing web document. Presentational markup is removed from the document, replaced by an external style sheet that specifies styles for layout, text properties and positioning of elements. Content is contained in a descriptive document structure that validates to a specific W3C document grammar. Content structured in this way can be accessed by a wide range of user devices, including older browsers, those in current use, and will be able to be accessed by user agents that have not yet been developed. Browsers that do not support CSS are an insignificant proportion of the total in use. The few users affected are able to access document content and experience the benefits of the revised document structure, most likely viewed with the default styles of the device.

Media-specific styles applied to valid and accessible documents provide accessibility enhancements over and above those already available in the revised document structure. Portions of the document tree may be selected for specific treatment, providing additional information to the user, placing emphasis or perhaps omitting sections of the document depending on the media type. Forward compatibility with new types of user agents and new versions of existing user agents is assured for an accessible web document.

Cascading style sheets enhance the accessibility of web documents to significant proportions of the population. To preserve their accessibility requirements users can specify that their own styles take precedence over author-defined styles. This is symptomatic of the way in which web documents will be accessed in the future. Web authors who use presentational markup will find it increasingly difficult to specify presentational requirements that will suit all devices that might access a web document. Rather than designing web documents so that they render best in a particular browser, the future will be best served by producing valid and accessible web documents in conjunction with cascading style sheets.

References

Altova (2002). XML Spy. [HREF25].

Architectural and Transportation Barriers Compliance Board (2001). Electronic and Information Technology Accessibility Standards. [HREF18].

Bartlett, K. (2002). XML as enabling technology: emerging developments in web accessibility. Technology And Persons With Disabilities Conference 2002. [HREF20].

Bos, B., Lie, H.W., Lilley, C., & Jacobs, I. (1998). Cascading Style Sheets, level 2 CSS2 Specification. [HREF4].

Brewer, J. (2001). How people with disabilities use the web. [HREF15].

Brewer, J. (2002). Web Accessibility Initiative (WAI) Home Page. [HREF16].

Center for Applied Special Technology (2002). Welcome to Bobby WorldWide. [HREF28].

Chisholm, W., Vanderheiden, G., & Jacobs, I. (1999). Web Content Accessibility Guidelines 1.0 [HREF5].

Chisholm, W., Vanderheiden, G., & Jacobs, I. (2000). Core Techniques for Web Content Accessibility Guidelines 1.0 [HREF6].

Chisholm, W., Vanderheiden, G., & Jacobs, I. (2000a). CSS Techniques for Web Content Accessibility Guidelines 1.0. [HREF17].

Chisholm, W., Vanderheiden, G., & Jacobs, I. (2000b). HTML Techniques for Web Content Accessibility Guidelines 1.0. [HREF19].

Chisholm, W., Vanderheiden, G. & Jacobs, I. (2000c). Techniques for Web Content Accessibility Guidelines. [HREF21].

Delorie, D.J. (2001). Lynx Viewer. [HREF31].

Dickey, T. (2001). Lynx2-8-4. [HREF30].

Gunderson, J., Eric Hansen, E., & Jacobs, I. (2001). User Agent Accessibility Guidelines 1.0 [HREF7].

IBM (2000). IBM Accessibility Center Home Page Reader Version 3.02 Trial. [HREF32].

ISOC-ECC (2002) ISOC-ECC access statistics [HREF10].

Jacobs, I., Le Hors, A., & Raggett, D. (1999). HTML 4.01 Specification. [HREF22].

Kubaitis, E. (2002). Browser statistics for January 2002 [HREF11].

Le Hégaret, P. & de Jong, S. (2002). W3C CSS Validation Service. [HREF27].

Macaskill, D. (1997). Disability survey - one in five New Zealanders limited by disability [HREF12].

Meyer, E.A. (undated). Browser compatibility chart [HREF8].

Meyer, E.A. (2001). Master compatibility chart [HREF9].

Nielsen, J. (2000). Designing Web Usability. (1st Ed.). New Riders Publishing, Indiana.

Opera Software (2002). Opera Software. [HREF29].

Oskoboiny, G. (2001). W3C HTML validation service. [HREF26].

Rigden, C. (2001). Choosing safe colours. [HREF24].

Sklar, J. (2001). Designing web pages with cascading style sheets. Course Technology, Thompson Learning, Inc., Canada.

Stein, B. (2001). VisiBone webmaster's color lab. [HREF23].

U.S. Census Bureau (2001). Americans with disabilities: 1997 - table 2. [HREF13].

Wolfmaier, T.G. (1999). Designing for the color-challenged: a challenge. Internetworking Vol. 2.1. [HREF14].

Hypertext References

HREF1
http://www.topnz.ac.nz/info/staff/mcchug.html
HREF2
http://www.topnz.ac.nz/
HREF3
http://www.baldwin-steam.org.nz/
HREF4
http://www.w3.org/TR/1998/REC-CSS2-19980512
HREF5
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/
HREF6
http://www.w3.org/TR/WCAG10-CORE-TECHS/
HREF7
http://www.w3.org/TR/WAI-USERAGENT/
HREF8
http://www.webreview.com/browsers/browsers.shtml
HREF9
http://www.webreview.com/style/css1/charts/mastergrid.shtml
HREF10
http://www.isoc-ecc.org/stats.php
HREF11
http://www.ews.uiuc.edu/bstats/latest-month.html
HREF12
http://www.stats.govt.nz/__4c2567e200085097.nsf/3153e23ac69cb3d84c25680800821fa4/e8c113f0ac7a4760cc256b120075e4e8?OpenDocument
HREF13
http://www.census.gov/hhes/www/disable/sipp/disab97/ds97t2.html
HREF14
http://www.internettg.org/newsletter/mar99/accessibility_color_challenged.html
HREF15
http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/
HREF16
http://www.w3.org/WAI/
HREF17
http://www.w3.org/TR/WCAG10-CSS-TECHS/
HREF18
http://www.access-board.gov/sec508/508standards.htm
HREF19
http://www.w3.org/TR/WCAG10-HTML-TECHS/
HREF20
http://www.csun.edu/cod/conf2002/proceedings/218.htm
HREF21
http://www.w3.org/TR/WCAG10-TECHS/
HREF22
http://www.w3.org/TR/html401
HREF23
http://www.visibone.com/colorlab/
HREF24
http://innovate.bt.com/people/rigdence/colours/ColChoice.html
HREF25
http://www.xmlspy.com/default.asp
HREF26
http://validator.w3.org/check
HREF27
http://jigsaw.w3.org/css-validator
HREF28
http://www.cast.org/bobby/
HREF29
http://www.opera.com/
HREF30
http://lynx.isc.org/release/
HREF31
http://www.delorie.com/web/lynxview.html
HREF32
http://www-3.ibm.com/able/hprtrial3.html

Copyright

Hugh McCracken, © 2002. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.