Users with Disability Need Not Apply? Web Accessibility in Ireland, 2002 by Barry McMullin
Users with a variety of disabilities can potentially benefit greatly from using the Internet to mediate their access to products and services; however, this relies on the proper server side design of Web sites to facilitate such access. Design of accessible Web content is codified in the Web Content Accessibility Guidelines (WCAG) 1.0 of the World Wide Web Consortium (W3C). Compliance with WCAG (and/or similar, derivative, guidelines) is now the subject of considerable activity, both legal and technical, in many different jurisdictions. Within this overall international context, this paper reports on a project to carry out an automated baseline survey of WCAG compliance of Web sites based in Ireland. Summary results are presented and discussed. Recommendations are made for policy action, relevant both in Ireland and beyond.

Contents

Introduction
Methodology
Key Results
Pervasive Defects
Discussion
Recommendations for Action
Conclusion

 

---

 

Introduction

"If anybody asks me what the Internet means to me, I will tell him without hesitation: To me (a quadriplegic) the Internet occupies the most important part in my life. It is my feet that can take me to any part of the world; it is my hands which help me to accomplish my work; it is my best friend — it gives my life meaning."
— Dr. ZhangXu (Zhangxu and Aldis, 2001)

The technology of the Internet holds tremendous promise to improve access to information, goods, and services for many people with disabilities. Properly engineered Web sites can interoperate with dedicated assistive technologies to address a wide range of disabilities. It has become possible for a blind person to read papers, magazines and books, without assistance, and on the same day they are published; for a person with restricted mobility to shop for groceries, and pay her bills without even leaving home; for a deaf student to attend a "virtual" lecture, with sub-titling and text transcripts (W3C, 2001a).

The key is in the design of Web sites so that they facilitate — rather than obstruct — access by groups of people with disabilities. This is not rocket science: the basic requirements have been internationally codified since 1999 in the Web Content Accessibility Guidelines (WCAG) 1.0 published by the World Wide Web Consortium (W3C, 1999).

WCAG consists of 14 separate guidelines, each of which has an associated set of one or more individual checkpoints. There are a total of 65 checkpoints which are classified into three priority levels (1-3); these then give rise to three recognised conformance levels:

• WCAG-A: All priority 1 checkpoints are satisfied. This is a minimum standard which a site must meet to be considered accessible for any significant disability groups.
• WCAG-AA: All priority 1 and 2 checkpoints are satisfied. This is a "professional practice" standard, which a site should meet to be accessible to a broad range of disability groups; and,
• WCAG-AAA: All checkpoints (at all priorities) are satisfied. This is a "gold standard" of maximum accessibility which some sites may choose to aim for — for example, sites with a particular remit to serve disability communities.

Design of Web sites in conformance with WCAG is clearly good for the community of people with disabilities — but it is also very good for the general community of Web users. It is well established that universal design frequently results in products and services that are more usable for all. In the world of the Web, where another site is only ever a hyperlink away, improved usability must be a key priority for all Web site operators. It seems to be the proverbial win-win situation.

However, although this is the promise, the reality depends on the extent to which the guidelines are actually observed in practice.

In many jurisdictions around the world there are now active public policy initiatives and/or legal instruments which are directing attention at this issue; for example:

• The case of Maguire v Sydney Olympic Games Organizing Committee, decided by the Australian Human Rights & Equal Opportunity Commission (HREOC) in August 2000, established a major legal precedent for litigation to compel access to Web-based services for users with disabilities (Worthington, 2001; NUblog, 2001);
• In the U.S., both the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act are generally regarded as imposing significant obligations on Web site operators to ensure accessibility for users with disabilities (Waddell and Urban, 2000);
• The U.K. Disability Discrimination Act, and the more recent Special Educational Needs and Disability Act, create similar obligations there (Sloan, 2001); and,
• The E-Europe Action Plan (European Commission, 2001, 2000) makes a commitment to the adoption and (ultimately) application of the WCAG guidelines to all public sector Web sites in Europe.

By contrast, the status of Web accessibility in Ireland is, at best, unclear. The Irish Information Society Commission has stated that "... [w]here organisations are designing web-sites care must be taken to ensure that they are accessible to as broad a section of the population as possible" (Irish Information Society Commission, 2000). More recently, the WCAG guidelines have been formally endorsed for general application in Ireland (Irish National Disability Authority, 2002), albeit without specific legal force. Some legal protection may be available through the Equal Status Act (An tOireachtas, 2000), through there is no case law yet to test this. The Irish Disability Bill (An tOireachtas, 2001) proposed some more explicit (but still strictly limited) measures. However that bill was withdrawn following considerable opposition from disability groups. Finally, Ireland is party — in principle at least — to EU level commitments. Arising from this, a target was declared that all Irish Government Department Web sites should have achieved WCAG-AA conformance by the end of 2001 (European Commission, 2001). (We will comment more specifically on this particular commitment later.)

Given this overall public policy context, it is clearly important to have objective information about the state of accessibility of Irish Web sites, and to monitor trends in accessibility actively over time.

