The World Wide Web ushered in a new wave of communication. It has since evolved into a dynamic mechanism for disseminating and managing information. A subset of the Internet, the Web is a virtual global space for interaction between individuals irrespective of their geographical location. Surfing the web is the means of accessing, organizing and moving through the Internet's huge repository of stored information.

As the online community continues its rapid growth, the Web increasingly becomes a necessity. It is emerging as a critical path to practically every aspect of human life. The community of people with disabilities who access the Internet have a number of challenges to face. These include the presentation, structure and interpretation of information (textual and graphical) through the Web. As technology reshapes and redefines this medium, obstacles can become more difficult to overcome.

The first phase of this project seeks to take a snapshot of accessibility on the web. Using the accessibility validators, surveys among specified genres of websites are taken to identify patterns or trends in accessible or non accessible websites.

A WBI proxy will also be created to identify specific html attributes that the validators do not identify. If a group shows a consistent pattern in the problems they present, then there is more hope that an automatic tool can spot and remedy the problem.

The second phase, if patterns and trends are clearly identified, is to devise a tool that can be used to automate accessibility. It becomes economically worth while to build such a tool because it can have an impact. It can be in the form of a proxy that delivers accessible web pages to the client.

The first phase determines whether the second phase is possible. If every site presents problems unique unto itself, then it would not pay to look for a mechanical approach to improving the sites.

The disabled comprise a significant number of persons within the US and internationally. In a 1980 estimate, the United Nations reported1 that approximately 1 in every 10 people in the world (more than 500 million people) has a disability.

Canada reports that 14% of its population have a disability, while 18% of the Australian population are disabled. In Europe reports 1 in 10, consistent with the UN report. According to the Bureau's 1997 report, 20% of Americans have some kind of disability, while 1 in 10 Americans has a severe disability.

These numbers include people with disabilities who are not directly affected by web accessibility issues, such as paraplegics. However, the population of people with disabilities, who are affected by web accessibility issues, ranges in the tens of millions

The US Census Bureau defines "Disability" as having a non-severe or a severe disability involving difficulty or inability in performing functional activities, activities of daily living, or instrumental activities, used a wheelchair, had used a cane or similar aid for six months or longer, or had a developmental disability or a mental or emotional disability2.

Disabilities that challenge a user's web accessibility include blindness/visual impairment; deafness or hard of hearing; and cognitive or language impairments.

For varying degrees of blindness/visual impairments, web accessibility is a challenge since it is a visual interface. The high graphical nature of the web poses a problem for people who have difficulty distinguishing between colors. Simply moving a mouse, requires eye and hand coordination, which can be problematic for people with low vision.

For the hard of hearing, audio cues, such as computer beeps and spoken messages, are hard to distinguish. For the deaf a completely different mechanism is required to render web content in a comprehensible manner.

Complex or inconsistent displays or word choice can make using computers more difficult for people with cognitive and language impairments. This ranges from dyslexia to difficulties remembering, solving problems, or perceiving sensory information to problems comprehending and using language.

Some disabilities, such as motor impairment, pose a general computer accessibility problem and therefore must first overcome that hurdle. Poor muscle control or weaknesses can make using standard keyboards and mouse devices difficult. This problem is addressed through operating system support and assistive technology. Web accessibility will have little impact here.

As the Internet, becomes a more viable way of conducting business, the "ease of use" and web access would be both beneficial to the consumer and the business. While it is becoming easier to shop online for many people, the web has yet to catch up with providing all consumers with the same "ease of use".

About 16 million people with disabilities are employed in the US. According to the 1998 report released by President's Committee on Employment of People with Disabilities, "Consumers with disabilities control more than $175 billion in discretionary income. In the United Kingdom, the Helen Hamlyn Research Center reports that the estimated purchasing power of people with disabilities in the UK is £40-50 billion.

Considering all consumers when designing e-business sites will increase the industries market. By providing easy access to functions such as shopping carts and search engines one can increase user accessibility.

Aside from the e-business aspect there are many other issues surrounding the right to information. When the fundamental right to information as an individual is infringed, governments are inclined to get involved.

Many countries, that seek to protect the rights of the disabled through governmental policy and laws, incorporate the right to information/technology access. Anti-Discrimination and Disability Laws tend to cover web accessibility rights and issues virtually by protecting the basic rights as an individual living in this society.

