Visualizing the Accessibility of HTML Tables for Web Page Developers

Transcription

1 Visualizing the Accessibility of HTML Tables for Web Page Developers Dorian Miller University of North Carolina at Chapel Hill Sitterson Hall, CB# 3175 Chapel Hill, NC USA Hironobu Takagi, Kentarou Fukuda, Chieko Asakawa Tokyo Research Laboratory, IBM Japan Shimo-tsuruma, Yamato-shi, Kanagawa-ken, Japan {takagih, kentarou, Abstract Web accessibility for blind users can be improved by the Web developers who create Web pages. It is challenging because accessibility issues go beyond a Web developer's main focus, the visual appearance of a Web page. Two Web pages could appear visually identical but one could be accessible and another inaccessible depending on the HTML implementations. We developed a table visualization tool to help Web developers efficiently verify the accessibility of HTML tables, an important component of Web pages. Our tool visually simulates the interaction a blind person has with a screen reader, a program enabling blind persons to control a computer s Graphical User Interface (GUI). We prototyped our tool and evaluated its merits in a user study. Our user study showed that a participant evaluates the accessibility of an HTML table 25% faster with our tool than with the alternative method of using a screen reader. Despite this advantage, our tool does not replace the screen reader when teaching sighted users about a blind person s experience with a screen reader. Overall, we hope our tool will help Web developers become more aware of accessibility issues and therefore improve Web accessibility. 1 Motivation Web accessibility is vital for persons with visual impairments to obtain information from the Web about everything in their lives, from work to leisure. Through accessible Web pages, companies and organizations reach the community with disabilities to market their products and services (Thomas, 2004). Governments are pursuing ways of using the Web to disseminate essential information for citizens to participate in democratic processes through initiatives, such as the NSF Digital Government program (Marchionini, Samet, & Brandt, 2003). Screen reading software makes Web pages accessible to people with visual impairments. Nevertheless, the accessibility of tabular data in Web pages needs to be improved. Tables present significant information, such as lists of products for sale by a company or election results made available by a government. Unfortunately a typical table on a Web page not only lists data values, but also includes unrelated visual formatting. The visual formatting makes it ambiguous for a screen reader to determine how the data values should be presented to the user. Improving the accessibility of tables largely depends on the Web developer who creates the Web pages. It is, however, challenging for the developer because accessibility issues go beyond a Web developer's main focus, the Web page s visual appearance. Two Web pages could appear visually identical but one is accessible and one inaccessible depending on the HTML implementations. To help a Web developer create accessible HTML tables, we developed a table visualization tool. It works with the common screen readers, JAWS (Freedom Scientific, 2004) and Home Page Reader (IBM, 2004), because both have similar keyboard controls for accessing tables. For a Web developer our tool is useful for analyzing layout tables, which are used to visually format a Web page, and data tables, which are traditionally used to present relationships between data. The visualization is

