FedStats 508/Accessibility Workshop
Back to: Conference homepage | Agenda
Marianne W. Zawitz
Bureau of Justice Statistics
For statistical agencies, tables of numbers are our product. Tables - R - Us. Of course we also write sentences and prepare public access data files but our primary products are tables. And we produce tables in vast quantities. As Glenn King will tell you later today, the Statistical Abstract of the United States contains 1900 tables and is published annually. That is just one publication.
If we took an inventory, the number of tables we have in some electronic format, it might reach into the millions. Certainly our paper tables exceed that.
We produce all types of tables. The British statistician Ehrenberg defined three types of tables, presentation tables, exploratory tables, and resource or reference tables that vary by purpose;
We have developed presentation methods to facilitate each of these purposes. Our tables are frequently complex, displaying many concepts and measures as well as appropriate metadata. Some of our tables are small but most are big.
Displaying numbers in tables is not new. It�s not even modern. Archeologists have found that tables have been used to display numbers since around 1900 B.C. Even though they are on clay tablets and use characters we don�t understand, they look like the data tables we know and love.
What has changed is the technology we use. First it was the printing press. Until the mid 1990�s, like everyone else, our primary medium for publishing tables was paper. To this day, many tables are formatted under a GPO style that was created in the 1940s to make it easy for typesetters to get numbers properly lined up. With the advent of desktop publishing, some agencies started moving away from that style to one based more on human visual perception. In addition, the development of computational devices, from calculating machines to computers, moved numbers into a different realm. Today, a spreadsheet that maintains the computational properties of numbers is a common publishing format.
When the Internet became a viable means of dissemination, we began moving our tables from paper to electronic formats. But we still had to print the paper. We took our existing production systems and produced electronic output. So it is no surprise that many of our tables still fit on an 8 � X 11 piece of paper. In the paper publishing arena, we had gone through great contortions to get our data and metadata to fit on a printed page and to jam as much as we could into as few pages as possible. The results were large complex data tables which are expected by our customers and often are responsive to legislative requirements. We simply converted what we had in print for distribution on the web - even though this may not be the best way to present data in that medium. In an optimal world, we would convert these tables to formats that fit the medium but because of resources and customer expectations we may not be able to do that.
To avoid proprietary electronic formats used by their publishing systems, many agencies looked for simpler electronic formats to begin publishing tables. Straight text versions of tables were electronically published on websites, the formatting coming from spaces or tabs. This method often leveraged the original computer output that was used as input by publishing systems. These tables were a throw back to the days before desktop publishing but still retained the properties of fitting on a piece of paper.
The first "new" solution in moving to electronic distribution was provided by Adobe with the Portable Document Format. This development allowed agencies to create electronic replicas of their paper documents that could be viewed on most platforms using the free reader. This solution was widely adopted because of its ease of implementation as part of the printing process.
As more agencies became familiar with HTML, data tables coded in HTML began appearing on agency websites. Early ventures frequently required hand coding. Anyone who has hand coded a complex table can tell you that it is not the easiest thing to do. With improved tools to prepare HTML tables, more and more tables were being presented on agency websites. Most are still being created one at a time. However, this is still not the most common format for tables.
The Internet has provided access to our content that was never dreamed of. All of us have seen a major expansion in the audiences we serve. It used to be a relatively limited number of "experts" were our data users. Now every home with a computer and a modem can access this tremendous store of information held by the Federal statistical system. We are moving rapidly from a mediated system of inquiry to a self -serve, customized delivery system.
The statistical agencies moved very rapidly to web dissemination, frequently, without any additional resources. We did pretty well given what we had to work with.
Today we are faced with increasing demands to present more data, faster, and to more people many of whom are not part of our traditional audiences. We are challenged to make all of our presentations more usable to more and more less sophisticated audiences.
Enter Section 508. We now must make certain that our information on the web is also accessible. Two of the 16 standards for web applications concern data tables.
Both the Access Board site and the W3C site provide suggestions on how to properly mark tables to meet these goals. For complex tables, this can mean adding code to every cell in order to properly associate it with the proper header and footer. Given the number of tables we produce every year, this is a daunting task. How are we supposed to do this, especially with no additional resources?
I remember one of my first conversations with Ken Nakata of the civil rights division of the justice department about this issue. I said Ken this is really hard to do. He replied that it really was not�t all that difficult and in fact he had just prepared an html version of the report on how the agencies were doing that had quite a few tables.
That report has 16 tables. None are complex. Ten are 7 rows by 2 columns. There are fewer than 400 cells in all 16. A single table on my site can have almost 2000 cells. So when we started planning this workshop, Ken was one of the first people I called to help out.
One of the first tasks of the planning committee for this workshop was to ask the agencies for samples of their tables. Laurie and I thought that we would be able to prepare a list of links so that vendors and others could see what we were talking about. What we got surprised us. Many agencies were only publishing in text, PDF, or spreadsheet formats. For those that sent us examples in HTML, none of the HTML tables were coded alike.
So we went back to the beginning and reviewed the Access Board and W3C sites. We discovered that the examples given by the W3C and Access Board were not consistent, did not meet the complexity stated by the corresponding guideline (i.e., coding an example that has one level of column heading/row stubs when discussing the markup necessary for complex tables), and were not even in the ballpark of what we are dealing with because they are not the same type of table. They were talking about tables people commonly use like train schedules and expense reports not the complex tables prepared by the statistical community.
So we switched to plan B. Based on the material submitted by the agencies, we prepared a suite of 5 tables in HTML and some additional questions. You should have these in your packets.
We removed all the accessibility tagging from the tables and abridged them. They vary in complexity from a simple one level of column headers and one level of row headers to more than two levels of column headers and two levels of row headers.
We provided these tables to Ken Nakata and Doug Wakefield and to the W3C through Judy Brewer requesting that they provide accessible versions. Our hope was to obtain a set of properly marked, increasingly complex tables that we could all refer to. Until we had this standard, it would be impossible to evaluate automated solutions and move toward batch processing of large numbers of tables.