Over the last two years, with the support of AIB PLC, a project has been underway at the Research Institute for Networks and Communications Engineering ( RINCE) at DCU to investigate the conformance of the Irish Web to the WCAG guidelines. Following the development of technical support tools, a detailed accessibility study of Web sites operated by Irish organisations, spanning a wide range of activities, information, and services, was conducted in the summer of 2002. This summary paper explains the methodology, distills the key results, identifies the most pervasive defects encountered, and, most importantly, presents recommendations for action that follow.

 

Methodology

This section summarizes the methodology of the study; more extensive technical details are available in (McMullin, 2002).

Sampling the "Irish Web"

The objective of this study was primarily to inform and promote Web accessibility policy in Ireland. However: by its nature, the World Wide Web is a globally distributed network. Thus, a Web "site" (or "server") can be physically situated in a location which is geographical arbitrary, relative to the locations both of the operating organisations and of the users of those sites. The general criterion that has been applied here is to classify sites as Irish if (and only if) the organisation responsible for the site is incorporated in this jurisdiction (i.e., would be legally bound by the laws and courts of Ireland). This is applied regardless of the physical locations of the servers or the users. Informally then, we use the "Irish Web" to denote this subset of the Web as a whole.

Data available from whoisireland and the Open Directory Project ( ODP) suggest that the order of magnitude of the Irish Web is approximately 10,000 distinct sites. In the context of the current study, it was clear that attempting an exhaustive study would be technically very demanding — and not necessarily appropriate. Web sites differ from each other in many ways: size, function, utility, popularity, etc. It is inevitable that a relatively much smaller subset of the total are actually significant to the needs of typical users.

Ideally, one might therefore attempt to identify the most relevant Irish sites by consideration of relative "traffic" or "activity". However, such an analysis is very difficult in the general case. There is considerable debate as to what the most appropriate measures of activity levels should be. Objectively certified usage data is not widely available. Finally, even where usage data is available it is typically intended to support commercial objectives (specifically, Internet based marketing), whereas, many important Web services are provided by public sector or otherwise non-commercial organisations (which may be therefore be seriously under-represented in such data).

Accordingly, the pragmatic approach taken here was to create a sample of the Irish Web based on largely subjective judgments of experienced Web users (drawn from within the project team). The ODP category for Ireland was used as a starting point, but sites were also identified from a variety of other sources, including other directories, public advertising, etc.

A target sample size of approximately 200 distinct sites was set. This was judged to be large enough to give a reasonably wide distribution across sectors and service types and serve as a proof of principle of the methodology and technology being used. Scaling up to significantly larger surveys can be considered subsequently, in the light of the experience with this initial baseline.

The following informal categories were taken into account in selecting specific sites:

• Government and other public sector sites;
• Political parties;
• Agencies with particular responsibilities for services to users with disabilities;
• Educational institutions;
• Media organisations;
• Major companies (PLCs);
• Travel related organisations; and,
• Telecommunications, IT and Web design/hosting companies.

Other less focused categories were also considered: entertainment, sports, trade unions, legal, medical, etc.

The final list of target sites contained 214 entries (McMullin, 2002, Appendix A). These sites vary significantly in size and in the types of media in which resources are offered. A further per-site sampling strategy was therefore required. Again, for the purposes of this initial baseline survey, a number of pragmatic decisions were taken:

• Only HTML resources were captured: this reflects the fact that only HTML-based accessibility indicators (detailed in the following section) were going to evaluated;
• The maximum quantity of data captured per site was set to 200 KBytes; and,
• The maximum link recursion depth was set to three (i.e., pages more than three links distant from the site "home" page were not captured).

Sampling was carried out on 9th April 2002. In total, 31 MBytes of HTML data, distributed over 3,270 separate pages, was captured. There were 10 sites for which no data was captured. For a further 18 sites, only the initial, "home" page was captured, indicating a failure to successfully follow any links from that page. The capture failures arose from a variety of causes including network connectivity problems, reliance on client side scripting for linking, and failed redirections (suggesting server mis-configuration). Finally, as will be discussed further in the following section, the accessibility evaluation was not successfully completed on a further 27 sites. Discarding all of these, the effective sample size was reduced to 159 sites (McMullin, 2002, Appendix H).

This is clearly not presented as a "statistically representative" sample in any formal or technical sense. Nonetheless, and subject to further critical testing in future studies, it is conjectured that overall patterns from this sample can usefully guide national policy development and implementation.

Accessibility Evaluation

There are a number of software products now available to carry out automated assessments against (subsets of) the WCAG guidelines. These have a variety of strengths and weaknesses, but are functionally very similar (by definition, as they are largely driven by the WCAG guidelines themselves). For the purposes of this study we chose to adopt one of the most widely deployed of these products, Bobby Worldwide (Core v4.0), originally developed by the Center for Applied Special Technology (CAST), and now distributed and maintained by Watchfire Corporation.

bobby implements 91 distinct tests or diagnostics, each of which maps onto a specific WCAG checkpoint [ 1]. A number of bobby diagnostics map onto (different aspects of) the same WCAG checkpoint.

