Accessibility Transformation Gateway Bambang Parmanto, Reza Ferrydiansyah, Xiaoming Zeng, Andi Saptono, and I Wayan Sugiantara Health Information Management Department, School of Health and Rehabilitation Sciences, University of Pittsburgh E-mail: {parmanto, ref11, xizst9, ans38, iws1}@pitt.edu Abstract We developed a transcoder gateway that is designed to transform any website on the fly and to adapt the website to the user’s preference and limitations. The gateway applies accessibility rules during transformation to lift accessibility barriers from a webpage. We report both the results of a pilot study and a usability study of visuallyimpaired users utilizing the gateways.

1. Introduction Despite good progress in making people aware of the Web accessibility issues for persons with disabilities, the Web remains fairly inaccessible [1]. Our study suggests that Section 508 has been successful in making federal government websites relatively accessible and that accessibility guidelines are especially making progress in educational websites [2]. This same study however, also reveals that other categories of websites, namely corporation, community, e-commerce, and portal websites, remain largely inaccessible. As the complexity of websites increases due to new technology, the problems of inaccessibility only gets worse [3]. The number of unique web pages was estimated at 2.1 billion pages as of July 2000, growing at a rate of 7.5 million pages per day [4]. The total number of deep hidden web pages, Web connected back-end databases, is estimated at 550 billion invisible Web documents [5]. The Web is not only characterized by its sheer enormity but also by its fluidity: websites constantly change. This factor also decreases the overall accessibility of the web. The efforts in making the Web more accessible can be categorized into three fronts: the client side, the server side, and via a transcoding intermediary. Efforts on the server side include guidelines for writing accessible Web sites [6]. Richards and Hanson [7] argues however that the redesign of websites may be costly. Efforts on the client side include development of adaptive browsers or screen readers [8, 9]. Another front to make the Web accessible is the automatic transcoding intermediary [10, 11]. The transcoding intermediary is a server that transcodes web pages according to some transformation rules. In

considering the size and the general inaccessibility of the Web, this approach has great potential in supplementing the other two approaches.

2. Related Work The first accessibility transcoder was probably WAB [12], an HTTP proxy developed in ETH Zurich that was not customizable. It modifies HTML to assist users who are blind. Asakawa & Takagi [10, 11, 13] developed a customizable transcoding server using the IBM Websphere Transcoding Publisher. This transcoder also uses knowledge specific to websites to enhance the accessibility transformation. A transcoding proxy aimed at the elderly was also built by Richards and Hanson [7]. Silas Brown [14] developed a customizable gateway for low-vision users that does not use the site-specific knowledge concept. The broad objective of our gateway is to adapt any website by transforming it to the users’ preferences and limitations, especially for users with disabilities. This paper discusses the initial development of the gateway that implements transformation rules based on the Web Content Accessibility Guidelines 1.0 (WCAG)[6]. The gateway checks whether a web page conforms to the WCAG and transforms the elements that do not conform to the WCAG. This transcoding process is done in real time; the gateway does not store a transcoded page in the cache. This paper also reports the results of the usability study of the gateway on users with visual impairments.

3. WCAG WCAG is used as the primary guideline for transformation since it addresses broad issues on accessibility for persons with disabilities. Although it is not perfect, conformance to WCAG leads to more accessible websites. The WCAG is intended mainly as a design guide. The WCAG contains a total of 14 broadly phrased guidelines. The 14 general principles for WCAG are: 1. Provide equivalent alternatives to auditory and visual content. Don't rely on color alone. 2. Use markup and style sheets and do so properly. 3. Clarify natural language usage.

Figure 1. Transcoding gateway framework 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

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.

Each of these general principles is elaborated in checkpoints. These checkpoints explain how the guideline applies in the development scenarios. There are a total of 65 checkpoints in the WCAG. Details on the checkpoints are given in the WCAG documents. Each checkpoint is given a priority level according to the impact that fulfilling/not fulfilling the checkpoint has on accessibility. Priority 1 checkpoints are for those checkpoints that must be satisfied or it will be impossible for one or more groups to access the page. Priority 2 checkpoints are for violations that make it difficult for one or more groups to access the page. Priority 3 checkpoints are for violations that make it somewhat difficult for one or more groups to access the page.

