This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
|Cell 1 1||Cell 1 2|
|Cell 2 1||Cell 2 2|
|This is a title cell|
| Navigation link 1 |
Navigation link 2
Navigation link 3
Navigation link 4
|Banner ad|| Right Navigation 1 |
Right Navigation 2
Right Navigation 3
|Main content area with lots of text and|
content filling the center part of the
element in order to create indenting. As tables are currently used for site layout, you should avoid using the
element to have text centered and bold. If you do, then the assistive technology will think the table is a data table, and try to deal with it accordingly. The WCAG also has a further Priority 3 checkpoint related to our discussion of the way screen readers speak text on the web page: 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. [Priority 3] User agents, including assistive technologies, do in fact render side-by-side text correctly, so in my opinion, this checkpoint is moot. Neither the Section 508 Rules on Web accessibility nor the IBM Web Accessibility Guidelines include provisions that specifically address layout tables because, apparently, these issues are interpreted as less pressing. It is next to impossible to look at the source of a large commercial web page and determine what it will look like when it is linearized. The linearization algorithm that we have described, involving recursion as it does, is somewhat hard to apply even when you know the structure of your page. Fortunately there are readily available tools that let developers look at their linearized page. Often the tabular structure for layout is part of the basic template used for development of the site. When this is the case, you can understand how your pages linearize just by looking at one of the pages. Lynx (http://lynx.browser.org/) is a text-only browser that is popular in the Unix world and is available for Windows, OS/2, and VMS. It is shareware so you can download Lynx and try it yourself. Short of that, however, Delorie Software provides the Lynx Viewer (http://www.delorie.com/web/lynxview.html). Just browse to that site and submit the URL of a page you want to test. I ran the sample table at the beginning of this section through this Lynx Viewer and here is a screenshot of the result:
file:///I|/1/8212final/LiB0026.html (4 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
This text view of our table as seen by the Lynx Viewer is show overleaf. It is essentially identical to the HPR view that we saw previously. IBM Home Page Reader provides a text view, which by definition linearizes all tables. There is a free trial of HPR available at http://www.ibm.com/able/hpr.html. When you use HPR to observe the linearized text view, you don’t have to listen to the whole page; instead, bring up the web page and place the focus on the text view, either by clicking on that view or using F6 to cycle to the text view. When in the text view, use CTRL+A to mark (highlight) the text view. HPR will analyze the complete page and get all the text and mark it. Then use CTRL+C to copy the text view to the clipboard. You can then paste the view into your favorite text editor, for example Notepad, and analyze it there, or print it. Another way to check out the linear version of your site is to use the Tablin tool (http://www.w3.org/WAI/Resources/ Tablin/) from the Web Accessibility Initiative’s Education and Outreach working group. Tablin is available in several formats including an online service and downloadable Java source.
Data Tables Data tables are a different story. Data tables don’t have to be made up of numeric data. They are made up of any kind of data that depends on the rows and columns to convey information. The accessibility issue is that information is lost when a data table is linearized. Consider this table of TV listings (http://tvguide.com/listings):
file:///I|/1/8212final/LiB0026.html (5 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
By listening to the linearized version of this table you may, with difficulty, be able to tell what is playing on KVUE. You can listen to this page to hear the shows that follow KVUE and come before KXAN. Those are the ones playing on KVUE. But because of spanning cells, it is impossible to tell what time Monday Night Football is starting. Information is lost when the table is linearized. Notice that if there were no column spans then technically you might be able to figure out the times of each show. In the example the third show heard after the station name would be the one that is showing at 8:00PM. But that is only technically true, as this is not a reasonable solution to the problem. Imagine searching for “Angel” with your screen reader and finding it. There you would be in the middle of the table. What time does it start? On which channel will it be aired? This is the central issue with the accessibility of data tables. The advice for marking up tables in a way that will allow assistive technology to help the user decipher the information is divided into two parts: simple data tables and complex data tables. The example above is a complex table, and we will be returning to it later, but first let us look at the guidelines for simple data tables. Simple Data Tables in the Guidelines A data table is simple if it satisfies two conditions: ●
The column headers for any given data cell is in the same column as the cell.
The row headers for any given data cell is in the same row as the cell.
The Section 508 provisions require that row and column headers be identified with markup: §1194.22(g) Row and column headers shall be identified for data tables. This provision is essentially the same as Checkpoint 5.1 from the Web Content Accessibility Guidelines: 5.1 For data tables, identify row and column headers. The IBM Web Accessibility Guidelines follow suit but specify how to identify headers and how to deal with complex tables. We will discuss the complex tables shortly. 10. Table Headers. Use the TH element to mark up table heading cells. Use the headers attribute on file:///I|/1/8212final/LiB0026.html (6 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
cells of complex data tables. These guidelines are all designed so that the assistive technology can provide information about tabular structure to people who use screen readers or talking browsers. When you are listening to a page, the content is linearized and when tables are linearized, information is lost unless steps are taken to recover it. The intent of the guidelines is to allow a screen reader to recover the lost information and present it to the user. In particular the screen reader or talking browser needs to know which cells contain header or title information for any given data cell. Table Reading with Assistive Technologies In order to fully understand this “table problem”, it is very helpful to listen to tables with a screen reader or talking browser. To test the recovery of the tabular information that is lost when the table is linearized, you have to listen to the cells of a table a cell-at-a-time, rather than just listening to a whole page. Unfortunately, listening to tables is not the easiest task with these technologies. First you may have to make sure that the settings are correct, and then you have to read the table cells one at a time. It would be a case of information overload to always read out table headings when reading tables, since almost all tables are layout tables. Header information is not interesting or relevant for layout tables. Here are the techniques needed to set up and use our three assistive technologies for reading table cells. ●
Window-Eyes: Use CTRL+SHIFT+H to cycle through table heading speaking choices. Choose “Column or Row” to hear the row heading when the row changes and the column heading when the column changes. CTRL+ALT+TAB moves to the next table; CTRL+ALT+SHIFT+TAB moves to the previous table. Turn on table mode with CTRL+PLUS. Turn table mode off with CTRL+MINUS. When in table mode use INS+ARROW to move from cell to cell in the table.
HPR: You must turn on reading of table headers in the programs settings. Go to menu items, then Settings, then Miscellaneous, and then check the two checkboxes, Read Column Headers and Read Row Headers. These are not checked by default. Switch to Table Jump Mode with ALT+J and then use the left and right arrow keys to jump from table to table. When you are ready to read a table, go into Table Reading Mode and then use all the arrow keys to move from cell to cell.
JFW: You don’t change modes to work with tables. Use ALT+CTRL+ARROWS to move around table cells.
Let’s begin by seeing how these technologies read the cells of a simple data table, one with no specific markup indicating which cells are header cells. Here’s a table which is apparently a performance chart for some mutual fund: 1998
Here is the HTML for this table. There is no specific code indicating headers beyond the fact that the headers are all in the first row and in the first column.
All three assistive technologies treat this table in exactly the same way. When reading cells which are outside of the header rows and columns, that is, not in the first row or the first column, each technology speaks the heading information in the first row when the column changes and speaks the heading information in first column when the row changes. The following table shows how all three assistive technologies read cells in the table. It is not enough to just indicate how a given cell is announced because the announcement depends on whether you arrive at the cell from the side or from above or below. To row 1 column 3
file:///I|/1/8212final/LiB0026.html (7 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
1998 1999 2000 09–01 Fund 17.7 52.9 6.9 −9.6 +/− Cat 13.0 21.2 6.8 6.3 +/− Index −10.9 31.9 16.0 10.8
To row 2 column 2
Move from row 1 column 2
+/− Cat 13.0
Move from row 2 column 3
As soon as the headings are moved out of the first row or the first column this accessible rendering is lost to users of assistive technology. For a simple example of how the accessibility gets broken, let’s look at what happens when a caption is added as a cell in the table. (We will discuss a better way to introduce captions, or headings, in a later section.) Here is the code added at the top of the table. This so-called caption is centered and in bold style, but it is not designated as a heading
file:///I|/1/8212final/LiB0026.html (8 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
The resulting table is shown below: Performance 1998
Window-Eyes and IBM Home Page Reader both think “Performance” is the information to be used as column headings including the cells containing the dates. Here is how they speak with this new table: To row 3 column 3
To row 4 column 2
Move from row 3 column 2
+/− Cat 13.0
Move from row 4 column 3
JFW, on the other hand, uses a heuristic whereby a row with spanned cells is assumed not to be heading information. This screen reader ignores the first row in this example and correctly uses the dates as headings. Using the
Element and Scope Attribute is used to enclose data in a table that is intended to be a heading. The default implementation in a visual browser of the element is to center the text and make it bold. It is both easy (and advisable) to use Cascading Style Sheets (CSS) to modify the presentation of the element if this default is not what is desired. In the figure below, the element is used for all the cells of the first row and for the first column— all the headings, in other words. Performance 1998
Here is the new HTML, which you may wish to compare with what we used earlier:
The behavior of Home Page Reader is now exactly as it was before we added the performance cell to our table because the
<STRONG>Performance 1998 1999 2000 09–01 file:///I|/1/8212final/LiB0026.html (9 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
Fund 17.7… elements help to identify the cells containing the headers. The two screen readers, however, ignore and scope elements. The fact that JFW reads the table correctly is a matter of luck or good judgment on the part of its makers, as we noted earlier. The scope attribute offers an alternative to the element for specifying header information in an HTML Table. It has the advantage that the heading cells would not be formatted differently than the other data cells (not centered or bold). It is worth bearing in mind, however, that it is a more recent element that is only supported by the 4+ visual browsers, so employ it with caution if you are using this formatting data for reasons other than accessibility. Here is our sample table marked up with scope instead of : <STRONG>Performance 1998 1999 2000 09–01 Fund 17.7 52.9 6.9… Again, HPR uses this information to correctly identify the headers in this table, but the two screen readers ignore it. Once more, JAWS gets it right, but only because it ignores the spanned cell. Here is a summary of the effects of and scope markup on speaking simple data tables with assistive technologies. HPR: ●
If there is no scope or
markup, HPR will read headings from the first row and first column.
If any table cell is designated as a heading with scope or
, then only the heading information specified by the scope or will be announced. It is announced in rows to the right of or below the heading cells.
Window-Eyes always speaks heading information from row one and column one independent of the scope attribute and
JFW: file:///I|/1/8212final/LiB0026.html (10 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
JAWS for Windows speaks heading information from the first row and column independent of the scope and
Sometimes JFW will choose an alternative adjacent row or column for headings if the first has spanned cells.
So, of these three assistive technologies, only HPR supports the simple table heading markup,
and scope. There is a simple reason for this: it takes development time for the screen readers to implement support for these constructs and the assistive technology companies have to ask how that effort will benefit their customers. Since there are almost no data tables out there on the Web that use these markup techniques, it follows there is no direct value in supporting these markup techniques to the screen reader customers. However there is an indirect benefit that probably forms the basis for IBM’s decision to support and scope. As it comes into greater use, the needs of assistive technologies will raise in developer’s minds the importance of using and/or scope markup, so that assistive technologies can stop having to guess where the headings are, and can instead use the ones that the author has designated. When HPR finds or scope markup, it assumes that the author knew what they were doing and uses the headings specified in the markup. Going back to our TV listings page, an ironic postscript to this issue of support for headers markup is that the cell containing the advertisement is marked as . As a consequence HPR doesn’t read the TV stations in column 1. It is clear that with today’s technology, it is best to identify table headers by placing them in the first row and first column, but to use and/or scope, where appropriate, in the hope that future technologies will implement them. Recommendation: For simple data tables, identify row and column headers by placing them in column one and row one. In all cases use or scope to identify which cells are row and/or column headers. Let’s now take a look at how assistive technologies cope with complex tables.
Complex Data Tables There are lots of access problems with the table of TV listings at the beginning of this section. The problem relevant to this discussion is the fact that the advertisement for fantasysports.com at the top of the table is an image in a cell in the first row of the table, a cell that spans the entire table. The alt text for the image is, disappointingly, “click here”. Window-Eyes and Home Page Reader think “click here” is the column heading for all the columns and so announce “click here” when changing columns just as they announced “Performance” in the earlier example. Here are the guidelines for tables that are complex, that is those which have “two or more logical levels of row or column headers” (the source of this wording is the WAI Web Content Accessibility Guidelines): 5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1] The Access Board again uses essentially the same language: §1194.22(g) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
file:///I|/1/8212final/LiB0026.html (11 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
We already saw the way the IBM Guideline 10 refers to complex tables: 10. Table Headers. Use the TH element to mark up table heading cells. Use the headers attribute on cells of complex data tables. I have looked high and low for a definition of “two or more logical levels” and the closest thing I have found is an example from the Web Accessibility Initiative techniques document for the Web Content Accessibility Guidelines, http:// www.w3.org/TR/WCAG10-HTML-TECHS/#identifying-table-rows-columns. Meals
San Jose 25-Aug-97 26-Aug-97 subtotals Seattle
I believe the idea behind this frequently used example is that there are “two logical levels of row headers”. The heading “subtotals” is only useful if you also know whether the trip destination is San Jose or Seattle. The first logical level of row headers consists of “San Jose, Seattle, and Totals”. The second level consist of the dates and subtotals under each city. The crucial point in this kind of complex table is that heading information for the highlighted cell at row 5, column 2, with the value 65.02 cannot be determined from heading information in its row and column. That information, meals, subtotals, is relevant, for sure, but you need to know the city as well. HTML 4.0 includes markup specifically designed to address this situation. It is robust in that, as required by both the 508 provision and the WCAG checkpoint, it associates heading information with the data cell. Each cell can have specific heading information associated with it. The way it works is that each heading cell is assigned an ID, using the id attribute. Then the headers attribute is added to each data cell, and the value of the attribute is a space-delimited list of ID’s of heading information. The highlighted cell has headers="C5 R2 C2" which would read "subtotals Meals San Jose". Here is the markup for half of the table above:
Window-Eyes does not support the headers attribute while both IBM Home Page Reader and JAWS for Windows do. Rather than speaking all the headers information at every cell, JFW and HPR speak the header cells that change as you move from one cell to another in the same way that they speak headers for simple data tables. There is one difference between the JFW and HPR implementation of headers on tables. When JFW encounters a cell with no headers tag, it assumes the header information is located in the first row and first column while HPR assumes there is no header information.
<STRONG>Travel Expense Report Meals Hotels Transport subtotals San Jose
file:///I|/1/8212final/LiB0026.html (12 of 13) [30.06.2007 10:18:18]
Creating Accessible Tables
25-Aug-97 37.74 112.00 45.00 26-Aug-97 27.28 112.00 45.00 subtotals 65.02 224.00 90.00 379.02 … Seattle
Guidelines for Accessible Tables Implementing accessible tables can be an expensive proposition, in terms of money and workload, but that expense can be totally avoided with careful design of data tables. In a table with 10 rows and 10 columns, a complex table requires all 100 cells to be specially coded. When the table is simple but the header positions are not in the first row or first column, there are about 20 specially coded cells. When the headers are in the first row and first column there don’t have to be any specially coded cells. ●
Identify row and column headers by placing them in the first row and first column.
Use the table header element,
, for all header cells or, if the visual effects of are not desired, use scope="row" or scope="col" on all header cells. This is essential if header information is not in the first row or first column.
Use the headers attribute to explicitly associate header information with data cells. This is essential if the table is not simple, meaning if the header information for a data cell is not in the same row and the same column as that cell.
file:///I|/1/8212final/LiB0026.html (13 of 13) [30.06.2007 10:18:18]
Avoiding Flicker Rapid visual changes, flashes, or blinking objects on a web page can cause photosensitive epileptic seizures in susceptible individuals. This is particularly true when the flashing has a high intensity and is in the frequency range between 2 Hz and 55 Hz. All of our target guidelines contain some advice on avoiding flicker. The Web Accessibility Initiative, Web Content Accessibility Guidelines caution web developers to avoid flicker so long as users have no control over flickering: 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. The two major browsers (Microsoft Internet Explorer and Netscape Navigator) permit users to stop animation in GIF’s by pressing the escape key. Opera more effectively allows users to turn off animation by using the menu options, File | Preferences, there in the Multimedia section uncheck the checkbox labeled “Enable Animation (GIF images).” §1194.22(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. The IBM Web Accessibility Guideline is not as specific as the Section 508 provision from the Access Board. 13. Blinking, Moving, or Flickering Content. Avoid causing content to blink, flicker, or move. It may be helpful to have an idea of what the frequencies of concern are like. The flashing rate of my text cursor is just shy of 1 Hz, of course that doesn’t help the reader very much! The caret blink rate (or cursor blink rate) in Windows 2000 is set in Keyboard settings from the Control panel. The blink rate varies from .4 Hz at the slowest setting to 3.1 Hz at the fastest; the middle setting is about .8 Hz. There are other ways that web pages can be caused to have flicker. There is the