The bobby diagnostics are classified into a number of different "support" categories, as follows:

Full:
bobby automatically detects violations.

Partial/Partial Once:
bobby performs some partial automatic checking, but this requires manual verification.

Ask Once/Summary Ask Once:
bobby does not do any checking, the diagnostic is presented only as a reminder to perform manual checking.

For all categories other than Full, further evaluation would be required by a human assessor to determine WCAG conformance. Accordingly, in the work presented here, bobby is restricted to implementing just those diagnostics with Full support. There are 25 such diagnostics, which map onto (aspects of) 20 distinct WCAG checkpoints, including some at all three priority levels, as follows (in order of WCAG checkpoint):

 

ID	Description	WCAG Priority	WCAG Checkpoint
g9	Provide alternative text for all images.	1	1.1
g21	Provide alternative text for each APPLET.	1	1.1
g20	Provide alternative content for each OBJECT.	1	1.1
g10	Provide alternative text for all image-type buttons in forms.	1	1.1
g240	Provide alternative text for all image map hot-spots (AREAs).	1	1.1
g14	Client-side image map contains a link not presented elsewhere on the page.	3	1.5
g271	Use a public text identifier in a DOCTYPE statement.	2	3.2
g104	Use relative sizing and positioning (percent values) rather than absolute (pixels).	2	3.4
g2	Nest headings properly.	2	3.5
g125	Identify the language of the text.	3	4.3
g31	Provide a summary for tables.	3	5.5
g38	Each FRAME must reference an HTML file.	1	6.2
g37	Provide a NOFRAMES section when using FRAMEs.	2	6.5
g4	Avoid blinking text created with the BLINK element.	2	7.2
g5	Avoid scrolling text created with the MARQUEE element.	2	7.3
g33	Do not cause a page to refresh automatically.	2	7.4
g254	Do not cause a page to redirect to a new URL.	2	7.5
g269	Make sure event handlers do not require use of a mouse.	2	9.3
g109	Include default, place-holding characters in edit boxes and text areas.	3	10.4
g35	Separate adjacent links with more than whitespace.	3	10.5
g39	Give each frame a title.	1	12.1
g41	Explicitly associate form controls and their labels with the LABEL element.	2	12.4
g34	Create link phrases that make sense when read out of context.	2	13.1
g265	Do not use the same link phrase more than once when the links point to different URLs.	2	13.1
g273	Include a document TITLE.	2	13.2

 

Given that evaluation is limited to only a subset of the WCAG guidelines, and is applied to only a sample of the content of any given site, it cannot determine that any site positively satisfies the guidelines; but failure on any of these tests definitively demonstrates failure against the guidelines.

As already noted, bobby did not function properly for a number of sites. Discounting the 28 sites for which the capture phase had failed, an independent bobby failure was encountered on a further 27 sites. These failures were manifested in two ways:

• For 12 sites bobby terminated with an abnormal status code. The reason for this failure could be identified in only a subset of these, where the problem was triggered by invalid HTML coding on the server — in particular the use of invalid characters, such as spaces, in URLs. In the other cases the failures may also be related to invalid HTML, but it is not possible to be definitive based on the limited failure information emitted by bobby; it is also possible that some of these actually indicate defects in bobby itself [ 2].
• For the other 15 sites, bobby appeared to "lock up ": that is, execution was continuing for a much longer period that normal and appeared as if it would continue indefinitely. Again, these failures may be symptomatic of either invalid HTML or defects in bobby itself. The pragmatic resolution was to terminate bobby forcibly after a fixed timeout (set at a multiple of three of the maximum time otherwise recorded for successful completion).

 

Key Results

Of the sites studied:

• At least 94 percent failed to meet the minimum WCAG-A accessibility standard;
• 100 percent failed to meet the professional practice WCAG-AA accessibility standard;
• At least 90 percent failed to meet minimal conformance with other generic technical standards for Web interoperability.

 

Pervasive Defects

Of the 25 specific bobby accessibility diagnostics studied, the most pervasive (at WCAG priorities 1 and 2) were as follows:

• g104: Use relative sizing and positioning (percent values) rather than absolute (pixels).
  WCAG 3.4, priority 2, 98.7 percent of sites.

  The visual position and size of various elements can be specified in HTML — for example, font size for text, widths of tables, or individual table cells, etc. In general, HTML allows such positions and sizes to be specified in either "relative" or "absolute" units. Relative units mean that the numbers specified in the HTML should be scaled according to some norm which the user's browser already has; absolute units mean that the numbers are not scalable. The effect of using relative units is that the browser can very flexibly adjust the visual presentation according to the available visual space on the user's device, and the user's preferences and capabilities. For example, it can be ensured that even if the device, or viewing window, is relatively small, or if the user needs to use comparatively large text (for example, due to visual disability), then the text can still "flow" (so that horizontal scrolling is not required).

  This defect type is particularly relevant to users with intermediate visual disability: they are not blind, but require some facilitation, particularly the use of larger font sizes. This is already a large category of disability; furthermore, as its incidence is significantly age-related, and the relative population of seniors is growing, its importance is, if anything, increasing (European Commission, 2001).

  This defect type also illustrates the general concept of universal design. This is the fact that designing to include the widest possible variety of users often results in products and services that are significantly more usable for all users, whether disabled or not. In the current case, by designing a Web site that uses only relative positioning and sizes, it can automatically adapt to changing user technologies and needs — such as the growing use of Internet enabled TVs, Personal Digital Assistants (PDAs), etc., which have a much wider variety of visual display capabilities than standard computer terminals.