4. Gateway Framework We developed the gateway from the ground up, using components from the Open Source community whenever possible. Figure 1 shows the framework of our transcoder. Figure 1 (a) shows the usage of the gateway by a user,

who treats the application as a gateway to the Web. Figure 1 (b) gives a more detailed view on the gateway. When a user needs to access a webpage, instead of directly entering the webpage Uniform Resource Locator (URL), the user types the URL of the gateway. The user will then input the URL of the webpage into the gateway. The gateway receives the URL input and forwards the user’s request to the correct Web server. The gateway also forwards any input, including webpage forms. The gateway receives the response page from the Web server and transforms this page according to accessibility and usability rules. The first step of the gateway is getting the Document Object Model (DOM) structure of the page. A DOM structure presents documents as a hierarchy of Nodes objects [15]. The hierarchical nature of the DOM makes it easier to process the content of the document compared to the original text document. Asakawa and Takagi’s transcoder [10, 13] uses a DOM tree as a basis to annotate web pages and to rearrange individual elements in a webpage. Another study uses the DOM tree to extract the content of a page by removing unnecessary layout elements [16]. The gateway then transforms the page according to the accessibility transformation rule. Details on this process are given in the next section. The resulting transformed page is then returned to the user. All connection is done via the gateway and it will appear that all pages come from the gateway instead of the real web servers. The user receives a transformed webpage that can be easily rendered by screen readers or other assistive technologies. The objective of the gateway is to transform any webpage on the fly. To achieve the objective, the gateway is designed to follow the following principles:

1. Equivalence. We expect the transformed page to have the same meaning as the original page. When transforming, the application may decide to move, add or delete elements. This process should not change the overall meaning of any information contained in the original page. 2. Accessibility. The transformed page should be accessible to users according to the rules set out in Web Content Accessibility Guidelines 1.0 (WCAG). 3. Speed. Speed is a very crucial issue for the gateway. The time difference between using the gateway and not using the gateway should be negligible. Since we have no control over the network speed, we must utilize fast algorithms for the gateway. 4. Flexibility. The gateway is scalable, enabling the addition of new elements and rules. The gateway is also designed to be multi-modal, in the sense that the gateway can be used for more than one type of transformation. This principle allows us to create transformation aimed at different types of disability.

5. Accessibility Transformation Our accessibility transformation rules are based on the Web Content Accessibility Guidelines 1.0 (WCAG)[6] checkpoints. We assume that the accessibility of a webpage can be increased by fixing violations of the WCAG rules. An example is the checkpoint “Provide alternative content for all image-type buttons in forms” which is a checkpoint for the first guideline. This checkpoint is converted to the following rule: if input element and type attribute =”image” then if alt attribute is not empty then replace the image button with the value of alternative text else if title attribute is not empty replace the image button with the value of title attribute else replace the type to "submit" The main problem in creating these transformation algorithms is that WCAG checkpoints are originally intended as design guidelines. Some of the checkpoints are difficult to convert to transformation rules. For these rules, we may create a solution that will give an approximate conformance to that checkpoint, or we may not convert the checkpoint at all. One example of a non-convertible rule is the checkpoint that states “each image should have an alternate text describing the context of the image”. When the image tags does not have alternate text, the context of the image must be found by either looking at the context or by trying to recognize the image. Such an algorithm is still impractical using present technology due to its