2 particularly useful for working with complex data structures with spanning cells (cells spanning across several columns or rows) and nested tables (tables defined in another table s cell). Our table visualization tool complements two related techniques Web developers use to verify a Web page s accessibility. The first technique is to use automatic accessibility checker tools that verify that a Web page s HTML complies with rules, such as defined by the US Rehabilitation Act, Section 508 (GSA, 2004). A developer can use our table visualization tool to inspect and better understand the errors reported by the checker. In fact, our tool was inspired as an extension to adesigner (Takagi, Asakawa, Fukuda, & Maeda, 2004), an automatic accessibility checker. The second technique is for developers to use a screen reader. A Web developer would verify the accessibility of a Web page by using a screen reader as a blind person would. Our tool visually simulates the interaction of a blind person with a screen reader. Our table visualization contributes to the larger objective of improving Web accessibility for blind computer users. Our user study indicates that our tool is more efficient to use than using Home Page Reader. 1.1 Reading tables with a screen reader Our table visualization tool visually simulates the interaction blind users have with screen readers when accessing HTML tables. To explain our tool it is necessary to briefly describe how screen readers are used to read tables. Two common screen readers are JAWS and Home Page Reader. Both have similar interfaces to access data and layout tables and therefore our visualization applies to both screen readers. There are two modes to read tables. The first mode is the straight through reading mode, where the screen reader reads the entire table without interruption. The table cells are read in the order that they are declared in the HTML, so for a simple table the cells are read from left to right, row by row, and the rows are read from top to bottom. The implication of this reading mode is that it determines the sequential order in which the blind user receives a table s information. Users usually read layout tables in this mode. For example a typical home page with a layout table might have a title in the top row spanning the page and a second row with two table cells for navigation links and the main content. Also this reading mode is used to read data tables to get a first impression of the table s information. To study the table in more depth, the user switches to the second reading mode. The second mode is the interactive reading mode, where a user interactively selects the table cell to read with the screen reader s keyboard commands. The basic navigation is to move between neighboring cells above, left, below, and right of the current cell. The user can also access the current cell s column and row header text necessary for understanding the units or description of the current cell s data. Layout tables are usually not examined in the interactive mode because the cells do not have predictable relationships like in data tables. 2 Our Table Visualization Tool Our tool visualizes the two reading modes to help a Web developer verify the accessibility of a table. An overview of how to use our tool follows. Figure 1 shows a screen shot of our tool in use. Our tool is similar to a Web browser. A user starts by navigating to a Web page containing a table to be investigated. The user clicks the Table Viz button and the application generates a modified version of the original Web page containing data for the table visualization. The new page is displayed in the browser as shown in Figure 1 and the user interacts with it. In the following subsections, we describe the details of the visualized screen reader interaction and how a developer uses the tool to evaluate the accessibility of HTML tables.

3 Figure 1: Screenshot of our table visualization tool showing the interactive mode for cell number 21. Figure 2: Example of a table with 2 nested tables. The cell numbering (numbers with background colors) indicate the order in which cells are read.

4 2.1 Visualized reading modes The two screen reading modes we visualized are the straight through and interactive reading modes. The purpose of the visualization is to simulate the screen reader interaction. Straight through reading mode: We visualize the straight through reading mode by numbering the table cells in the order that the screen reader reads them. As also shown in Figure 1, the numbers have a background color to distinguish them from data in the table. Shown in Figure 2, we also account for the reading order of complicated table structures with nested tables. The numbering in a nested table continues from that table s parent cell. This is how the screen reader reads nested tables without interruption. The background color of the numbers in the nested table is different from the numbers in the parent table so that it is easy for a user to distinguish between tables. Interactive reading mode: For the interactive reading mode we visualize the screen reader keyboard commands. In the application, a user places the mouse over a table cell and the application highlights the table cells corresponding to cells read by the next keyboard command. Figure 1 shows the current cell, numbered 21, and eight selected cells. Cells reached with similar keyboard commands are highlighted with the same color, such as green for the arrow keys, which change the current cell to a corresponding neighbor cell. The keyboard commands are also overlaid on the highlighted cell. In this case, the commands are those of Home Page Reader, but they can be changed to those of JAWS. We hope this helps users learn the commands for when they use a screen reader. The visualization for nested tables also mimics the screen reader behavior. With the screen reader, the interactive keyboard commands access only cells in the current table and not the parent table. Likewise in the visualization, only cells in the current table are highlighted. 2.2 Verifying Accessibility Web developers will use our table visualization tool as part of an iterative process to create an accessible Web page with tables. After creating a page, the developer will visualize it and verify the accessibility of an HTML table. Any accessibility errors will then be fixed. We propose two rules of thumb specific to verifying a table s accessibility. Besides these rules, there are other table accessibility issues we do not elaborate on because they apply more generally to an entire Web page. Rule 1: When considering the straight through reading mode, the order in which the table cells are read should be comprehensible. Related information should be read consecutively and not be interrupted. For example, when reading a row, only the cells in that row should be read and not arbitrary cells from different rows. Rule 2: When considering a data table read in interactive mode, it should be possible for each data table cell to access the correct column and row header. The headers inform the user where the currently selected cell is in the table and how it relates to other data. Rule 1 applies to when a user gets an overview of a Web page with a layout table. The layout table sets the order in which information is presented. If necessary, a developer can use nested tables in the layout table to control the order in which information is read. All the cells in the nested table will be read before the remaining cells in the parent table are read. A developer can easily verify cells are read in an appropriate order with the cell numbering in the table visualization. In an HTML table implementation, there are at least two cases that would violate Rule 2. The first case is using nested tables in a data table, although nested tables are permitted in a layout table. The screen reader only accesses the current table, so if the current table is nested and the current cell s header is in the parent table, it is not accessible. The error might happen because a developer used a