• g9: Provide alternative text for all images.
  WCAG 1.1, priority 1, 90.6 percent of sites.

  Many Web pages incorporate images for a wide variety of purposes. This immediately presents a potentially serious obstacle for a user with a significant visual disability, who may not be able to perceive the content of such images fully (or at all). While a speech synthesizer, for example, can automatically read out any text on the page, it cannot in general recognise or describe arbitrary images in any meaningful way. Fortunately there is a relatively trivial way of resolving this. HTML makes provision for attaching "alternative" or ALT text to images. This is generally hidden if the image is displayed or visible to the user; but it can be picked up and spoken by a speech synthesizer, or other alternative output device, for a blind user. The extra design effort involved is minimal — but dramatically improves the usability of the site for the affected users [ 3].

• g271: Use a public text identifier in a DOCTYPE statement.
  WCAG 3.2, priority 2, 89.9 percent of sites.

  Properly formatted HTML pages must conform to a set of strict technical specifications. Conformance to such specifications is quite generally important to ensuring compatibility between Web sites and Web browsers (Zeldman, 2001); but it is absolutely crucial to ensuring compatibility with the wide variety of special purpose Web browsers and assistive technologies that are necessary to address the diverse needs of users with disabilities.

  Unfortunately, many Web sites continue to deliver HTML pages which do not conform to these technical specifications. This situation has been able to develop historically because a very small number of browsers have accounted for the vast majority of users. These browsers have been able to process HTML which is "broken" in a variety of ways (relative to technical standards) and still render such pages in some more or less usable way. For many site operators, as long as "most" users appeared to be able to access the site, they did not concern themselves with whether it was operating in conformance with technical standards (or, in many cases, may not even have been properly aware of the technical issues).

  But this is a very unsatisfactory, and indeed, unsustainable, situation. The diversity of browser technologies in active use is now growing significantly. Firstly, there is the continuing evolution of browser software: successive versions of even the "same" browser can differ significantly in their handling of various kinds of HTML "bugs"; but users are becoming progressively reluctant to continuously upgrade their browser software. So among the user population, there is a growing diversity of legacy browser versions in active use. Secondly, there is the diversification of access devices — Internet TVs, games consoles, PDAs etc. This is an unstable situation because this growing diversity makes it progressively more difficult for faulty HTML to function consistently across user populations; the only effective long term solution is to adopt strict technical standards on the server side.

  Furthermore, the need to try to deal with non-conforming HTML has resulted in very significant software overhead in recent browser designs: on the one hand this has meant that "mainstream" browser software has tended to become progressively more bloated, and thus require significantly more powerful computers to run on; on the other hand, it has meant that browsers targeted at more lightweight devices (PDAs, etc.) simply cannot be designed to accommodate such technical deficiencies on Web servers.

  So this is another case where universal design will benefit all users, regardless of ability: but the benefit to users with disabilities will be disproportionate because of their very reliance on diverse specialist technologies.

  bobby is not technically an HTML validator — that is, a general purpose tool to validate HTML code conformance to technical standards. Future studies may complement bobby testing with the use of such a validator. However, for the purposes of the current study, bobby does give some basic indications of HTML standards conformance. In particular, a properly conforming HTML page minimally contains a so-called DOCTYPE statement which identifies which particular HTML standard the page satisfies. If this is missing, then it is not even possible in principle to validate the page for standards conformance; and bobby raises defect code g271.

  On this basis, the current study shows that 89.9 percent of sites examined have at least some non-conformant HTML. Furthermore, given that this bobby diagnostic is only a preliminary test of HTML standards conformance, the statistic above must be interpreted as a minimum level: actual levels would require more research to establish, but may well be significantly higher.

• g265: Do not use the same link phrase more than once when the links point to different URLs.
  WCAG 13.1, priority 2, 76.7 percent of sites.

  A "link phrase" is the (usually short) fragment of text in a Web page that is hypertext linked to another Web resource. For users of visual browsers link phrases are normally visually highlighted in some way (perhaps by colour, underlining, etc.); and "clicking" within the link phrase causes the browser to load the linked resource. Such users can generally scan Web pages visually very quickly to pick out link phrases; and can easily read the surrounding text if they need more context to understand a particular link phrase.

  For users of non-visual browsers (say using computer-synthesised speech, or a braille output device) "scanning" a Web page is generally a slower and more cumbersome process. One common technique to aid scanning in such cases is to simply skip from link to link; in this circumstance, only the link phrases are directly rendered to the user, and access to surrounding text (for additional context) will be relatively slow (i.e., it will undermine the very utility of this form of scanning).

  This being the case, access for such users can be significantly improved if a little care is taken in the selection of link phrases; and, conversely, poor selection of link phrases can create a significant, and generally quite unnecessary, obstacle to users. More specifically, if the same link phrase is used multiple times, in the same page, but linking to different resources, this will be completely hidden from a user who is scanning only such link phrases. The most hackneyed form of this is a repetition of stock phrases like "click here", or "more", which are meaningless in isolation.