inaccuracy or speed. Therefore we had to be satisfied with adding the name of the file as the alternative text. We grouped transcoding rules into two major categories: tag-based rules and site-based rules. Tag-based rules apply to the individual HTML tags of a page. For example, the rule “every image should have an alternate text to describe the context of the image” is a tag-based rule because it applies to the tag. Site-based rules are mostly complex rules, usually rules applicable to a segment of a page consisting of more than one tag or rules for page layout. In total, we created 25 rules from 65 checkpoints. Regardless of the priority level of the checkpoints given by the WCAG working group, we tried to transform each checkpoint to a corresponding rule with some notable exceptions: 1. We do not transform a checkpoint to a rule when the rule would necessitate an understanding of the context or content of the segment to transform it properly. The reason for this constraint is that creating a system that understands content is too difficult and building such a system will distract us from our main focus. 2. Checkpoints that required documents to conform to a particular standard were ignored. Transforming whole pages to conform to a particular standard would slow down the process yet still gives the same look and structure to the page. 3. We ignore checkpoints that required us to create equivalent information for segments that use technology that may be non-accessible (for example flash or javascript). This information can only be correctly given by the creator of the site and should not be created by the intermediary. Based on those criteria, the rules that were eventually chosen are: 1. Provide alternative text for all images 2. Provide alternative text for each applet 3. Provide alternative content for each OBJECT 4. Provide alternative content for all image-type buttons in forms 5. Provide alternative text for all image map hot-spots 6. Client-side image map contains a link not presented elsewhere on the page 7. Use a public text identifier in a DOCTYPE statement 8. Use relative sizing and position (% value) rather than absolute (pixels). 9. Nest headings properly 10. Identify the language of the text 11. Linearize table layout 12. Each Frame must reference an HTML code 13. Provide a NOFRAMES section when using FRAMES 14. Change blinking text created with the BLINK element 15. Change scrolling text crated with the MARQUEE element 16. Do not cause a page to refresh automatically

17. Do not cause a page to redirect to a new URL 18. Make sure event handlers do not require use of a mouse 19. Include default, place-holding characters in edit boxes and text areas 20. Separate adjacent links with more than white space 21. Give each frame a title 22. Explicitly associate form controls and their labels with the LABEL element 23. Create link phrases that make sense when read out of context 24. Do not use the same link phrase more than once when the links points to different URLs 25. Include a document TITLE As noted before, our infrastructure relies on the DOM tree extracted from the webpage. The gateway traverses the DOM structure of the page, visiting each element tag of the page. On each tag we call a rule function corresponding to the currently traversed tag. The function checks for possible infringement to any of the 25 rules we created and, on finding an infringement, transforms the text to conform to the accessibility rules. Of these two rule categories, most accessibility rules are tag-based rules. Therefore, our focus in accessibility modification is on heuristically creating transformation algorithms for the WCAG tag-based rules. Some heuristic methods to find the elements of an HTML page were employed to help improve the response time of the transformation to meet the speed and correctness constraints. To extend the flexibility of the system, we expand the infrastructure to allow multiple object rules on a type of tag. This infrastructure enables us to shape the modification according to the user's preferences and helps us to address different types of user abilities without cluttering the algorithm to match every possible ability or disability. It is worth noting that our approach to implementing accessibility rules is different from that of Takagi & Asakawa’s (TA) transcoder [17]. The TA Transcoder uses the results of an external analyzer (Bobby) to create rules to fix WCAG violations. The rules are then stored in the proxy server, ready to be applied when needed. This approach might be suitable for a limited set of web pages and could potentially be an efficient transformation since the transcoder only addresses the violated checkpoints. Unfortunately, this approach would require an extensive amount of space if the goal of the transcoder is to transform any webpage in the world. Since our goal is to transform any webpage, we propose a different approach.