In the United States, legislation protecting the rights of the disabled include the Americans with Disabilities Act (ADA)1; Section 508 of the Rehabilitation Act2; Section 255 of the Telecommunications Act3; and the Assistive Technology Act 19984.

While some legislation deals with standards and federal funding, the Rehabilitation Act actually enforces web accessibility for federal agencies. A deadline of June 21, 2001 was set by the US government for federal agencies, that utilize electronic and information technology, to ensure accessibility to that technology/information. This is to be done in a manner comparable to access by people who are not disabled.

There are similar trends Internationally. With the New European Community Disability Strategy initiative5, Europe is increasingly exposed to elements of Web Accessibility. In Portugal, the Portuguese Accessibility Special Interest Group (PASIG)6 spearheaded efforts for Internet and Web accessibility. PASIG helped to compile the Internet Accessibility Guidelines which was adopted by the Portuguese Parliament in 1999.

A center piece to web accessibility internationally is the World Wide Web Consortium's(W3C) Web Accessibility Initiative (WAI), which is supported by a number of countries including Canada, Australia, Japan, US and the UK.

The W3C is an entity that develops specifications, guidelines, software, and tools to lead the Web to its full potential as a forum for information, commerce, communication, and collective understanding. This commitment includes promoting a high degree of usability for people with disabilities, which lead to the creation of the WAI program office.

The WAI, in coordination with organizations around the world, pursues web accessibility through five primary areas of work: technology, guidelines, tools, education and outreach, and research and development1. The WAI is concerned with web content and design, as it recognizes that structure and presentation of web pages is critical to web accessibility.

While Governments seek to support and protect the rights of individuals, it is up to web page authors to heed the call.

Web Browsers - Text, GUI and Accessibility

Text Browsers are generally accessible regardless of ability. Since it is text-based, it is easier to use media products such as screen readers and speech synthesis & recognition applications. Text browsers used by people with disabilities include Lynx, Net-Tamer and Emacs/W3.

GUI Browsers ushered in the high graphical nature of the Web, posing new challenges for the visually impaired user community. Browsers have made an effort in facilitating easier web browsing for people with disabilities. The popular browsers, Internet Explorer and Netscape support adjustable font colors, sizes and styles, displaying of alternative text descriptions of images/image maps, creating and installing style sheets. Other Browsers that consider accessibility include Amaya and Opera.

The widespread use of GUI Browsers influenced the creation of "Accessibility Browsers". These specialized browsers, developed by assistive technology vendors, primarily focused on web access for the blind and visually impaired. Accessibility browsers include IBM Home Page Reader and BrookesTalkWeb. The IBM Home Page Reader utilizes IBM's ViaVoice text-to-speech synthesizer and Internet Explorer to provide accurate spoken output of Web information1. It also outputs visual data through the browser's interface.

One of the most popular screen readers available today, JAWS (Job Access for Windows) completely reformats the Web page, making complex page objects such as tables and link lists accessible2. In the case of list links, JAWS reformats them alphabetically and creates a list box where the list is displayed. Users can scroll through this list easily. For tables, it converts a table into a single column of text with the appropriate header.

In general, the accessibility features of Web Browsers provide some measure of usability for the disabled. However web accessibility is a partnership involving browsers, assistive technology and web content producers. For Example, while JAWS reformats tables to make them more accessible, if designers/authors are not filling in table headers and summaries, this JAWS feature may prove to be useless.

Cognitive Disabilities Support

Screen readers provide an unexpected tool for people who can see, but do not comprehend visual information well. Since a screen reader translates input into spoken language, web content may be more easily comprehended by dyslexics. Screen readers that highlight the word it is reading, doubles as a learning tool since the user can listen and read simultaneously. The dual modes of input can help in comprehending written language.

Accessibility Validation Tools

A-Prompt is a software toolkit designed to be embedded within an HTML editor or a stand alone, that prompts the author for accessible HTML code enhancements3. It includes a validator that reviews elements for accessibility. If the validator determines that the HTML code is not accessible, the A-Prompt Wizard displays a warning message and a Repair box.

Bobby, a java-based program, provides an accessibility validation service that examines a single Web page or web sites4. Bobby provides reporting status on accessibility errors, questions and tips; recommended changes; browser compatibility errors and download time for Web pages. Repairs are not automated.