• g41: Explicitly associate form controls and their labels with the LABEL element.
  WCAG 12.4, priority 2, 69.8 percent of sites.

  In the visual presentation of a Web page there can often be important relationships between different components of the page which are expressed only implicitly by their juxtaposition in the display. A common example arises in the case of HTML based forms. A form generally consists of information explaining to the user what has to be filled in, interspersed with e"form controlse" — text entry boxes, radio buttons, drop down lists, etc. — which the user can interact with. Typically, the relative positions in the visual display make it reasonably easy for a visual user to identify which text is associated with which control.

  However: for users who are unable to use a visual display effectively (blind, partially sighted, etc.) it is not possible to directly perceive these implicit, but critical, relationships. To address this, HTML provides facilities whereby a particular form control can be explicitly marked as associated with a particular text (the corresponding e"labele"). This coding can then be used by a suitably configured browser to help a user with a disability to recognise the correct relationships. Furthermore, coding these explicit relationships can improve general form usability; for example, the browser can associate clicks on a label as intending to activate a form control, thus providing a larger target for selection with a pointer. This may be particularly helpful to users with motor impairment which limits fine pointer manipulation; but will generally be of benefit to all users. Thus, this again illustrates the applicability of universal design.

• g269 Make sure event handlers do not require use of a mouse.
  WCAG 9.3, priority 2, 69.2 percent of sites.

  Various HTML coding techniques (commonly using client side scripting) rely on certain kinds of interaction with the user. However, depending on their individual capabilities and preferences, users may adopt a wide variety of interaction devices. In particular, the use of a conventional mouse, or even of some adapted form of screen-pointing device, may be difficult or impossible for some users. Thus, if a page is coded in such a way that certain functionality or features can be accessed only by using a particular form of interface device — such as a mouse in the current case — then that functionality will be unavailable to many users with disabilities; worse still, such users may not even be aware that such functionalities exist.

• g39: Give each frame a title.
  WCAG 12.1, priority 1, 34.0 percent of sites.

  Frames are a legacy HTML technology allowing for more or less arbitrary sets of distinct Web resources to be dynamically combined for display purposes at the client side — i.e., by the user's browser. Historically, the frame concept was an ad hoc invention which was very poorly matched to the underlying technical principles of the Web (Engelfriet, 1997b). Frames continue to give rise to a wide variety of problems both for general usability and for accessibility by users with disabilities in particular. The functionality offered by frames can now be achieved by alternative technologies that have been properly engineered into HTML, and are well supported in browsers. Accordingly, frames should be deprecated in the design of new sites; and should preferably be phased out of existing designs. Similarly, Web publishing tools should be configured to avoid the use of frames; or if this is not supported, alternative tools should be identified. These recommendations can be made on general engineering and usability grounds, quite aside from accessibility considerations.

  However, as long as frames are still in use, then it is essential that the special accessibility issues which they raise are adequately addressed (Engelfriet, 1997a). In particular, each HTML frame element should have an associated, textual, title attribute. This serves to provide critical orientating information about the frame organisation for users who cannot directly perceive the visual layout or configuration of frames.

Of course, many sites exhibited a combination of these defects, and others.

The list above should be interpreted carefully. It identifies a number of accessibility barriers which this study has identified as pervasively present across the Irish Web; however, the list is by no means exhaustive. As noted, the 25 bobby diagnostics included in the study address only a subset of the WCAG checkpoints (and do not cover even those exhaustively). The other WCAG checkpoints represent further potential accessibility barriers, at all three priority levels, which were not checked for at all in the current study. It is likely that at least some of these are as pervasive as some or all of the factors identified above. In other words, bleak as the above picture is, it is almost certainly an understatement of the difficulties faced by users with disabilities in accessing the Irish Web.

While this list may be a useful starting point for individual Web site operators in considering the accessibility of their own sites, it is, of course, no substitute for:

• a comprehensive accessibility audit against the complete WCAG guidelines;
• effective evaluation and testing with real users;
• robust embedding of accessibility practices into continuing Web maintenance and development.

 

Discussion

This section provides a brief critical review of the study, and of the tools and methodology adopted. It also considers some implications for future work.

First, the project has demonstrated that this sort of largely automated survey of selected accessibility indicators is technically feasible; and that once the appropriate tools have been developed and integrated, the technical resources to carry out such a survey are comparatively modest. This is contrast to surveying approaches that rely on significant manual intervention (e.g., Schmetzke, 2002).

However, the project has also identified a number of limitations and/or open issues, many of which will require further research.

