Welcome to WebmasterWorld Guest from 22.214.171.124
Forum Moderators: ergophobe
With the exception of a few newcomers, we have all heard the sometimes heated debate over "table based vs. tableless layouts." For those of us who are a little bit older (measured in web years, which includes yours truly), we all "grew up" during a time when Cascading Style Sheets (CSS) was unheard of. In fact, even tables were unheard of at the time. The websites of the day looked like a Word document, at best. The flexibility was, well, non-existant. While the purpose of this post is not to rehash the "table based vs. tableless layouts" argument (that is for another forum and another day, despite being discussed to death numerous times already) it is important to understand the background of table usage in order to fully understand tables.
March 1995 marked the first initial draft [w3.org] of what was scheduled to be the World Wide Web Consortium (W3C) HTML 3.0 specification. Part of the work which went into this new specification was the HTML3 Table Model [w3.org]. Tables first became part of the W3C standard as part of HTML 3.2 [w3.org] in 1997 (Jan 14). The HTML 3.2 standard provided a big leap forward in many aspects. CSS support was at this time, well, not quite as bad as the flexibility of old; but pretty close. Despite the quite noble process which went into developing CSS -- a descriptive layout layer which would take the web to a level not even dreamed of -- the browsers of the day did, if we were lucky, support a few color properties here and there. Quite naturally everyone began using tables to control their layout. And understandably so. Tables were the only HTML elements which had any form of structure to them, allowing us to control much of the site layout in what seemed endless possibilities. Templates and design sites began popping up. The web matured, and we started seeing both creativity and individuality in both design and layout.
And so it continued, despite the advent of CSS 1 [w3.org] already in 1996 (Dec 17). I still remember churning out table based layouts, including a stylesheet which controlled but one thing -- anchor tag coloration in its various states. It is difficult to teach an old dog new tricks, so the table based layouts continued -- in fact, flourished -- on the web. And they still live on today in significant numbers, even among brand new and big name websites.
Tables, as an HTML element, were defined to fulfill a specific purpose. They exist, then and now, to arrange data into rows and columns of cells. Tabular data can take many shapes, most of which we see every day around us: spreadsheets, bus and train timetables, sports scores, TV schedules, etc. They all have one thing in common -- data logically organized into rows and columns of cells. Each row and column follow a specific pattern, a pattern which may vary depending on the table in question, but which is consistent throughout the table itself.
Based on the initial draft for the HTML3 Table Model [w3.org], the objective was quite ambitious, but also well thought through. Quite the impressive reading:
This specification extends HTML to support tables. The table model has grown out of early work on HTML+ and the initial draft of HTML3. The earlier model has been been extended in response to requests from information providers for improved control over the presentation of tabular information:
alignment on designated characters such as "." and ":"
e.g. aligning a column of numbers on the decimal point
more flexibility in specifying table frames and rules incremental display for large tables as data is received the ability to support scrollable tables with fixed headers plus
better support for breaking tables across pages for printing
optional column based defaults for alignment properties
Tables start with an optional caption followed by one or more rows. Each row is formed by one or more cells, which are differentiated into header and data cells. Cells can be merged across rows and columns, and include attributes assisting rendering to speech and braille, or for exporting table data into databases. The model provides limited support for control over appearence, for example horizontal and vertical alignment of cell contents, border styles and cell margins. You can further affect this by grouping rows and columns together. Tables can contain a wide range of content, such as headers, lists, paragraphs, forms, figures, preformatted text and even nested tables.
For the visually impaired, HTML offers the hope of setting to rights the damage caused by the adoption of windows based graphical user interfaces. The HTML table model includes attributes for labeling each cell, to support high quality text to speech conversion. The same attributes can also be used to support automated import and export of table data to databases or spreadsheets.
Impressive, right? Especially from a usability perspective! And this is still 1995 and 1996 we are talking; the very beginning of tables as we know them. Over time the HTML Table Model evolved and improved slightly to what we know as tables according to the HTML 4.01 specification [w3.org] in 1999 (Dec 24).
Although tables can be discussed from a number of standpoints, and as basis for several different topics, I will focus specifically on tables as related to usability. We will look at all aspects of tables, including the many supportive subelements which comprise the markup of any given table. I will also discuss the unfortunate lack of browser support for something as fundamental as tables (yes, you read me right -- tables are actually not very well supported; unique to HTML elements in today's browsers). More than anything, I will explain simple basics for making use of the tools and options available to us; especially as it pertains to marking up accessible tables, regardless of complexity. Please note that I will discuss HTML markup only. XHTML and XML differences or elements are a different topic and will not be considered or used for comparison.
Our focus begins with the table structure itself.
As it stands today, the following are the HTML elements and subelements which together form the basis for tables:
The structure above directly indicates the parent/child relationship between the elements. Most of these should be familiar to you. But, regardless of familiarity, we will discuss each in detail.
TABLE There is really not a whole lot to say about the TABLE tag itself. It is simply the container. Everything else goes inside it. :) Author Considerations Use the
Attributes of note: summary, frames, rules
There is really not a whole lot to say about the TABLE tag itself. It is simply the container. Everything else goes inside it. :)
attribute. This attribute provides a summary of the table's purpose and structure, especially for user agents rendering to non-visual media such as speech and Braille. Authors should provide a summary of the table content and structure so that people using non-visual user agents can better understand it.
The table model has been designed to allow for incremental loading, i.e. as rows arrive. In order to achieve this, authors must make use of the COLGROUP and COL elements (more about this below).
Although the frames and rules attributes do not carry significance from a usability perspective, I still wanted to highlight them here, as I am sure many are unaware of their function. (More information [w3.org])
CAPTION The CAPTION element (along with other table headings) does for the sighted user what the TABLE
Attributes of note: align
The CAPTION element (along with other table headings) does for the sighted user what the TABLE
attribute does for non-sighted users. Naturally, the CAPTION serves as the title for your table. If your table contains a train timetable, it would be extremely appropriate for your CAPTION to be "Train Timetable" or similar. I feel like I can impossibly make this any clearer, although the absolute negligence of this perfect element forces me to repeat myself. Use it! Every table (which contains truly tabular data) should have a CAPTION, whether "Sales Report for the Fourth Quarter 2005" or "Cups of Coffee Consumed Daily by Senators."
The CAPTION can be aligned however you want: to the left of the table, to the right, at the top or at the bottom; which is quite neat. This accomplished by use of the
attribute. It accepts four different values: top (default), left, right, and bottom. Yes, I know the
attribute is deprecated; deprecated, not obsolete. It is therefore perfectly fine to use this attribute in an HTML 4.x document even if you are concerned about markup validation (which you should be, as part of being concerned about usability and accessibility). Further, there is really no CSS equivalent which can replace the
The typical (visual) user agent will not style the table CAPTION differently than regular table cells. It is therefore highly recommended to manually style it (which you should do anyway instead of relying on user agent default rendering [which may differ from one agent to the other]).
The CAPTION element is, unfortunately, optional.
Consider using CAPTION. ;)
Browser Compatibility Concerns
Only Firefox properly supports all four values for the
attribute. Internet Explorer and Opera do not support "left" or "right."
THEAD, TFOOT, and TBODY
Here is another thing which shows how well designed tables really are, both from a usability/accessibility perspective and from a design perspective. Table rows may be grouped into a table header, table footer, and one or more table body sections, using the THEAD, TFOOT, and TBODY elements, respectively. This division serves two purposes. It enables visual user agents to support scrolling of table bodies independently of the table head and foot. Further, when long tables are printed, the table header and footer information may be repeated on each page that contains table data. Talk about useful and usable!
Both the THEAD and TFOOT elements (should) contain column specific information (such as column headers) whereas the TBODY element contains rows of data. Although all three elements are optional, if included, the THEAD and TFOOT elements must come before any TBODY elements present. If all three elements are excluded, a TBODY section is quite commonly silently implied (Firefox, Internet Explorer, and Opera all do this). So, do not be surprised if the Document Object Model (DOM) tells you there is a TBODY element, even if your markup does not specifically include one.
Do user agents make use of THEAD/TFOOT/TBODY in ways which significantly affect usability or accessibility? Not really. These elements can probably be seen as most beneficial for the author, due to the grouping capabilities they provide. Although THEAD and TFOOT can improve visual usability depending on how they are styled, this improved usability is not exclusively connected to the use of the elements themselves.
I highly recommend using both THEAD and TBODY (also TFOOT for longer tables) whenever dealing with a linearly structured table (only one header row). If dealing with headers along both the X and Y axis of the table, do not use THEAD as this falls outside its usage scope. Regardless of table type or data contained within, always use TBODY. It is good practice.
Browser Compatibility Concerns
When accessing the
property for the table through the DOM, Firefox returns "undefined" when no THEAD/TFOOT/TBODY elements are used in the markup. However, the
property for any table row returns, as expected, "TBODY".
When printing a table which spans multiple pages, only Firefox properly displays THEAD and TFOOT data at the top and bottom of each page. Internet Explorer struggles with the page transition somewhat, but otherwise prints OK. Opera also strugles with the page transition, but in a slightly worse manner by occasionally causing the TFOOT to overlap table data.
Firefox is also the only browser which remotely supports scrolling of the TBODY section independently of THEAD and TFOOT. But, only sort of. The scrollbar is applied on the inside of the TBODY, but without adjusting the table width accordingly. Awkward. Opera silently ignores any requests resembling scrolling of the TBODY section (probably related to the incompatibility with multipage handling of THEAD and TFOOT). Internet Explorer also ignore any requests resembling TBODY scrolling. Unfortunately, however, Internet Explorer decides to apply the defined TBODY height to each individual table row. Stupid? Hey, it is IE!
Neither browser seems to have a problem with multiple TBODY sections. Rendering is the same as for when only one TBODY section is present.
Please note that both scrollable TBODY sections and multipage handling of THEAD and TFOOT are considered optional behavior for conforming user agents. Lacking support thereof is not to be considered a bug, although perhaps justly questioned.
COL and COLGROUP If THEAD/TFOOT/TBODY serve as the row groups for the table, COL and COLGROUP groups our columns. COL allows attribute sharing among several columns without implying any structural grouping. COLGROUP likewise allows for attribute sharing, but also groups the columns structurally. The TABLE
Attributes of note: align, char, span
If THEAD/TFOOT/TBODY serve as the row groups for the table, COL and COLGROUP groups our columns. COL allows attribute sharing among several columns without implying any structural grouping. COLGROUP likewise allows for attribute sharing, but also groups the columns structurally. The TABLE
attribute is an example of an attribute which behaves differently depending on whether COL or COLGROUP is used.
Although I consider structural/logical column grouping useful on its own, the ability to share attributes across multiple columns (by defining them in a single place) increases their worth considerably. To put everything in its right perspective -- COL and COLGROUP allow you to define styling for the column (or column group, when applied to multiple columns at once) in one place, while applying to all cells which are part of that particular column (or column group)! This means that we can define attributes such as text alignment, font color, etc once -- for the COL or COLGROUP -- and have it automatically apply to all cells of all rows which belong to that column (or column group)! For substantially large tables this becomes very interesting. No need to clutter code (not to mention the increased code size) with class attributes for a given cell on every single row.
attribute defines how many columns are to be included in this particular column group. It accepts any integer value greater than zero. If omitted, the COL/COLGROUP includes a single column. All other attributes (all TD attributes can be used) assigned to the COL/COLGROUP element are meant to affect each cell belonging to any column included in that particular column group. Let us read that again: all other attributes assigned to the COL/COLGROUP element are meant to affect each cell belonging to any column included in that particular column group. This is there the one-stop styling comes into play. For example, defining the
attributes for the COL/COLGROUP is equivalent to applying it to each cell in that column group; except, obviously, much less code! Likewise, a COL/COLGROUP styled using CSS should apply those style definitions to each cell belonging to any column in the group. Handy!
gains another possible value in addition to those we are typically used to: "char." This value, in combination with the
attributes, allow authors to specify character alignment within the cells. Yes, you heard me right! The character by which the cell contents are to be lined up is defined by the
attribute. The implications for tables containing floating point numbers is just, well ... Actually, before we even go there -- I better say it right now -- no browser (visual user agent) has been found to support character alignment within cells. WEAK! (Do I hear chanting? "Way to burst my bubble, fella!") Just another example of how poorly supported tables really are.
Do user agents make use of COL/COLGROUP in ways which significantly affect usability or accessibility? COLGROUP can definitely assist visual usability due to sectioning of one or more columns (provided styled properly, or by proper use of the TABLE
attribute, for example) it is unknown whether non-visual user agents make any use of this grouping information. The COL element should by its definition not affect usability, but can be seen as an author-only benefit.
By now you should not need me to tell you that these elements should be used. Although the browser support for COL and COLGROUP is at times somewhat disappointing, the structural grouping alone makes it worth considering use thereof.
Browser Compatibility Concerns
This time it is Firefox' turn to be the ugly step child. Although all tested browsers generally support COL/COLGROUP very well. Firefox falls short, however, by completely ignoring the
attribute. While the rendering is otherwise generally very similar, I must say that Opera certainly is a cut above the rest. Very easy to read. Very user friendly.
Testing also shows that Internet Explorer is the only browser properly applying CSS properties assigned to the COL/COLGROUP to the cells. However, it also turns out that certain CSS properties are somewhat sketchy (such as
). Please note that the style attribute should be used on the COL/COLGROUP element. Giving it an ID or styling by tag name does not work.
Again, no browser has been found to support character alignment within cells. Weak!
TH vs TD This is where element familiarity picks up again for many of you. Welcome back. In its simplest form, TH is a header cell (hence the "H") and TD is is a data cell (hence the "D"). While proper use of TH and TD implies always using TH for any column/row headings and TD for all other data, there is much more to these elements than that. For those of you who just returned to familiarity, we are off again. Although there are several other attributes which apply to TH and TD, I will naturally only focus on those which pertain to usability and accessibility. The attributes I will discuss in depth are specifically designed to make tables accessible for non-visual user agents. First we will take a look at the
Attributes of note: abbr, headers, scope, axis
This is where element familiarity picks up again for many of you. Welcome back. In its simplest form, TH is a header cell (hence the "H") and TD is is a data cell (hence the "D"). While proper use of TH and TD implies always using TH for any column/row headings and TD for all other data, there is much more to these elements than that. For those of you who just returned to familiarity, we are off again.
Although there are several other attributes which apply to TH and TD, I will naturally only focus on those which pertain to usability and accessibility. The attributes I will discuss in depth are specifically designed to make tables accessible for non-visual user agents.
First we will take a look at the
attribute. As the name indicates,
should be used to provide an abbreviated form of the cell content. User agents may, when appropriate, render the abbreviated content in place of the actual cell content. Keep in mind to keep the abbreviated description short, since user agents may render the information repeatedly. For instance, speech synthesizers may render the abbreviated headers relating to a particular cell before rendering that cell's content.
We continue with the
attribute. This attribute specifies the list of header cells that provide header information for the current data cell. and is therefore typically applied to TD elements (even though it can certainly apply to a TH element as well, especially when the TH in question serves as a sub-heading). The value of this attribute is a space-separated list of cell IDs. Each ID refers to a corresponding TH which serves as a header for the cell in question. This way, even a complex table with headers and sub-headers along both the X and Y axis can be made accessible. Speech synthesizers (or other non-visual user agents) may thus make use of this attribute to provide header information for the cell to the user. Imagine a table with months along the X axis and years along the Y axis. Any given cell can then be referenced by month and year for the user. This improves usability and accessibility in ways ranging from "unusable" in the case of omitted
information, to "easy to use and understand" when the
attribute is used. Use it!
A similar attribute, although on the other side of the spectrum, is
. This attribute should be applied to the header cell itself and specifies the set of data cells for which the current header cell provides header information. You should use either
in your table, but not both. For simple tables,
is preferrable. The
attribute accepts four different values: row, col, rowgroup, or colgroup. I believe these values are fairly self explanatory. It may, nevertheless, be worth mentioning the difference between row/col and rowgroup/colgroup respectively. Use the "group" equivalent scope value whenever the header cell spans multiple rows or columns.
Our last attribute is
. Now we are getting into technical stuff, so bear with me. The
attribute may be used to place a cell into conceptual categories. These categories can be considered forming axes in an n-dimensional space. User agents may give users access to these categories (e.g., the user may query the user agent for all cells that belong to certain categories, the user agent may present a table in the form of a table of contents, etc.). The value of this attribute is simply a comma-separated list of category names. I am not going to go into depth about how exactly this attribute is used. But you should know that it is there. For more information about multidimensional tables, please consult the HTML 4 Tables [w3.org] section directly.
You can impossibly consider yourself an author of accessible table without first and foremost use the TH and TD elements properly. Further, you should also be using either the
attribute according to the details above. I also strongly encourage you to use the
attribute, especially when the cell contains non-textual data, or when the actual data itself is not self-explanatory in its context.
Contents of a TH cell are typically rendered centered and bolded by visual user agents. Although I have yet to encounter a situation where this is not the case, you should still make it a practice to explicitly define the styling yourself.
Browser Compatibility Concerns
Despite the apparent beauty of the
attribute, I do not know of any user agents which truly support it. Support thereof would not only be difficult, but is also extremely vague in the specification itself.
colspan and rowspan
Before I go into the pros and cons about these two attributes, let me mention something I am sure most of you are unaware of. For
, a value of "0" means that the cell will span all columns, beginning with the current column, to the end of the row or colgroup to which it belongs. Similarly, for
, a value of "0" means that the cell will span all rows, beginning with the current row, to the end of the THEAD/TFOOT/TBODY section to which it belongs. Awesome! No need to dynamically figure out the number of rows or columns. A fluid span identifier.
Now, I would like to discuss these two attributes as they relate to usability and accessibility. First of all, you should keep the use of spanning cells to an absolute minimum, especially for TD elements. In fact, I would go as far as to say that there is truly no valid reason to apply
to a TD element if the table is designed properly. As I see it, the only time when such cell spanning is called for is when one TH element serves as a parent header to two or more other TH elements. Certainly, sibling cells should also be spanned (the opposite direction) to create a uniform header section. The reason why I otherwise discourage use of these two attributes is because they are generally counteracting usability and accessibility. A lot of spanning cells are confusing for the user. A spanning data cell is, by definition, borderline inaccessible and unusable. Imagine a large table where data cells span here and there. Confusing. The TD
attribute does somewhat counter the effects of cell spanning, but I still discourage their use except as noted above.
Browser Compatibility Concerns
No browser has been found to support "0" for neither
. Disappointing. This is to be considered a bug, as the W3C specification does not indicate this to be optional behavior.
The inherent inaccessibility
Despite their usefulness and well deserved place in HTML, tables are not very easy to understand, especially when accessed through a non-visual user agent. The larger the table, the greater is the risk for resulting in a table which cannot easily be understood or made use of. The biggest reason for table inaccessibility results from its design, where related information resides in separate cells, sometimes many spaces away. Tables are also, from an authoring perspective, sometimes difficult to grasp. There are usually more than one way to present the information, and this in ways which affect the accessibility and usability. This altered behavior may be difficult to realize or identify. More often than not, the ability to successfully use information presented in a table format depends heavily on the user's previous experience with tabular data.
I would be as bold as to say that tables are generally not accessible unless we specifically design them to be. Luckily, as my overview has shown, the tools have been given us. We just need to make use of them.
How to make your tables accessible
One often overlooked aspect is how the table itself is used. As an author, you should consider whether the table is best suited as the main source of information, or whether it is better suited as a supplementary (and perhaps, optional) information source for the data you are trying to present. You should always consider using a textual representation which presents key facets of the tabular data in a paragraph form. Do not assume that your visitors will be able to decipher the table the way you consider given. Sometimes it may be advisable to highlight specific key points from the table, perhaps even providing ways for the user to navigate to those sections of the table. This is especially true when dealing with reports which display anomalies. These anomalies may otherwise be difficult to find and identify without prior familiarity with the data itself.
Take some time to learn how to use all the table elements and their respective attributes properly. Become familiar with how different user agents treat these elements and attributes. Test on platforms and using user agents your audience are likely to use. While this may seem like a daunting task, do not forget to rely on third part sources. Many different organizations and associations for people with various impairments are usually open to assisting you in making Internet more accessible for their particular needs. A single session with a blind or physically impaired person will forever change the way you view accessibility and usability. For large and public sites, such knowledge and testing by the audience most affected by malformed design is priceless.
More than anything, follow the suggestions set forth in the Web Content Accessibility Guidelines (WCAG) [w3.org] for tables. Lacking user agent support is no excuse for insufficient coding of your tables. Hopefully browser support will continue to improve, and certain attributes and elements which may now have dismal support will begin to find its way into more and more user agents. If an element or attribute by definition will make your tables more usable and accessible -- implement it. Implement as much as you can, while still avoiding breakage in non-conforming agents.
For now, I thank you for your time and attention. It has been a pleasure to discover accessible tables with you.
I would not want you to leave empty-handed. I have therefore prepared a couple different examples of accessible tables which demonstrate the simplicity of rudimentary accessibility and usability, as applied to tables. You may modify these examples as you wish, and apply each scenario on a personal level as related to your own needs and uses.
The first scenario we will look at provides two different ways of authoring the same table. This particular table presents average daily temperatures in Fakeland throughout the year. Multiple years are provided for comparison over time.
<table rules="all" frame="box" border="1" cellspacing="0">
<caption>Average Daily Temperature (°C) in Fakeland</caption>
<col span="12" width="30"></col>
<th colspan="2" rowspan="2"></th>
<th colspan="12" id="m">Month</th>
<th id="m1" headers="m">Jan</th>
<th id="m2" headers="m">Feb</th>
<th id="m3" headers="m">Mar</th>
<th id="m4" headers="m">Apr</th>
<th id="m5" headers="m">May</th>
<th id="m6" headers="m">Jun</th>
<th id="m7" headers="m">Jul</th>
<th id="m8" headers="m">Aug</th>
<th id="m9" headers="m">Sep</th>
<th id="m10" headers="m">Oct</th>
<th id="m11" headers="m">Nov</th>
<th id="m12" headers="m">Dec</th>
<th rowspan="3" id="y">Year</th>
<th id="y1" headers="y">2003</th>
<td headers="m1 y1">-5</td>
<td headers="m2 y1">-2</td>
<td headers="m3 y1">4</td>
<td headers="m4 y1">8</td>
<td headers="m5 y1">12</td>
<td headers="m6 y1">16</td>
<td headers="m7 y1">19</td>
<td headers="m8 y1">21</td>
<td headers="m9 y1">16</td>
<td headers="m10 y1">10</td>
<td headers="m11 y1">3</td>
<td headers="m12 y1">0</td>
<th id="y2" headers="y">2004</th>
<td headers="m1 y2">-4</td>
<td headers="m2 y2">-3</td>
<td headers="m3 y2">2</td>
<td headers="m4 y2">6</td>
<td headers="m5 y2">11</td>
<td headers="m6 y2">17</td>
<td headers="m7 y2">18</td>
<td headers="m8 y2">20</td>
<td headers="m9 y2">15</td>
<td headers="m10 y2">6</td>
<td headers="m11 y2">1</td>
<td headers="m12 y2">-3</td>
<th id="y3" headers="y">2005</th>
<td headers="m1 y3">-10</td>
<td headers="m2 y3">-8</td>
<td headers="m3 y3">0</td>
<td headers="m4 y3">6</td>
<td headers="m5 y3">10</td>
<td headers="m6 y3">13</td>
<td headers="m7 y3">18</td>
<td headers="m8 y3">22</td>
<td headers="m9 y3">18</td>
<td headers="m10 y3">8</td>
<td headers="m11 y3">5</td>
<td headers="m12 y3">1</td>
<table rules="all" frame="box" border="1" cellspacing="0">
<caption>Average Daily Temperature (°C) in Fakeland</caption>
<col span="12" width="30"></col>
<th colspan="2" rowspan="2"></th>
<th colspan="12" scope="colgroup">Month</th>
<th rowspan="3" scope="rowgroup">Year</th>
Although the former example is more explicit due to referencing header data for each cell individually, both examples technically produce the same output. The former uses
to convey this information, whereas the latter uses the
attribute. As you can see, the second example appears leaner and would definitely be preferrable for a dynamically generated table. The first example is, however, recommended due to its explicit nature.
Next I would like to give you an example of how to utilize THEAD/TFOOT/TBODY sections in your table.
<table rules="groups" frame="hsides" border="1" cellpadding="10" cellspacing="0">
<caption>Weekend Shift Managers, August 2005</caption>
<colgroup align="center" span="3"></colgroup>
There are many more examples which can be given. Both the HTML 4.01 Table Model [w3.org] section and the WCAG [w3.org] contain further information about the various table elements and their attributes. Further examples are also given on those pages.
If one use tables at least use them accordingly to the correct model, as you mentioned deprecated does not mean outlawed.
Tables are really useful with server side DB generated content
I recently did a new site MySQL PHP oriented that is CSS 100% template based
Certainly not my most pleasant experience!
Tables are great to be used as a structure/frame and let the whole content being CSS driven.
WHY only 8 distinct members did read that great thread?
it should be forced fed
This tutorial really helped me understand the finer points which allowed me to more easily make all of my tables more accessible and my site has lots of different (but legitimate) data tables.
Once I finish looking for and updating any overlooked tables I'll be ready to have a blind user take my site for a spin so that I can find where I have any issues. Now if I just knew someone who was blind to do this for me. I doubt any increased ad revenues from making my site more accessible (it was pretty good to begin with) will justify the time commitment, but it will be nice knowing that as many people as possible will be able to access and benefit from my site. It would be nice to know that my site was in the top 99.99 percentile for accessibility.