6. Accessibility Transformation Results The gateway was tested to transform a number of sites. One of them was the Pittsburgh Post Gazette, a local newspaper (http://www.post-gazette.com)[18]. We tested the site on Bobby, an online accessibility tester [19]. Bobby claims that the Post-Gazette site does not conform to the WCAG. In particular, Bobby finds 116 priority 1 violations, 108 priority 2 violations, and 18 priority 3 violations. Figure 2 shows the original Post-Gazette page. The transformation based on our gateway is shown in Figure 3. Some screen readers have trouble reading this page because they tend to read the text horizontally per line, even though a page may be divided into 2 or more parts vertically such as the Post-Gazette page shown here. Section A in the original page is an inline frame. In the transformed page, the inline frame is deleted. The content of the inline frame is not shown in this page; instead the content can only be accessed by clicking the link (shown in figure 3). The structure of the page shows that part C comes before part B, even though B is rendered in the left of C in the original page. However because our gateway transforms the page based on the structure, part C comes before part B. Notice also that the title in part C is changed to a normal text without the grey background. Both Part B and part C are taken out of the column format, making it easier for screen readers to read. This transformation is based on the checkpoint that states that tables should not be used for layout. This compels us to linearize tables, which results in the page shown in figure 3. The transformation shown here is transformation for the blind. Therefore the gateway also deletes all images and replaces them with the text ‘[IMAGE: ]’. Testing the transformed page, Bobby finds no priority 1 violations, 69 priority 2 violations, and 142 priority 3 violations. The priority 2 violations detected by Bobby include the need to use relative sizing and positioning rather than absolute pixels (61 instances). These violations were found on font size. The rest of the violations were: creating link phrases that make sense when read out of context, providing explicit labels for each form control and using different link phrases when links point to different URLs. Unfortunately our gateway needs to know the context of the text before being able to fix these violations. Therefore none of these violations were changed.

Figure 2. Pittsburgh Post Gazette Page

The priority 3 violations are that the WCAG expects more than white space to separate links (for example links may be separated with the ‘|’ character). However, our experience using screen readers suggests that these separator characters are read aloud by the screen readers, thus resulting in a more confusing set of sentences.

7. Usability Study We conducted a usability study to explore the effect of our gateway server on blind Web users using screen readers. The study was conducted at participants’ house or office, whereever they use the Internet most often. By observing the participants working in their natural environments, we gain not only an ecological validity but also insight into how the participants use their computers in daily life.

7.1. Participants Sixteen participants were recruited from the local Pittsburgh area via local vision services and blind computer user groups. Six out of the sixteen participants are female. The participants range from 30 to over 65 years of age. On average, they have 5.8 years of experience using screen readers, 4.6 years of experiences with the Internet, and 4.1 hours of daily usage of the

Figure 3. Transformed page

Internet. All participants use the JAWS screen reader with thirteen of the sixteen (81.25%) using version 5.0 and the rest using version 4.5. Because JAWS provides integrated functions with Internet Explorer, all participants used Microsoft Internet Explorer as their only Web browser.

The participants are involved in many online activities: 100% use email, browse the Web, and use the Web to search for information; 62.5% listen to online radio or music; 50% had previously shopped online; 31.3% played online games or mentioned reading books online; 12.5% participated in online chatting.

7.2. Study Design The study design is a within-subject crossover study. Each participant accessed both original websites and the websites transformed by our gateway server. Half of the subjects accessed the original website first, then the transformed website. Half of the subjects accessed the websites in the opposite way. The benefits of the crossover design are: eliminating the between subject variance, decreasing the size of the sample needed, and identifying possible learning effects. Learning effects occur when participants rely on experiences obtained in the first leg of study to implicitly improve their performance in the second leg. Because listening to the synthesized speech from a screen reader can easily cause fatigue for blind Web users, we asked subjects to take a break between the first and the second leg of the study. The break also serves as a washout period to reduce the learning effect on the performance in the second leg.

7.3. Outcome measurements We used time spent on each task as the objective measurement to assess the efficiency of the gateway server for blind Web users. Success and error rates were used to measure the effectiveness of the gateway server for blind Web users. Success rate measured whether the participant could finish the task in time and find the correct answer. Error rate measured the number of erroneous Web pages a participant visited before finishing the task. On the other hand, we used questions with a 7-point Likert scale to measure the subjective effect – satisfaction, frustration, and confidence – of the gateway server on the blind Web users. • Could you indicate the degree of your satisfaction with the websites using a 7-point scale – one is the least satisfied, seven is the most satisfied? • Could you indicate the degree of your frustration with the websites using a 7-point scale – one is the least frustrated, seven is the most frustrated? • Could you indicate the degree of your confidence with the websites using a 7-point scale – one is the least confident, seven is the most confident?

7.4. Tasks We included two types of usability tasks in our study. The first task is related to online browsing and information gathering. The participants visited a local newspaper website, read the headline news of different sections, and found the names of the journalists who wrote the articles. The second task pertains to online shopping. The participants visited a bookstore website to locate a bestselling book. They also needed to find the different formats in which the book is available and put their favorite format into the shopping cart. Table 1 describes the detail of each task. Although the same websites appears in both legs, the tasks performed on the website are slightly different to reduce the learning effect. The similarity of the tasks from the same website at different legs will minimize the performance difference caused by task variation. Table 1. Tasks of the usability study Leg Websites Tasks 1 http://www.postRead the top headline news at gazette.com the local news section. Find out the name of the reporter who wrote the news. http://www.books Locate the No. 1 bestselling fiction book, find out the amillion.com different formats of the book, and put one copy (in any format) in the shopping cart. 2 http://www.postRead the top headline news of gazette.com the U.S. news section. Find out the name of the reporter who wrote the article. http://www.books Locate the No. 1 bestselling amillion.com non-fiction book, find out the different formats of the book, and put one copy (in any format) in the shopping cart.

7.5. Results The results are very encouraging and suggest the potential of the gateway to improve accessibility & usability of the Web for persons with disabilities.

and non-gateway access. In task 1, 81.25% of the participants can find the right answer via gateway server, while 56.25% of them find the correct answer via nongateway. In task 2, 62.5% of the participants can find correct answers via the gateway server, while 43.75% of them can find the right answers accessing the original websites. This indicates that participants tended to find more right answers via the gateway server than by visiting the original websites. It also indicates that participants were more likely to find the right answer for task 1 than task 2. This also matches the level of complexity of each task.

Figure 4. Time (mean and standard deviation) of each task via gateway or non gateway Figure 4 depicts the mean and standard deviation of the time participants spent on each task through the gateway server or original websites. On average, participants spent less time finding information through the gateway server than accessing the websites directly in both tasks. They spent less time on task 1 than on task 2, which is proportional to the level of the complexity of the tasks.

Figure 6. Number of errors of each task via gateway or non gateway Figure 6 illustrates the mean and standard deviation of the number of errors that participants made in each task via the gateway or non-gateway server. It shows that the gateway server can help participants make fewer erroneous visits to unrelated web pages as compared to the original website. It also shows that the number of errors increase when the complexity of task increases.

Figure 5. Percentage of success levels for each task via gateway or non gateway Figure 5 shows the percentage of different success levels – not finished, finished with incorrect answer, and finished with correct answer – of each task via gateway

Figure 7. Subjective measurements (satisfaction, frustration, and confidence) after visiting websites via gateway or non gateway server

Figure 7 lists the mean and standard deviation of each subjective variable—satisfaction, frustration, and confidence—after finishing the performance test through the gateway or non gateway server. On average, participants feel more satisfied, less frustrated, and more confident when using the gateway server than when accessing the original websites. We conducted a series of mixed model analysis on each measurement variable as dependent variable. The independent variables included in the model are: study periods, participants, and intervention (gateway or nongateway). Table 2 lists the p-value of design (the sequence of the study), period (period 1 or 2), and intervention (gateway or no gateway) from the mixed model analysis of the time on the tasks. The outcome of the mixed model analysis is the time of each task. For each task, the design variable does not have a statistically significant effect on time (p ≥ 0.05) This indicates that each participant is randomly assigned to different sequences. The period variable also has no statistically significant effect on the time the participant spent on task. The intervention variable is the variable indicating the effect of our transcoder server. It is the only variable that has a statistically significant effect on each task. Table 2. p-value of mixed model each task Time on Task 1 Design 0.1780 Period 0.3162 Intervention 0.0356

analysis of time on Time on Task 2 0.6165 0.8028 0.0168

Table 3 lists the p-value of the design (the sequence of the study), period (period 1 or 2), and intervention (gateway or no gateway) variables from the mixed model analysis of the number of errors on each task. The outcome of the mixed model analysis is the number of errors in each task. For each task, the design variable does not have a statistically significant effect on the number of errors. This indicates that each participant is randomly assigned to different sequences. The period variable has no statistically significant effect on the number of errors participants made during the study. The intervention variable is the variable indicating the effect of our transcoder server. It is the only variable that has a statistically significant effect on task 2.

Table 3. p-value of mixed model analysis of errors on each task Errors on Task 1 Errors on Task 2 Design 0.1042 0.6994 Period 0.9125 0.3556 Intervention 0.1166 0.0038 Table 4 lists the p-value of the design (the sequence of the study), period (period 1 or 2), and intervention (gateway or no gateway) from the mixed model analysis of each subjective variable. The outcome variables of the mixed model analysis are the subjective variables in the study – satisfaction, frustration, and confidence. For each task, the design variable does not have a statistically significant effect on any of the subject variables. This indicates each participant is randomly assigned to different sequences. The period variable has no statistically significant effect on how the participant feels about the websites. The intervention variable is the variable reflecting the effect of our transcoder server. It is the only variable that has a statistically significant effect on each subjective variable. Table 4. p-value of mixed model analysis of the subjective measurements Satisfaction Frustration Confidence Design 0.1780 0.6165 0.6313 Period 0.3162 0.8028 0.6858 Intervention 0.0356 0.0168 0.0212 The results from the mixed model analysis shows that the gateway server has a statistically significant effect on time, error rate, and subjective measurements of the participants accomplishing the designated tasks. According to the mixed model analysis, the period of the gateway usage and other personal differences among participants have no statistically significant effect on the outcome variables.

7.6. Observational Findings and Feedbacks From the quantitative data, we found that accessibility oriented online transcoding could improve the usability – effectiveness, efficiency, and satisfaction – for blind Web users. However, the Web, despite efforts to enhance the accessibility, still presents a challenge to blind Web users. One of the researchers (XZ) shadowed the subject visiting websites and took notes of interesting findings. The following is the list of observations from the pilot study: Later versions of JAWS (> version 4.02) have a feature that can retrieve all headings (h1 - h6) in the HTML file after it is loaded, blind Web users usually rely on this

feature to navigate directly to the destination. They also utilize this feature to circumvent the repetitive and tedious navigation menu. Navigation menus usually are placed at the top or right side of the page that will appear first from the JAWS readout. Because of this finding, we implemented preliminary heuristics to find out possible headings at different sections of a webpage. Although some pages may take the suggestion of better navigability for blind Web users by adding a “skip to the main content” at the beginning of the navigation menu, it may not be practical for novice users of screen readers. Our subjects let the screen reader read out a page for them. When they hear the “skip to the main content” link, usually it is too late to press the “ENTER” key to follow the link. Therefore, in addition to the “skip to the main content” hyperlink, we also add an implicit heading coded as “

” to indicate the starting point of the main content. The usability of this approach needs further exploration. JAWS versions 4.5 or later allow users to choose different levels of verbosity. If the user selects “read out links,” JAWS can add a readout “link” after each hyperlink. This eliminates the initial problems presented by adjacent links as required by WCAG. We suppressed the implementation of adding brackets between adjacent links to accommodate newer versions of JAWS. However, whether this approach is universally acceptable by all assistive technology users is uncertain. WCAG 1.0 defines “Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.” Although the latest version of JAWS still does not have the ability to handle empty controls, putting default characters inside a text field or area as hints may cause usability problems for novice assistive technology users. For example, our pilot testers often forget to remove the default text before inputting any character in the text input or area. As long as the label of the form element is closely bound to the element itself, it is not necessary to put default text inside an input field. We removed our original implementation of putting default text in input areas as a reminder to accommodate novice users of screen readers or browsers. One common theme from our observations is that other aspects of usability, such as navigability, could be as important as accessibility. For example, a page can be free from accessibility violations, but it may still be difficult to use by a blind user if it does not provide contextual support or shortcuts. On the contrary, if a page provides screen reader-friendly contextual information such as informative headings and hyperlinks, it would be more usable for the blind user even if it contains syntactical violations of the Web accessibility guidelines. Many participants made such statements as “I don’t care whether the image has alternative text or not. I only care whether the site can help me find the information I am interested

in.” This indicates Web accessibility guidelines are only useful to a certain extent. Other aspects of usability such as navigability should also be addressed when designing websites for persons with disabilities.

8. Conclusion A lot of work has been done in creating a more accessible Web. The fact remains that the Web is still fairly inaccessible to persons with disabilities. One reason is the introduction of new technology that increases the complexity of the Web [3]. Another reason is the fact that not everyone is concerned about accessibility, thus Web pages are still not designed with accessibility in mind. Without effort from the designers, tools such as screen readers are not effective in helping users navigate the World Wide Web. The W3C has also paid attention to these accessibility issues. One of the results of their work is the Web Content Accessibility Guidelines. WCAG is used as the primary guideline for transformation since it addresses broad issues on accessibility for persons with disabilities. Although it is not perfect, conformance to WCAG leads to more accessible websites. In our work, we developed a transcoding gateway that transforms a webpage based on transformation rules. These transformation rules are converted from the 65 WCAG checkpoints. Based on those checklists we were able to create 25 rules. The other checkpoints were impractical to convert to rules and were therefore ignored. We evaluated the usability of the transcoding technology for users with visual impairments on two representative tasks. We evaluated the usability of the web in terms of the speed, the success rate, and the correct rate of the users in accomplishing the tasks. We also used subjective measurements (satisfaction, frustration, and confidence) to measure the usability of the gateway compared to the accessing the web directly without the gateway. Our studies show that the time to complete a task decreases and the success rate increases when people used our gateway instead of accessing the Web directly. On average, participants feel more satisfied, less frustrated, and more confident when using the gateway server than the original websites. The results suggest that our transcoding server that transforms webpages according to 25 transformation rules is successful in increasing the accessibility of webpages to visually impaired users. We note that our work also reinforces the assumption that converting a webpage to better meet the Web Content Accessibility Guideline will make it easier for disabled users to use the webpage in their daily lives.

9. References [1] Lazar, J., A. Dudley-Sponaugle, and K. Greenidge, Improving Web Accessibility: A Study of Webmaster Perceptions. Computers and Human Behavior, 2004. (in press). [2] Zeng, X. and B. Parmanto. Evaluation of Web Accessibility of Consumer Health Information Websites. in Proceedings of AMIA Symposium. 2003. Washington, DC. [3] Hackett, S., B. Parmanto, and X. Zeng. Accessibility of Internet Websites through Time. in ACM Conference on Assistive Technology. 2004. Atlanta, GA: ACM. [4] Murray, B.H. and A. Moore, Sizing the Internet, in White Paper Cyveillance. 2000. [5] Bergman, M.K., The Deep Web: Surfacing Hidden Value. The Journal of Electronic Publishing, 2001. 7(1). [6] WAI, http://www.w3.org/TR/WCAG10/, accessed 8/1/2003 [7] Richards, J.T. and V.L. Hanson. Web Accessibility: A Broader View. in WWW 2004. 2004. New York, USA. [8] Zajicek, M. and S. Hall. Solutions for elderly visually impaired people using the Internet. in Proceedings of People and Computers XIV Usability or Else. Sept. 2000 Sunderland, UK. 2000: Springer-Verlag London, London, UK. [9] Stephanidis, C. Universal Access Through Unified User Interface. in CSUN 2000: Technology and Persons with Disabilities Conference. 2000. California State University Northridge. [10] Asakawa, C. and H. Takagi. Annotation-Based Transcoding for Nonvisual Web Access. in ASSETS'00

Proceedings of the Fourth International ACM Conference on Assistive Technologies. 2000. Arlington, VA: ACM. [11] Takagi, H. and C. Asakawa. Transcoding Proxy for Nonvisual Web Access. in ASSETS'00 Proceedings of the Fourth International ACM Conference on Assistive Technologies. 2000. Arlington, VA: ACM. [12] Kennel, A., L. Perrochon, and A. Darvishi, WAB: World Wide Web access for blind and visually impaired computer users. ACM SIGCAPH Computers and the Physicially Handicapped, 1996(55): p. 10 - 15. [13] Takagi, H., et al. Site-wide annotation: reconstructing existing pages to be accessible. in ASSETS 2002. Proceedings of the Fifth International ACM SIGCAPH Conference on Assistive Technologies. 8 10 July 2002 Edinburgh, UK. 2002: ACM, New York, NY, USA. [14] Brown, S. and P. Robinson. A World Wide Web Mediator for Users with Low Vision. in CHI 2001 Workshop No. 14. 2001. [15] W3C, http://www.w3.org/TR/1998/REC-DOM-Level-119981001/, accessed February 3, 2004 [16] Gupta, S., et al. DOM-based Content Extraction of HTML Documents. in Proceedings of the Twelfth International World Wide Web Conference, WWW2003. 2003. Budapest, Hungary: ACM. [17] Takagi, H., et al. Realizing Site-Wide Compliance by Linking Tools for Web Accessibility. in CSUN. 2003. California State University Northridge, CA, USA. [18] Gazette, P.P., www.post-gazette.com, accessed June 10, 2004 16:21 EST [19] Bobby, http://bobby.watchfire.com/, accessed June 10, 2004 16:30 EST