The analysis of accessibility in both A-Prompt and Bobby are based on the W3C's WAI Web Content Accessibility Guidelines. The settings in A-Prompt allow the user to set the priority levels that correspond to those outlined in the WAI Guidelines. Although Bobby will check for all priority errors, it will approve sites that have no priority 1 errors. This group of errors are the highest priority as they tend to provide users with basic web accessibility. While both programs are based on W3C's guidelines, a web page, analyzed by both programs may not yield the same results. Figure 1 shows the contrast between similar priority levels using the same html page for both A-Prompt and Bobby5. P denotes the priority level. In this survey, Bobby appeared to be more lenient than A-Prompt, in approving the site. However, both A-Prompt and Bobby caught similar errors. The reason is that not all errors caught are considered in Bobby's approval rate.

Bobby separates priority errors from user checks errors. User checks require the attention of the author to review and correct. This is the human element since comprehension cannot be automated. A-Prompt's approval rate considers all errors. This makes sense since Bobby is a validator, and A-Prompt is a tool that can repair and validate.

What A-Prompt considered over Bobby included low color contrast, script missing NOSCRIPT section, link text may not be meaningful and multiple links missing skipover. Similarities included providing a summary and caption for tables and providing alternative text for images. Both highlighted keyboard accessibility.

Publishing Tools

There are robust Web development tools that provide wizards for HTML design. Other tools can convert word processor files such as Excel, PageMaker or Word Perfect into HTML code. Despite the availability of such tools, authors who are unaware of accessibility issues tend to create non-accessible sites by default.

Good Web tools should help the author develop accessible sites through prompts, automated tools, help files and alerts among other things. It should support all accessible content requirements and recommendations for HTML; identify non accessible or nonstandard HTML; and provide easy access to and easy edits of the html generated by the tool.

Text HTML Editors provide designers with control over presentation and content. Since the html document is basically a text document, virtually any word processing program can edit html. However there are web development tools that are text-based html editors. These include BBEdit and Homesite.

Visual HTML Editors separate the Web author from the HTML code by providing a graphical development interface. As a result these tools tend to favor appearance (presentation) over document structure.

Both Macromedia's Dreamweaver and Microsoft's FrontPage, which are popular cross platform graphical editors, contain an HTML viewer. Dreamweaver bundles either BBEdit or HomeSite as its text editor, while FrontPage provides its own editor. Neither product produces "out of the box" HTML 4.0 -compliant code. Dreamweaver's incorporation of the text editors allows both syntax check and compliance tips. There is no integrated syntax checker in FrontPage, which can lead to generating extraneous code.

If publishing suites and authoring tools supported accessibility within the application environment, accessible websites would be created more easily. The W3C recommended authoring tool accessibility guidelines, in order to help developers create authoring tools that produce accessible web content. The decision of incorporating these guidelines into such authoring tools, is up to the software developers.

The templates, produced by two popular authoring tools, were examined for W3C accessibility compliance. The results are shown in table 1a. The opening page and relative links were tested separately using Bobby as the validator. The overall site approval was based on compliance of all pages including the opening page.

While templates provide a look and feel for websites, they provide a basic design structure on which to build the site. If accessibility is stressed at this level, it may encourage and guide web authors to follow this pattern.

With the increasing use of Intranets, comes the demand for easy conversion of basic documents to HTML. Corporations can communicate, distribute information and facilitate project collaboration through the intranet. There are built-in HTML converters for products such as MS Office, Adobe PageMaker, QuarkXPress, Lotus WordPro and Corel WordPerfect.

In terms of web accessibility, such converters, however, are limited by the lack of structure in the original document, and focuses on presentation/appearance. Since HTML specifies document structure, the generated code may be syntax error prone. Ideally, code from converters should be checked by an HTML validator before publishing to the web.

Standard documents converted into HTML were analyzed for accessibility. The results are shown in table 1b.

Programming for Web Accessibility

Java incorporates accessibility into its platform, providing support to assistive technology with various API's7. The Accessibility API provides a clean interface that allows assistive technologies to interact and communicate with the Java Foundation classes and AWT components. Java's Accessibility Utilities help assistive technologies provide access to graphical interface toolkits that implement the Accessibility API. The Accessibility Bridge to Native Code is the medium through which existing assistive technologies on operating systems and Java's accessibility support can communicate.

