Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Web Design & Development > Usability

Web Design Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

Designing Data Tables

Last updated Oct 17, 2003.

If you’re looking for more up-to-date information on this topic, please visit our Web Design article, podcast, and store pages.

By Sarah Horton, author of Access by Design: A Guide to Universal Usability for Web Designers

Table design is a gentle art. It's not about wowing viewers with spiffy effects and snazzy colors. The goal of table design is to present information clearly so viewers can arrive at insights, draw conclusions, and make decisions. While tables aren’t likely to inspire oohs and ahhs, or win design awards, a well-designed data table can give rise to something more profound: knowledge and understanding.

On the web, the impact of tables is hampered by limited screen resolution. Tables normally share the screen with other elements, and there is only so much page that can be visible at one time. When users scroll to see the full extent of the table, the context provided through column and row headers disappears off screen, and trying to make sense of data without headers is like trying to understand a sonnet by reading a single word. Like words, individual table elements have limited meaning; taken as a whole, they speak volumes. As table designers, our task is to make sure the limitations of the medium do not stifle the information narrative.

In this article, I take a fresh look at table design, covering both the challenges of working within the constraints of the screen and the markup that can be used to help provide table structure.

How Tables Work

What is it that makes a table sing? Edward Tufte would say, "differences that make a difference." In his book, Envisioning Information, Tufte refers to tables as a form of "small multiples," in which the same design structure is applied across a set of information. This approach provides an "economy of perception" by housing a body of information within a single structure, allowing users to quickly learn the structure and focus on the details. And rather than describe each detail, the design enforces a single context, creating also an economy of space. In addition, a consistent design structure allows for comparisons by highlighting the differences in the information. And it's these comparisons—these differences that make a difference—that tell the story of a table: for example, how the population of Arizona increased 40% between 1990 and 2000, whereas the population of North Dakota increased only a half a percent (see Figure 1). Comparisons lead inevitably to conclusions, like maybe people like warm, dry weather year-round better than six months of winter.

On the subject of comparisons, Tufte says they "must be enforced within the scope of the eyespan"—that "if the visual task is contrast, comparison, and choice, ...then the more relevant information within eyespan, the better." And aye, there's the rub. Because of space constraints, any large data set challenges the designer's ability to provide sufficient context, and the web is even more constrained then the printed page. Also, most web pages serve multiple masters: content, navigation, branding, and advertising. The chance of designing a multi-column, multi-row table that displays within the scope of one screen is about as likely as designing a one-page phone book—even in North Dakota!

When context is not readily available, users must rely on memory (I think the population numbers from 2000 were in the first column—or was it the second?), deduction (Well, the second column numbers are smaller than the first, so they must be the 1990 numbers), or by scrolling up and down, up and down, to reorient themselves within the structure (What was it again? Right—2000 first, 1990 second. ...Er, what was it again?). None of these approaches to reading a table is particularly effective or enjoyable, but the solution isn't for users to get bigger monitors, much less better memories. Nope—it's up to us designers to construct tables that accommodate the limitations of the screen.

Design Considerations

In this section, we turn to the practicalities of designing tables to be viewed onscreen. Because of space limitations and the disruptive quality of scrolling, our fundamental design goal must be to help users establish and retain a mental model of the data context. In this, we move away from Tufte's ideas about information complexity ("less is a bore"). When designing tables for on-screen display, our goal must be to achieve the greatest degree of simplicity afforded by the content.

The first step in simplifying data is identifying the purpose of the information. Are we trying to give an overview—what are the different methods people use to get to work? Or show changes over time—are people making more use of public transportation, or less? Or to provide answers to specific questions—what percentage of people walk to work? Once the purpose is clear, the next step is to determine which information is required to provide the answers. While it's tempting to provide all the information on hand, just in case it's of interest, in table design, "just right" is more. Include just the right amount of information to produce answers and get the message across (Figure 2).