• The scope of this study was, deliberately, limited to the Irish Web space. However, to inform public policy properly, it would be highly desirable to have comparative data for other jurisdictions; this is particularly relevant in the context of EU initiatives (European Commission, 2001, 2000).
• A fundamental issue in the study is the effect of limiting it to those accessibility indicators that can be measured by purely automatic means. On the one hand, this made the surveying of a comparatively large number of sites feasible; on the other hand, it runs a real risk of focusing remediation action solely on these automatically detectable defects, to the exclusion of action on other — potentially much more significant — accessibility barriers.
• A related point which bears emphasizing is that the presented benchmark measures of accessibility must be interpreted very carefully. In particular, the fact that zero priority 1 (WCAG-A) defects were detected on a small number of sites (six percent) does not mean that these sites are, in fact, WCAG-A conformant: it means only that they would qualify for closer evaluation.
• The work reported here is based on a snapshot taken at one point in time. Much of the real value of the work would be in exploiting the same machinery to repeat the survey automatically at regular intervals, and track any trends or significant changes.
• An open question is the relationship between WCAG conformance and the actual experience of real users. By its nature, that is not amenable to automated testing.
• The sampling techniques used in the study are intrinsically qualitative; the sites selected are not "statistically representative", and the results cannot be extrapolated by statistical means. This is a non-trivial problem: it is not apparent that it is even possible in principle to carry out statistically representative sampling for these particular purposes.
• A quite separate issue is the strategy for delimiting and sampling individual sites. We conjecture that the key results presented here are not strongly sensitive to this internal site sampling strategy (above some minimal sample size: realized in the current case by requiring that more than one page be successfully retrieved from any given site). However, it would be feasible and desirable to carry out a further study in which a substantially larger sample was taken (or at least attempted) of each site in order to test this conjecture explicitly.
• The site capture mechanism used in this study suffers from significant limitations with respect to sites which require user "registration". More generally, automated evaluation of "interactive" sites is fundamentally problematic. This is particularly important given the growing number and diverse roles of such sites.
• The finding that the vast majority of sites surveyed (90 percent) had at least some pages which do not conform to minimal technical standards for interoperability is striking — but not necessarily surprising. The development of the Web, and the evolution of these very technical standards, has been so rapid that there has been a ongoing shortage of professionally trained and qualified developers. Moreover, in many cases, standards violations are not the fault of individual developers, but of the development tools which are being used, which have also been poorly engineered, and/or released prematurely. However, for the long term viability of Web services, for all users, it is essential that this situation be improved.

 

Recommendations for Action

The primary motivation for this particular study was to inform public policy development in Ireland. The recommendations below are therefore specifically targeted at the Irish national context; however, at least some of them should have wider relevance in other jurisdictions.

Public Awareness

An Irish Web accessibility awareness campaign, targeted specifically at relevant policy and decision makers in both public and private sectors, should be an immediate priority. This should focus explicitly on the incorporation of accessibility requirements into all specifications, tender documents, etc., for Web services.

The accessibility barriers identified in this study appear to be primarily products of ignorance rather than design. Senior decision makers, responsible for commissioning Web sites and services, presumably do not set out to discriminate against users with disabilities. However, it seems that, in too many cases, they are still unaware of the requirements (and opportunities!) associated with making Web sites and services universally accessible.

There is some evidence that this situation is improving. The Information Society Commission has been active in promoting public debate on this and related issues (Irish Information Society Commission, 2000). The Irish National Disability Authority (NDA) has recently published over-arching IT Accessibility Guidelines (incorporating WCAG), and is actively promoting their adoption (Irish National Disability Authority, 2002). A number of Irish Web design consultancies now highlight accessible design. The recent requirements statement for the Public Services Broker, issued by the Irish Government Agency REACH, explicitly includes accessibility requirements (REACH, 2002).

Nonetheless, the results of the current study indicate that these efforts are certainly not yet fully effective, and it is recommended that advocacy efforts be intensified.

New Tools and Technologies

Organisations developing software and tools for Web site development should ensure that these conform to relevant standards and guidelines for producing accessible content and services. Organisations sourcing or evaluating new Web development tools should make conformance to accessibility guidelines an essential qualifying condition.

It is increasingly the case that Web content and services are developed using a variety of more or less sophisticated authoring tools, packages etc. The accessibility of the developed content and services then depends significantly on the extent to which those tools have been designed to support this. The W3C has again been to the forefront in promoting good practice in this area, for example in specific guidelines for authoring tools and applications (W3C, 2000, 2001b). Unfortunately it seems that many tools still do not incorporate such techniques adequately.

Leading by Example

A detailed timetable should be immediately published for all Irish Government Department Web sites to achieve WCAG-AA conformance. Reports on progress against this timetable should be issued regularly. A co-ordinated project to achieve conformance across the wider public sector should be centrally initiated and monitored. Private sector organisations should initiate similar comprehensive commitments to an accessible Irish Web.

As noted earlier, in the context of the E-Europe Action Plan, Ireland declared a target that all Government Department Web sites should have achieved WCAG-AA conformance by the end of 2001 (European Commission, 2001). This is a very laudable goal, and substantial resources are evidently being directed to it. However, it was apparent from the current study that this had certainly not been achieved by the target date; in fact, defects were detected on all such departmental sites included in the sample. In any case, this initiative should surely not stop at Government Departments, but should extend to all publicly supported agencies and institutions. Similar initiatives can, and should, by taken by private sector companies, representative organisations and professional bodies.