The Java Speech API (JSAPI) covers speech recognition, synthesis and resource management. While speech applications are relatively safe, Java speech applets can pose security risks. In order to implement a speech applet on the internet, permission must be granted for that applet to access the JSAPI, which can be located in the client's file system or on a server. The JSAPI interacts with the client's speech engines, while the OBJECT and EMBED elements in the APPLET, directs the browser to the JavaSun's Plug-in.

While the use of Java applets enables a web page to obtain new capabilities with little user intervention, Java's intricate machinations can leave a computer vulnerable to attack. A hostile Java applet could tamper with a host system's files or siphon off private data without the user's being aware of the damage until it's too late.

Microsoft integrates the Microsoft Active Accessibility (MSAA) into the operating system8. It enhances the capabilities of adaptive devices and software applications. MSAA for Java includes java-based interfaces required by Java developers to create applications that are accessible, seamless and portable. Developers benefit from Java's cross-platform portability and MSAA's architecture and interface standards.

Microsoft's ActiveX controls, which can also enable web pages with speech recognition and synthesis has security issues similar to that of java speech applets.

Web Content

Hypertext Markup Language(HTML), created by the W3C, is the "lingua franca" for publishing on the World Wide Web. Although WAI was instituted by the W3C, the main battle lines are in the HTML protocol. It is here where many accessibility design conflicts arise and are dealt with.

One of the main concerns in designing web pages is how content is presented/rendered. When designing for the accessibility, one should consider the varying disabilities and the levels of severity. Catering to the needs of all people calls for dynamic design supported by HTML.

The W3C provides Web Content Guidelines to help authors to create accessible web sites. It serves to remind the designer of the users in various environments, such as not being able to hear, see, move or understand easily. These Guidelines come with technical support:

• Core Techniques for Web Content Accessibility Guidelines which deals with accessibility themes and general techniques that apply across technologies (e.g., validation, testing, etc.). http://www.w3.org/TR/WCAG10-CORE-TECHS/
• HTML Techniques for Web Content Accessibility Guidelines which provides examples and strategies for authoring accessible Hypertext Markup Language (HTML) content. http://www.w3.org/TR/WCAG10-HTML-TECHS/
• CSS Techniques for Web Content Accessibility Guidelines provides examples and strategies to help authors writing Cascading Style Sheets as part of accessible content design. http://www.w3.org/TR/WCAG10-CSS-TECHS

Using the guiding principles of the Web Content Accessibility Guidelines, a checkpoint system was devised to determine the level of accessibility of a web page. Each checkpoint has a priority level based on the checkpoint's impact on accessibility. There are 3 Priority levels which range from basic requirements (priority1) and removing significant barriers (priority2) to improving access to web documents (priority3). Conformance Level "A" means that all Priority 1 checkpoints have been satisfied. For Level "AA", all Priority 1 and 2 checkpoints have been satisfied. The highest level of Conformance, "AAA" indicates that all Priority 1, 2 and 3 checkpoints have been met.

Although the W3C's Web Accessibility Initiative(WAI) is recognized as the authority and central repository for the development of Web accessible guidelines, there are other organizations that have issued guidelines for Web Accessibility. These include IBM's Guidelines for Writing Accessible Applications using Java and Microsoft's Guidelines for Accessible Web Pages (See Appendix).

While there is support in the form of papers and working drafts from the WAI, for the average web page designer, it may be overwhelming.

Content Issues

Whatever guidelines the designer chooses there are several common issues and barriers which they seek to address. These issues include image rendering; use and navigation of tables, forms and frames; and multimedia (video).

Image Rendering
Since the web is highly graphical in nature, image rendering is very important. A blind/visually impaired user is likely to be using an alternative output such as a screen reader. HTML has the "ALT" attribute which allows description of image files. An image that does not include a textual description can be a barrier.

Table 2 shows the statistical data gathered from a number of existing websites. These websites were grouped into five categories: Airlines, Car Makers, Government, Online Trading and News Agencies. These groups were selected because they provide certain general services to consumers/users. The data looks at the percentage of ALT tags with a textual description compared to ALT tags without it. With this data we can also see how these categories vary in terms of image rendering.

