So far, so good. But it gets a bit trickier from here. According to Adobe, tagged PDF documents can support markup for data tables, including identification of row and column headers and association of data cells with those headers. (See Chapter 11 for details on how to mark up data tables in HTML using id and headers attributes on the <th> and <td>elements, respectively.) According to Adobe's online documentation, PDF now allows electronic publishers to
. . . preserve markup in tables in an Adobe PDF file, including table rows, header cells and data cells. Acrobat 5.0 for Windows enables users to create tagged Adobe PDF files automatically from Microsoft Office 2000 for Windows applications. If the author defines table rows, header cells and data cells in the application, Acrobat 5.0 will automatically include that information in the PDF file. Users of Macintosh or Windows versions can create or edit data table header information using the Acrobat tags palette. For more information, see the White Paper "Enhancing the Accessibility of the Web with Adobe Acrobat software." 
 "Acrobat 5.0 and Section 508." Accessed February 10, 2002, at http://access.adobe.com/acr508_2.html.
This makes it sound easy, but not so. Word 2000 does not have built-in mechanisms for HTML-style identification of column and row headers or for associating data cells with those headers. For example, we took the small table and pasted it into an otherwise empty Microsoft Word document, saved the file, and then converted it to PDF. The result appears in Figure 12-6.
Figure 12-6. A tagged PDF document, created from a Microsoft Word file that contains only a small data table. The Acrobat Reader plug-in displays the PDF document in Internet Explorer 5.5. Used with permission.
The good news is that JAWS can read the items in the table and read them in the correct order. The bad news is that JAWS doesn't quite seem to recognize the table as a table. Actually, it's a little more ambiguous than that. Pressing Alt+Ctrl+NumKeypad5 the JAWS keystroke for querying the current data cell yields the message "Row 0, Column 0" no matter what cell you're in. This would seem to indicate that JAWS recognizes the table but can't identify where the focus is. But pressing Alt+Ctrl+DownArrow the keystroke for reading down the current column returns an even more surprising result: "Not in a table," says JAWS, though clearly it is in a table.
We wondered whether this was a JAWS problem or an Acrobat problem, so we asked a friend to try reading the table with IBM Home Page Reader 3.0. He reported the same result: Home Page Reader read the words on the page in the correct order but did not recognize the presence of a table.
Acrobat's Accessibility Checker
It should be possible to identify such problems and fix them: Acrobat 5 includes an Accessibility Checker licensed from SSB Technologies and based on SSB's InSight product. But the Accessibility Checker reports "no problems" in our new PDF document, even though the document contains nothing except our little table and there is clearly something wrong. The table doesn't meet the relevant WCAG 1.0 checkpoints or the Section 508 standard, and there's no reason the Accessibility Checker shouldn't be able to spot this.
Even when the Accessibility Checker does find problems, its reports are hardly useful. We ran the Accessibility Checker on a newsletter with a complicated layout and got a dialog box that offered the following report:
The checker found problems which may prevent the document from being fully accessible.
+ All of the text in this document lacks a language specification.
44 element(s) with no alternate text.
+ This document is unstructured; the reading order of the contents may be incorrect.
The report indicates that there are major problems, but it offers no information about how to find them in the document itself and no guidance about fixing them. With help like this. . . .
Acrobat's Tags Palette
Since we clearly couldn't count on the Accessibility Checker, we decided to try the Tags palette, which at first sight is both forbidding and unhelpful (Figure 12-7).
Figure 12-7. Acrobat 5's Tags palette opens in a small window inside the main document window. It partially overlaps the document's contents. The only thing visible in the Tags palette is the highlighted phrase "Tags Root." Used with permission.
Sighted readers will quickly note that there's a small plus sign (+) just to the left of the phrase "Tags Root," indicating that the term can be expanded to reveal more levels. For some reason, however, the phrase "Tags Root" did not have focus (that is, it wasn't highlighted) when the Tags palette first appeared on the screen; it received focus only after we pressed Ctrl+Tab twice in succession. This took us first to the Fields view (which was completely empty) and then back to Tags view. At that point, JAWS reported the existence of the Tags Root and the option to expand it using the arrow keys. Pressing the right arrow several times finally brought us to the contents of the first table row (<tr>) element (Figure 12-8), which is where the table headings (<th> elements) usually go.
Figure 12-8. Acrobat's Tags palette in expanded view. The first table row contains two <td> elements instead of table headers. Used with permission.
This was helpful. It told us, first, that the document did indeed contain a <table> element. And we could also see that there were no column headers in the first table row as there should have been. To fix that, we brought up the applications menu and selected the Element Properties. . . option to open the dialog box shown in Figure 12-9.
Figure 12-9. Acrobat's Element Properties dialog box is now overlaid on top of the Tags palette. The element name "TD" is highlighted. Used with permission.
We replaced the highlighted letters "TD" with "TH" for this element and the next one and, voilà, we had properly labeled the column headers (Figure 12-10).
Figure 12-10. Another view of the Tags palette. The <td> elements shown in Figure 12-8 have now been replaced with <th> elements. Used with permission.
We changed the tags in the first table row from <td> to <th>; we also changed the content of the cells by entering a new phrase in the field labeled "Actual text." However, the changes had no apparent effect. The content of the cells remained unchanged, and JAWS was again unable to report the table properly.
We encountered other difficulties during this exercise as well. Not only did JAWS fail to report that "Tags Root" had focus when the Tags palette first appeared, but we were unable to return focus to other parts of the document without closing the Tags palette. The Tags palette itself has no Close, OK, Cancel, or Help buttons; the only way that someone using a screen reader can close it is by pressing Alt+F4. And, finally, if the user switches to another open application using Alt+Tab and then comes back to Acrobat the same way, the Tags palette will still be visible on the screen but the Tags palette will not have focus, and the only way to give it focus is apparently to click on it with the mouse. Catch 22 again.
Authors who are blind or who work exclusively at the keyboard will be seriously hindered by the problems with focus that we've described, though these problems will have less impact on those who are sighted and able to point and click. The problems with Acrobat's built-in repair tools are more serious since there appears to be no way to correct the table markup (unlike HTML, there is no "view source" option or rather, the Tags palette is the equivalent mechanism).