Education and Training

Training materials, courses, etc., relevant to universal design should be developed and promoted by the widest possible variety of organisations involved in education and training. Professional bodies should require that Universal Design be incorporated in the curriculum of all relevant educational programs.

It is apparent that specific, pervasive, Web design flaws identified in this study could be drastically reduced or eliminated if the issues were adequately understood by relevant personnel. There is a particular need to provide appropriate training for technical and design professionals. Some progress is being made in this front at the European Level, particularly through the E-Europe Action Plan (European Commission, 2000), which includes a commitment to the development of a European curriculum in "design for all" for designers and engineers. However, effective engagement with such European initiatives relies on support from national agencies in individual member states.

Legislation

There should be clear Irish legislation setting explicit, comprehensive, and legally enforceable standards for accessibility of all Web products and services to users with disabilities.

As noted in the introduction, there is ample evidence from other jurisdictions (notably Australia, the U.S. and the U.K.) that strong legislation to protect the rights of citizens with disabilities (in all areas of life) is a regrettable, but nonetheless essential, element in achieving comprehensive engagement with accessible design. Given the demise of the previous Irish Disability Bill it is to be hoped that a revised bill, inter alia specifically addressing accessibility of information goods and services, in both public and private sectors, will now be published as a matter of urgency.

Further Research

Research and development of technologies to support social inclusion in the information society should be encouraged actively, and supported materially, by both public and private sector agencies and organisations.

The current study provides only a crude baseline assessment of the accessibility of the Irish Web. The detailed report (McMullin, 2002) discusses in more detail both the strengths and limitations of its particular methodology; and lays out a programme of further work to extend, clarify, and refine our ability to monitor the evolving state of Irish Web accessibility — as an essential tool for informed policy formation. There is also an ongoing need for research and development of new Web technologies to support both service providers and users with disabilities. The previous Disability Bill (An tOireachtas, 2001) proposed the establishment of an Irish national Centre for Excellence in Universal Design to promote and support research in all aspects of Universal Design, on a continuing basis: this proposal should be elaborated in the drafting of any new bill. By this means, or otherwise, there should also be strong engagement by Ireland in international fora (such as W3C) concerned with accessibility of information society technologies.

 

Conclusion

This study should be a national "wake-up call" — for the Irish government, for public agencies, for private companies, organisations and individuals. It signals that, despite Ireland's justifiable pride in its economic and technological development, despite very laudable goals in documents such as the E-Europe Action Plan (European Commission, 2001, 2000), the current commitment to accessibility of the Irish Web for users with disabilities is, at best, aspirational — and, at worst, cynically inadequate.

This is doubly unfortunate. It is not just that Web technology is not being applied — as it could be — positively to improve opportunities and capabilities for users with disabilities; but on the contrary, as Web services become more pervasive and essential, to the extent that they remain inaccessible this will actually impose progressively more disadvantage and exclusion on groups with disabilities in our society.

And, of course, failure to take effective action in this area affects all citizens regardless of ability: through correlation with poor general usability, through continuing reduced participation in the emerging Information Society, and, crucially, through the inevitable compromising of Ireland's ability to trade in Web-mediated goods and services with countries having stronger legal safeguards and requirements.

It is hoped that the results of this study will serve to highlight these issues, and to further encourage the many agencies and organisations who are already actively promoting and supporting voluntary improvements in Web accessibility in Ireland. Ultimately however, there must surely also be a role for compulsion — legislation and regulation — to fully guarantee and vindicate the rights of all citizens to equal treatment in a digital democracy.

 

About the Author

Dr. Barry McMullin is a senior lecturer in the School of Electronic Engineering of Dublin City University ( DCU). He directs the eAccessibility Lab of the Research Centre for Networks and Communications Engineering ( RINCE) at DCU.
E-mail: Barry.McMullin@rince.ie

 

Acknowledgments

The work described here could not have come about without generous financial support provided by AIB PLC. I am especially indebted to John Kelly, Head of Business Banking at AIB. He demonstrated an enduring faith and commitment to the the project, and the ultimate value that it could have in setting the agenda for Ireland's emerging information society.

Detailed research and development for the project was carried out by my two research students, Esmond Walshe and Carmen Marincu.

The work was carried out in the Research Institute for Networks and Communications Engineering ( RINCE), established at DCU under the Programme for Research in Third Level Institutions operated by the Irish Higher Education Authority.

The final text of the paper has benefited significantly from constructive comments by the First Monday reviewers.

 

Notes

1. There are an additional three bobby diagnostics which do not relate to the WCAG guidelines, but only to the requirements of Section 508 of the U.S. Rehabilitation Act; since this Act does not apply in the Irish jurisdiction, these diagnostics were excluded from the current study, and will not be discussed further.

2. It should be noted that bobby is not distributed in source form; this makes further investigation in cases such as this problematic.