5 nested table in a data table to visually format the data table. In this case the developer should structure the table in a different way that avoids nested tables. The second case is when there is a blank header cell. An example is when one header applies to multiple rows or columns but the header is in only one cell while the other header cells are blank. This creates a visual cue familiar to sighted persons. The screen reader, however, will incorrectly use the blank cell instead of the intended header cell. A solution to make the header accessible and preserve the same visual appearance is to span the header cell across every row or column it applies to. 3 Implementation Our motivation for designing the implementation was to efficiently prototype our visualization tool by utilizing as many existing software components as possible. Our tool uses Internet Explorer to display an HTML file containing scripts to control the visualized reading modes. JavaScript in the HTML file controls the entire visualization. Our tool does not need to render any graphics because the JavaScript is executed by the browser. The component we implemented in Java analyzes the HTML of a Web page and generates the JavaScript and necessary metadata in the resulting HTML file for the table visualization. The Java program parses the original HTML file, stores the DOM structure, and represents each table using a virtual table data structure. The virtual table has the same numbers of rows and columns as the original table, but is a uniform grid. The HTML table is mapped to the virtual table so that a spanning cell in the original table covers corresponding cells in the virtual table. From the virtual table it is straightforward to access a cell s neighboring cells and headers that are otherwise not easily accessible from the HTML table declaration. Accessing neighboring cells and header cells is necessary for the visualization. For users to have a smooth experience with our visualization it is important to have minimal latency for the JavaScript in rendering the interactive visualization. The rendering is a concern because a lot of JavaScript must be executed. Each table cell has metadata for up to eight other cells that are highlighted when the mouse is moved over a cell and activated. In our experience to date, the rendering performance is acceptable. For Websites with complex table structures, such as professional news Websites, the rendering latency is under one second. In an especially bad case with a large data table with 1,500 cells, it takes about 20 seconds to render our interactive visualization. 4 User Study Our study is intended to evaluate the merits of our table visualization tool. The tool is intended for Web developers who would use the tool to create accessible HTML layout and data tables. To make a manageable user study, however, we focused only on evaluating data tables. The main performance measure is the time to evaluate if a data table on a Web page is accessible or not. We compare the performance of evaluating a Web page with our tool to evaluating it using Home Page Reader, one of the current techniques used by Web developers. Our hypothesis is that participants will be faster at evaluating Web pages with our visualization than with Home Page Reader. The improved performance will contribute to the process for a Web developer in creating an accessible table. Six participants, similar to the potential users of our table visualization tool, completed the user study. All are sighted computer science engineers or researchers. They browse the Web daily, occasionally create Web pages, and have little or no accessibility and screen reader experience.