Tables
The use of tables with screen readers can be tricky. Traditionally, screen readers read lines of information from left to right. When text is in columns, the screen reader would read across the lines ignoring column breaks. This could result in confusing output. Screen readers are now taking different approaches to rendering web content correctly, including reformatting the page into a single column.

Frames
Frames present a total comprehension problem. The implementation of frames focuses on layout not structure. The central concept is the FRAMESET element which defines the organization of a set of independent window regions (frames). This element is located in the only addressable HTML document of that web site. This addressable document acts as a container for the files that will be displayed in the specified window regions in the browser.

The URL does not change as a user navigates his way through the site and there is no other mechanism to keep track of where the user is. Therefore the current location within the site cannot be expressed as a URL.

Screen readers or self-voicing browsers can identify the number of frames on a web page, but they cannot track multiple events in these frames. They can only follow one frame at a time. Providing an alternative page for users who cannot render framed content properly is important. The HTML element NOFRAMES can be used. Figure2 and table 3 shows the percentage of FRAMESET elements located within the grouped websites from table 2.

Forms
Complex online forms containing multiple groups of input boxes without HTML support can be a problem. HTML syntax supports shortcut keys, form controls and grouping mechanisms. With the ACCESSKEY attribute, web designers can provide keyboard access to elements in a Web page. The TABINDEX attribute give web authors control over the order of the tabbing. A user can tab through links as well as forms. Both the AccessKey and TabIndex attributes provide a good basis for creating accessible forms. There are other form-specific elements that can be used such as SELECT, OPTGROUP, FIELDSET and LEGEND.

Navigation
The navigation of forms, tables and frames can be an arduous task for anyone. Visual cues help users with vision to navigate, however for blind users it could be utterly impossible. Implementation of audio cues in conjunction with visual cues can help to alleviate these problems.

Multimedia(Video)
For the blind/low vision user, additional narrative in a descriptive video is important for the comprehension of the electronic document. For the Deaf and Hard of Hearing close caption and text description are possible solutions.

Validating/Approval and Analysis

The government category has the highest rate of approval. This may be due to the fact that the US government issued a mandate for all federal online agencies to comply with accessibility. Both the News Organizations and Online Travel Agencies have an extremely low rates of approval. There were different categories within the news organizations. There included daily and business publication, local radio/tv media,, regional/international tv and internet-only based news groups. Daily and business papers has a 0% approval rate, while local tv stations has a 60% approval rate. Regional/international and internet based news groups had a 0% approval rate.

Throughout the categories, the lowest percentage of errors are the priority 1 errors. This makes sense since this priority provides for the basic accessibility requirements. These errors are relatively easy to avoid. Priority 1 errors deals with providing alternative text for images, image-type buttons, and image map hot spots among other things.

The highest percentage are the P2 errors which deals with removing significant barriers. These include using relative sizing and positioning rather than absolute; not refreshing the page automatically and making sure event handlers do not require use of a mouse.

Table 4b looks at the most frequently occurring errors among the websites surveyed. For each category the percentage is taken for the number of a specific priority error among that priority level. For example in the Government category(C3), 75% of all P1 errors are not providing alternative text for all images. The empty boxes indicate that the errors, if they occurred, had a much lower frequency level. The values that are reported are either the most frequent, or close in percentage points to the highest.

The previous survey tested only for the opening page of the website. However it is unlikely that these websites consists of only one page. In the following survey a smaller number of sites were selected within each group and tested for its front page and relative links. The results are shown in table 4c.

Structure and Presentation

Some common structural archetypes on the web include linear, drill-down, chunky and single-note patterns. The linear structure consists of pages that progress in a straight line or page to page like a book, while online catalogs and resource pages are often set up using the drill-down type. The drill-down type consists of a home page followed by a top tier with sub topics below it on another level.

Chunky structure which consists of a home page with a number of sub-pages on various topics is popular on "home" pages or sites which discuss several distinct topics. The single-note type, the simplest of web pages, contains a concise handling of a single topic, such as a virtual business card. Many small businesses opt for this type of site to establish a web presence.

Irrespective of the types used, it is important to have a meaningful navigational structure when designing for accessibility. When designing a web page or a web site, time should be spent on deciding where things will go, how to attract the target audience and page layout.

HTML editors can isolate the web-author from the actual HTML coding. This takes part of the structural decision-making out of the hands of the designer and into the automated editor. While the editor takes the job of coding away, it also cannot comprehend the topic and make intelligent structural decisions.