Another way to provide context is to present information that is self-explanatory. The Netflix queue table has eight columns and the potential for hundreds upon hundreds of rows, depending on your enthusiasm for movies (Figure 3). The information in each row is mostly self-explanatory: movie title, star rating, MPAA rating, genre, and availability. With simple deduction, users can decode the information without needing to scroll back to the top to determine, for example, whether "Drama" is the movie genre or its availability. On the other hand, the Priority and Remove widgets sure could use clarification, particularly since the wrong choice might yield unhappy results (Do I click the checkbox to move Shaggy Dog to the top of the queue? Let's try... Hey, what happened to Shaggy Dog?).

We often get too ambitious with table design. In an attempt to save space and avoid repetition, and provide access to the full breadth of information, we collapse a complex body of information into a single table. To accommodate a diversity of data, we are forced to design a complex, multi-dimensional table structure: for example, population change over time by country, region, race, age, and gender. Such data displays can be difficult to decipher under the best circumstances, never mind on a web page (Figure 4).

How about we take a stab at redesigning this table for better onscreen access? Let's start by looking for opportunities to simplify the data. Since we're not the U.S. Census Bureau, we probably can get away with not showing margin of error, so let's remove those columns. Is anything accomplished by listing all subcategories in one table, besides the space economy of only one set of column headers? For onscreen viewing, frequent headers provide better context because the data and headers are more likely to appear onscreen at the same time. Let's move away from a single table approach and create tables for each population group. Also, since the purpose of the table is to show disability percentages—totals and by gender—let's remove the total population figures since they are not part of the narrative. This brings a uniformity to the data set that improves readability and facilitates comparisons (Example 1).

Bear in mind that accommodating the limitations of screen display does not mean cutting the heart out of your message. Remember: the goal in table design is "just right," and if your information narrative requires complexity, the solution is not to dumb it down so it fits on a single screen. Assume users will print the table and design accordingly: create a print view that is free of unnecessary clutter, and use the markup below to make sure contextual elements, such as headers, print on every page.

Table Markup

HTML gives us several tools to add meaning to tables. Currently, this markup is useful primarily to non-visual users. Screen readers and voicing browsers use markup to provide context, for example, by identifying the row and column headers associated with a table cell. Most visual browsers do nothing more with row and column headers than format them visually (centered and bold—unfortunately). However, browsers could easily make use of this markup to overcome the constraints discussed above. One possible approach is shown in Figure 5, with the table caption and column and row headers displayed in a pop up when the cursor hovers over a data cell.

Figure 5

Figure 5: Use of tool-tip-style pop-ups provide contextual information

The following is a review of useful table markup, described and illustrated using world population figures from the U.S. Census Bureau International DataBase.


The summary tag is used to provide an overview of the design structure—what the table is for and how it's organized. Summary is non-displaying, so any description you provide will be accessible only to nonvisual users.

<table summary="Yearly world population totals grouped by age, 1996 through 2006">


The caption tag is used to provide a descriptive title for a table. The caption displays on the page, and its display can be controlled using CSS.

<caption>Table 1: World Population</caption>


The <th> tag is used to mark up column and row headers, so that row and column headers are associated with the information they describe. This is particularly useful to nonvisual users because software can read the contents of a cell along with its descriptive headers. This binding of detail and context can be made more explicit by adding the scope attribute to the <th> tag. The scope attribute tells software that each cell of data in the row or column immediately following the header is described by the header.

<tr><th scope="col">Year</th><th scope="col">Ages 0-14</th><th scope="col">Ages 15-64</th><th scope="col">Ages 65+</th></tr>

<tr><th scope="row">1996</th><td>1,795,062,533</td><td>3,580,833,944</td><td>380,058,581</td></tr>


Finally, there is a set of tags that is used to describe overall table layout: <thead>, <tfoot>, and <tbody>. These tags are not widely utilized by current browsers, but let's be optimistic and include them anyway, just in case browsers catch on and start making better use of table markup. Currently, <thead> is used by some browsers to print column headers on all pages of a multi-page table.

Listing 1 shows the complete table markup, and Example 2 shows the markup in action, prettied up with some basic CSS.

Listing 1

<table summary="Yearly world population totals grouped by age, 1996 through 2006">
<caption>Table 1: World Population</caption>
    <tr><th scope="col">Year</th><th scope="col">Ages 0-14</th><th scope="col">Ages 15-64</th><th scope="col">Ages 65+</th></tr>

    <tr><td colspan="4">Source: <a href="">U.S. Census Bureau International Database</a></td></tr>

    <tr><th scope="row">1996</th><td>1,795,062,533</td><td>3,580,833,944</td><td>380,058,581</td></tr>    
    <tr><th scope="row">1997</th><td>1,799,970,690</td><td>3,648,232,424</td><td>389,406,129</td></tr>    
    <tr><th scope="row">1998</th><td>1,805,871,535</td><td>3,710,785,903</td><td>399,141,476</td></tr>    
    <tr><th scope="row">1999</th><td>1,810,810,284</td><td>3,773,501,394</td><td>408,505,028</td></tr>    
    <tr><th scope="row">2000</th><td>1,815,884,654</td><td>3,838,781,592</td><td>418,563,298</td></tr>    
    <tr><th scope="row">2001</th><td>1,816,807,897</td><td>3,903,367,470</td><td>428,890,589</td></tr>    
    <tr><th scope="row">2002</th><td>1,812,736,459</td><td>3,971,838,060</td><td>439,575,593</td></tr>    
    <tr><th scope="row">2003</th><td>1,810,047,253</td><td>4,038,479,845</td><td>450,701,157</td></tr>    
    <tr><th scope="row">2004</th><td>1,807,550,356</td><td>4,105,885,326</td><td>461,533,642</td></tr>    
    <tr><th scope="row">2005</th><td>1,804,617,392</td><td>4,174,048,905</td><td>472,726,158</td></tr>    
    <tr><th scope="row">2006</th><td>1,806,820,520</td><td>4,237,177,475</td><td>484,053,828</td></tr>



There's more to designing tables than meets the eye, and this article only scratches the surface. For more on the art of table design, and for access to a wide array of information narratives, check out the following resources:

  • Edward Tufte is the expert on information design. Read his book, Envisioning Information, for more on small multiples and table design.
  • Several online resources address the specific design requirements for universal access to tables. Try Accessible Data Tables, Bring On the Tables, and Creating Accessible Tables. Techniques for Accessible HTML Tables is an in-depth article on designing tables that are Section 508 compliant.
  • Like the CSS Zen Garden, the CSS Table Gallery is a showcase for CSS techniques for table design.
  • The U.S. government has a wealth of online data—from aviation safety to energy consumption to tobacco use. Check out the Fedstats gateway for access to data from over 100 federal agencies.