6 4.1 Procedure In an hour-long session each participant uses Home Page Reader and our table visualization tool to evaluate the accessibility of Web pages. Before using the tools we train the participants in how to use the tools. A participant then uses each tool to evaluate a set of five Web pages. The Web pages evaluated with each tool are different but demonstrate similar accessibility issues. Therefore each participant s experiences are similar with each tool. Half of the participants used Home Page Reader followed by our table visualization tool, and the other half used our tool first. The order was switched to determine if the participant s performance was influenced by the order in which the tools were used. Thorough training with the tools is very important to ensure the participants performance is not affected by confusion when using the tools. For each tool the participants read a short tutorial and have time to practice with the tools on a simple data table. The training also includes some tasks to force the participant to use all of the necessary commands or functions to control the tools. Following the training for one accessibility tool, the participant uses the tool to evaluate the accessibility of the five Web pages. While a participant evaluates a Web page, he or she also uses a separate questionnaire program that records the participant s answers to questions, any feedback, and the time to evaluate the Web page. For each Web page, the participant answers three multiple-choice questions. The questions guide the participants in evaluating a table s accessibility. During the study it seemed natural for the participants to interact with the questionnaire program and the accessibility tools. The two programs were on two computers so that a participant was not hindered by the complicated task of switching between applications on one computer. The questionnaire was also used to record the performance metric, which was the time to evaluate the Web page s accessibility. To start evaluating a Web page, the participant clicks a button to advance the questionnaire program to the next page and loads the Web page in our tool. This is the start time of the evaluation. The finishing time is after the participant has answered the last question: Is this page accessible? HTML Tables Used in the Evaluation Participants evaluated a set of five Web pages with each accessibility tool (a total of ten Web pages). The two sets of Web pages are different but represent the same accessibility issues. This way the participants must evaluate each page with the second tool without learning the answers from using the first tool. The data tables in the Web pages are carefully constructed to be consistent in order to make a fair comparison between the accessibility tools. The data tables are based on real Web pages and data found online. All tables are about the same size, with approximately ten rows and five columns, and are entirely visible in the application window. Inaccessible tables are simplified to only illustrate one accessibility issue at a time. Visual cues revealing a table s structure are removed because a participant can use the structure to determine its accessibility without using the accessibility tools. In a set of pages, there were three kinds of tables: two accessible tables, two inaccessible tables, and one special case, as described below. An expert screen reader researcher verified the accessibility status of each table. Accessible tables: A regular grid structure possibly with row spanning cells. All data cells have column and row headers. Table cells do not contain nested tables. Inaccessible tables: There are two kinds. Visually the tables are comprehensible and seem accessible

7 but are not because not all of the necessary information can be accessed with the screen reader. In the first kind some row or column headers are blank so it not possible to get a data cell s units or description. In the second kind, row or column headers are placed in a nested table. When accessing the header from a data cell, the header is not accessible because the screen reader commands only access the current table and not the nested table. A Web developer might create these accessibility errors when concentrating only on the visual appearance of a table. Special case tables: The special case is a table with column spanning cells, so that the table is read along the columns instead of along the rows. In an informal examination of column spanning tables, it seemed to be a common format for Asian radio and TV schedules. Western radio and TV schedules are usually read across the row. In the Asian schedules, each column represents a day of the week and the rows are times of the day. A table cell represents a TV program and its column span is proportional to the length of the program. Technically, this kind of table is accessible but can be confusing to use with current screen readers. In straight through reading mode, the screen reader reads across rows instead of reading down columns, as would be more appropriate. 4.2 Results The quantitative results of our user study compare the time for a participant to evaluate the accessibility of an HTML data table with our table visualization tool and Home Page Reader. For the comparison we include the performance results for the two accessible and two inaccessible tables each participant evaluated with each tool. The special case tables with column spanning tables are considered separately. With six participants we have a total of 48 data points (6 participants, 2 tools, 4 tables). Table 1 shows the aggregate results for all participants. The results are divided into categories. The main categories are accessible and inaccessible pages. These are subcategorized by tool to check accessibility. Accuracy in the table refers to the percentage of tables correctly identified as accessible or inaccessible. The standard deviation is for the average time to complete the evaluation. We statistically compare participants performances using Home Page Reader and using our table visualization with a repeated measures t-test. The overall trend is that participants can evaluate pages faster with our table visualization tool than with Home Page Reader. In the case of accessible and inaccessible pages the speed up is 39 and 37 seconds respectively. The speedup is statistically significant (p<0.05) with p-values of and for accessible and inaccessible pages respectively. This speedup is over 25% of the time it takes to evaluate tables in the user study with Home Page Reader. Table 1: Performance results for participants evaluating accessibility of Web pages with Home Page Reader (HPR) and our table visualization tool (Table Viz). Table type Accessible tables Inaccessible tables Tool HPR Table Viz HPR Table Viz Number of tables Number of evaluations Accuracy 92% 92% 92% 84% Average time to complete (sec) Standard Deviation p-value Speedup with Table Viz (sec) Percentage speedup 30% 26%