3. Note that, to be properly effective, this technique does rely on the author/designer of the Web site having a clear understanding of the need for, and the appropriate use of, such alternative text (Flavell, 2002).

 

References

An tOireachtas, 2001. "Disability Bill, 2001," Government Publications Office, Dublin, Ireland, at http://www.gov.ie/bills28/bills/2001/6801/default.htm, accessed 31 July 2002.

An tOireachtas, 2000. "Equal Status Act, 2000," Government Publications Office, Dublin, Ireland, at http://www.gov.ie/bills28/bills/1999/1999/default.htm, accessed 31 July 2002.

A. Engelfriet, 1997a. "Using Frames and Accessible Web Sites," Web Design Group, at http://www.htmlhelp.com/design/frames/, accessed 2 August 2002.

A. Engelfriet, 1997b. "What's Wrong With Frames?," Web Design Group, at http://www.htmlhelp.com/design/frames/whatswrong.html, accessed 2 August 2002.

European Commission, 2001. "eEurope 2002: Accessibility of Public Web Sites and their Content: Communication from the Commission to the Council, the European Parliament, the Economic and Social Committee, and the Committee of Regions," Commission of the European Communities, at http://europa.eu.int/information_society/eeurope/news_library/pdf_files/communication_accessibility_en.doc, accessed 17 October 2002 (Microsoft Word format).

European Commission, 2000. "eEurope 2002: Action Plan," at http://europa.eu.int/information_society/eeurope/action_plan/index_en.htm accessed 17 October 2002.

A.J. Flavell, 2002. "Use of ALT Texts in IMGs," at http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html, accessed 20 April 2002.

Irish Information Society Commission, 2000. "IT Access for All," at http://208.55.13.183/cgi-local/publications.cgi?f=exec&id=34, accessed 23 October 2002.

Irish National Disability Authority, 2002. "IT Accessibility Guidelines," at http://accessit.nda.ie/, accessed 17 October 2002.

B. McMullin, 2002. "WARP (Web Accessibility Reporting Project) Ireland 2002 Baseline Study," Technical Report warp-2002-00, Research Institute in Networks and Communications Engineering (RINCE), Dublin, Ireland, at http://eaccess.rince.ie/white-papers/2002/warp-2002-00/, accessed 17 October 2002.

NUblog, 2001. "Reader's Guide to Sydney Olympics Accessibility Complaint," at http://www.contenu.nu/socog-PR.html, accessed 20 October 2002.

REACH, 2002. "Public Services Broker: Requirements Statement," at http://www.reach.ie/psb1/Requirements_Statement.pdf, accessed 1 August 2002, PDF format (2.3 MB).

A. Schmetzke, 2002. "Web Page Accessibility on University of Wisconsin Campuses: 2002 Survey Data," at http://library.uwsp.edu/aschmetz/Accessible/UW-Campuses/Survey2002/contents2002.htm, accessed 20 October 2002.

M. Sloan, 2001. "Web Accessibility and the DDA," Journal of Information, Law and Technology, issue 2, at http://elj.warwick.ac.uk/jilt/01-2/sloan.html, accessed 20 October 2002.

World Wide Web Consortium (W3C), 2001a. "How People with Disabilities Use the Web," at http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/, accessed 20 April 2002.

World Wide Web Consortium (W3C), 2001b. "XML Accessibility Guidelines," at http://www.w3.org/TR/xag, accessed 1 August 2002.

World Wide Web Consortium (W3C), 2000. "Authoring Tool Accessibility Guidelines 1.0 (ATAG)," at http://www.w3.org/TR/ATAG10/, accessed 1 August 2002.

World Wide Web Consortium (W3C), 1999. "Web Content Accessibility Guidelines (WCAG)," at http://www.w3.org/TR/WCAG10/, accessed 20 April 2002.

C.D. Waddell and M.D. Urban, 2000. "An Overview of Law & Policy for IT Accessibility," at http://www.icdri.org/CynthiaW/SL508overview.html, accessed 20 October 2002.

T. Worthington, 2001. "Olympic Failure: A Case for Making the Web Accessible," presented at INET 2001: Internet Society Conference, 8 June 2001, Stockholm, at http://www.tomw.net.au/2001/bat2001.html, accessed 20 October 2002.

J. Zeldman, 2001. "To Hell With Bad Browsers!," A List Apart, number 99, at http://www.alistapart.com/stories/tohell/, accessed 17 October 2002.

Zhangxu and J. Aldis, 2001. "No Disability in Digitalized Community," International Center for Disability Resources on the Internet (ICDRI), at http://www.icdri.org/inspirational/no_disability_in_digitalized_com.htm, accessed 26 September 2002.

---

Editorial history

Paper received 24 October 2002; revised version received 25 November 2002; accepted 29 November 2002.

---

Copyright ©2002, First Monday

Copyright ©2002, Barry McMullin

Users with Disability Need Not Apply? Web Accessibility in Ireland, 2002 by Barry McMullin
First Monday, volume 7, number 12 (December 2002),
URL: http://firstmonday.org/issues/issue7_12/mcmullin/index.html