Graphical editors pay more attention to the presentation and appearance of the website than structure. However placing more emphasis on presentation can bar groups of disabled users, which may be counter productive to the designers intentions of increasing their target audience.

An organized structure signals good design and can employ good overall design techniques. It is key to good web site development and an efficient way to make it accessible. A good structure will expose the needs of the document in determining which HTML elements/attributes to use to ensure accessibility.

One of the drawbacks for HTML is that several webpage objects such as tables can be used in ways that was not intended. For example, tables can be used for spacing and positioning non-textual objects onto the web page. Blank picture files can be placed on a web page for positioning other objects. A screen reader may have trouble producing comprehensible output.

Accessibility validators/editors such as Bobby and A-Prompt are limited, since they cannot automate comprehension. There is yet no automated way to determine if the content of the webpage is fully comprehensible.

A sound structure provides a framework for the presentation which can be tailored to suit people with different operating environments, without compromising the integrity of the basic structure.

A web site that can dynamically provide for all people with differing operating environments can be useful in leveling the "playing field" in the Internet world. An equalizer of some sort. Although the web has not yet reached that plateau, it is not impossible to envision it in the near future.

WAI is involved in the creation of industry supported guidelines for content design, publishing and user agents. These guidelines are considered working drafts, since they are subsequently open to future revisions.

The following Content Accessibility Guidelines are designated as high priority items. These deal with Web page design involving images, programming scripts, navigation, multimedia, forms, frames and tables:

• Provide equivalent alternatives to auditory and visual content
• Don't rely on color alone
• Use markup and style sheets properly
• Clarify natural language use
• Create tables that transform gracefully
• Ensure that pages featuring new technologies transform gracefully
• Ensure user control of time-sensitive content changes
• Ensure direct accessibility of embedded user interfaces
• Design for device-independence
• Use interim solutions
• Use W3C technologies and guidelines
• Provide context and orientation information
• Provide clear navigation mechanisms
• Ensure that documents are clear and simple

• These guidelines are used to help developers create authoring tools that produce accessible web content:
• Support accessible authoring practices
• Generate standard markup
• Support the creation of accessible content
• Provide ways of checking and correcting inaccessible content
• Integrate accessibility solutions into the overall "look and feel"
• Promote accessibility in help and documentation
• Ensure that the authoring tool is accessible to authors with disabilities

WebTV, pagers, palm pilots, cell phones and kiosks are some of the types of user existing agents. More common ones include Netscape, Internet Explorer, Opera and Lynx. These guidelines provide direction regarding the development of accessible user agents:

• Ensure that the user interface is accessible
• Ensure that user agent accessibility features are configurable
• Ensure that users can disable features that might interfere with accessibility
• Provide summary information about keyboard access
• The user agent must render information accessibly
• Allow the user to control document styles
• Provide information about the content and structure of a document and the user interface
• Provide information about events that occur
• Allow keyboard navigation of the document and views of the document
• The user agent must make information available to other technologies
• Use and provide accessible interfaces to other technologies

IBM Special Needs Systems is a pioneer among corporate disability organizations. IBM SNS has been vigorously involved in accessibility standards and guidelines from the beginning. IBM SNS focuses on the essentials of accessible Web design while still supporting the WAI guidelines. These guidelines highlight the following:

• Use ALT="Text" attribute to describe the function of visuals
• Use client-side image maps
• Provide captions or transcripts for audio. Provide text or audio description for video
• Provide alternate content for scripts, applets and plug-ins
• Markup content with proper structural elements. Use Cascading Style Sheets(CSS2)
• Summarize content of each graph and chart
• Provide a title for each frame
• Use the header, caption, and summary tags for tabular data
• Use descriptive link text
• Check accessibility using the available tools

Microsoft also provides a checklist of guidelines for creating accessible Web pages:

• Use good ALT text for all graphics
• Use image maps properly
• Provide useful link text
• Enable good keyboard navigation
• Provide alternatives to all controls and applets
• Create alternate pages that don't use frames
• Ensure proper use of tables and their alternatives
• Support the reader's formatting options
• Don't require the use of style sheets
• Use file formats the reader can use
• Avoid using scrolling marquees
• Provide titles for most objects