8 With either accessibility tool, the participants accuracy in evaluating a table s accessibility is high, as seen in Table 1. In most cases the accuracy is 92%, that is, one out of every twelve tables was incorrectly identified. When evaluating inaccessible tables with our table visualization, the accuracy was 84% (two errors in twelve tables). One of the errors could be attributed to an ambiguity in our tool, which will be clarified in a future version. Overall, the high accuracy suggests that the participants had a clear understanding of the accessibility tools and how to use them. It also indicates that our training sessions for this study were sufficient to prepare the participants. Two factors did not impact the participants performance. First, the order in which the accessibility tools were used did not have a noticeable impact. When the participants used the second tool, experience from the first tool did not consistently improve or worsen a participant s performance. It seems strategies used in one tool were not necessarily an advantage in the other tool. This is probably because the strategies differ between tools. With our table visualization a participant uses visual information and processes it in parallel, but with Home Page Reader the information is auditory and processed sequentially. The second factor is type of table. There is no significant performance difference between evaluating accessible or inaccessible tables. While evaluating inaccessible pages with Home Page Reader, the experimenter repeatedly observed a behavior that one might think slows down the participants performance. When some participants encountered an accessibility problem in a table, they paused briefly with a surprised verbal exclamation or facial expression. It seemed a participant was surprised because Home Page Reader read something he or she did not expect. Next, the participant would try to reconcile the discrepancy by repeating the last keyboard command to see if it was a mistake. Finally they would try to find an alternative solution for accessing the inaccessible information and sometimes ask for a suggestion. Based on these behaviors one might expect the performance would be slowed down, but no significant impact was observed in the results. The performance results for the special case data tables with spanning columns were calculated separately from the accessible and inaccessible tables. Although technically these tables are accessible, most participants hesitated in deciding on the accessibility with either accessibility tool. Compared to the other table types, the special case tables took participants the longest time to evaluate in 83% of the sessions. Participants commented that they were debating if the table was accessible because it was not easy to access the row headers corresponding to the start and end of a column-spanning cell. The difficulty the participants had in deciding suggests that the screen reader interface for these tables could be improved. 5 Discussion Our table visualization tool is beneficial for Web developers creating Web pages with accessible tables. Relative to Home Page Reader, our tool s place in the creation process, as several participants independently concluded, is summarized as: Our table visualization is useful for creating accessible tables more quickly, although it is necessary to use Home Page Reader to understand accessibility issues through experiencing the blind person s perspective. When generating HTML tables, the advantage of our tool over Home Page Reader is that a developer can work faster with it. Our tool will be used iteratively: the developer will edit an HTML file, view the changes with our tool, and make corrections until the table is accessible. Since participants evaluated a table s accessibility faster with our tool, the iterative step will be shorter and therefore a developer will complete more iterations in the same amount of time. In this scenario, we assumed that Web developers are novices at using a screen reader. More experienced screen reader users might

9 evaluate a table s accessibility with a screen reader as quickly and efficiently as the typical developer using our table visualization. Our user study only tested simple data tables. With larger and more complex tables, developers with limited screen reader experience might have an even greater performance increase from our table visualization tool than from Home Page Reader. With our table visualization, the user moves the mouse to the table and cell that are to be inspected. With Home Page Reader, the developer must navigate to a table with keyboard commands. The navigation can be complicated for complex tables, such as switching between tables. Also an inaccessible table requires different navigation techniques, which requires the user to have more extensive screen reader training. We speculate the reason for the faster performance with our table visualization over Home Page Reader is the visual information. A sighted person is more familiar with processing visual information rather than audio information. Therefore it is more natural to work with. Also the visualization displays several pieces of information simultaneously. When the mouse is over a table cell, at most eight other cells reachable with keyboard commands are highlighted, making them visually stand out. A user can quickly scan the highlighted cells to verify that all are accessible as expected. Using Home Page Reader, however, to check the same cells, the user has to issue eight keyboard commands and listen to the cell content. This sequential process takes longer than visually scanning the information. Our table visualization tool does not replace Home Page Reader when teaching sighted persons about a blind person s experience using a screen reader. Using our tool, a user does not experience the sequential information processing that comes from listening to the spoken text. Also, the visualization does not simulate the meta-information a screen reader announces, such as when entering table mode and a screen reader announces the table size and the numbers of rows and columns. Several participants commented that the screen reader s meta-information was useful for understanding the table. In conclusion, Web developers who use our tool should first become familiar with accessibility issues using a screen reader. Our table visualization does have an advantage when training sighted persons to use a screen reader. Half of the participants commented that the visualization showed them the pattern of the keyboard commands. The pattern helps a user predict the behavior of a screen reader. 5.1 Future Work Our future work will cover a wide spectrum. At one end we want to improve a user s performance in evaluating the accessibility of Web pages and we want to enhance the visualization. At the other end we want to use the tool to explore novel Web accessible interfaces. We hypothesize a user s performance evaluating a data table s accessibility should be even faster with our tool compared to Home Page Reader. Demonstrating a better performance would require modifying the user study. Currently the participants have no experience with accessibility and when they evaluate tables it takes time to use the tool and reason about the accessibility. If the user study could measure the time to only use the tool a larger speedup might be recorded. Also the results of the user study might improve if the participants were experienced Web developers with accessibility knowledge. Their time to evaluate the accessibility would mainly be the time to use the tool because their experience reduces the time needed to determine the accessibility. We can also enhance our table visualization to improve an evaluator s performance. Integrating our tool into an automatic accessibility checker, such as A-Designer, will help a Web developer focus his or her attention on accessibility problems. If the checker indicates no table accessibility errors, then the developer does not need to manually evaluate the page. If there is an error, the tool should visualize the error on the table, such as highlighting a cell with a problem. Indicating the errors means

10 that developers can concentrate on the errors rather than the more time-consuming process of exhaustively inspecting the entire table. A further enhancement of our table visualization tool will be to account for HTML table tags specific to accessibility. Some of these tags are for table headers (TH), column groupings (COLGROUP), and categorizing cells (AXIS). With these tags it is possible to present more complex table structures through a screen reader. With increasingly complex table structure it will be important for a Web developer to have our visualization to analyze the complexity. We also plan to use our table visualization as a research tool to explore novel improvements for the screen reader interface to access tables. So far we have identified two possibilities to explore. First, we would investigate a screen reader reading mode for tables with column spanning cells, like the special case tables in the user study. These tables must be read down columns rather than across rows, as is done with the current straight through reading mode. Second, we want to investigate screen reader commands to access a data table with nested tables. Keyboard commands for cells in the nested table should be able to access cells in the parent table. This interaction could lead to supporting more complex table structures. With our tool we could model the suggested behavior and explore the appropriateness of it. We could advocate the designs worth pursuing by integrating them in future HTML standards that improve Web accessibility. 6 Conclusion Our table visualization contributes to the greater objective of improving Web accessibility for blind computer users. It supports Web developers in creating more accessible HTML layout and data tables important components of accessible Web pages. Our user study indicates that our tool is more efficient to use than Home Page Reader. The visual information clearly communicates to the Web developer the details necessary to evaluate the accessibility. 7 References Freedom Scientific, I. (2004). JAWS. GSA. (2004). Section 508 of the Rehabilitation Act. IBM. (2004). Home Page Reader. Marchionini, G., Samet, H., & Brandt, L. (2003). Digital Government. Communications of the ACM, 46(1), Takagi, H., Asakawa, C., Fukuda, K., & Maeda, J. (2004). Accessibility Designer: Visualizing Usability for the Blind. Paper presented at the ACM SIGCAPH Conference on Assistive Technologies (ASSETS), Atlanta, GA. Thomas, D. (2004). Diversity as Strategy. Harvard Business Review, 9(82).