DITA 1.3 and Improved Table Accessibility for Screen Readers

Other intriguing tidbits are emerging about what to expect in DITA 1.3. There’s very little information that is definite for those who do not have membership in OASIS, but interestingly the development milestone website is publicly accessible, though most of the more detailed information it references can only be found within password-protected sections held within the OASIS website. Still, there are some interesting tidbits of information there that provides a “head’s up” as to what to expect—or at least, what’s being considered, since nothing is final until it is published—which includes the following:

• A new Troubleshooting topic type (briefly explored in a previous article)
• New domains to better handle MathML and SVG
• Better release management-related markup
• Contain a stripped-down, lightweight version of DITA containing only the basics in terms of topic types and tags, suitable for those not needing complex functionality (and likely also an aide to learning the basics of DITA)
• Expansion of keyrefs to include ability to point to objects and parameters
• Mechanism to add rotation values to tables

…and considerably more. This is clearly designed to be an incremental update, not a wholesale change to the ways things are currently done.

As an example of that, one of the ideas that appears on the DITA 1.3 project tracking website has to do with extending the existing table model so that outputted tables are more accessible for those using spoken-word browsers. Oddly enough, this proposal provides more than just a brief description as to how it is supposed to work, so I have pieced together a brief overview as to how I think it is supposed to work.

Keep in mind that the following is speculation on my part, and that even if I am correct that there is still time for changes, so there could well be changes over what I present here.

Accessible Tables?
For those people who use voice or Braille readers to read content, reading content arranged in a table can be problematic, as it can be hard to determine which item being read aloud belongs to which column or row, especially in large tables. The proposal for this addition to DITA 1.3 quotes the World Health Organization, which says: “285 million people in the world are visually impaired, of whom 39 million are blind and 246 million have moderate to severe visual impairment”. So the idea is to improve DITA so that screen reader users can better understand the content that is being read to them. In most cases this does not pose a problem, but with content in tables it can be, as it is not always easy to discerne which spoken value in a cell within table row belongs to which column.

The new DITA 1.3 proposal relating to accessible tables adds attributes that explicitly identifies the table’s headers and associates specific data elements within the table to those headers.

This is accomplished by adding the new element rowheader to the table and colspec tags. This new element can take one of the following three possible values:

• rowheader="firstcol" – indicates that the entries in the first column of a table are to be considered row headers
• rowheader="headers" – entries for a column (described via colspec) are to be considered row headers in those cases where there is more than one column of row headers
• rowheader ="norowheader" – says that the entries in the first column have no special significance and are not be considered as column headers

The entry tag—which handles the content of an individual cell within a table—also gains two additional attributes: scope and headers. They will work like this:

• scope – can take one of four possible values: row, col, rowgroup and colgroup, each indicating in turn what type of grouping the data in the cell belongs
• headers – takes the name of the header that applies to the individual cell

Here is some example code that I have put together from the proposed specification to demonstrate how I think this would work (with the new attributes highlighted in bold):

<table frame=”all” rowheader=”firstcol”>
<title>Table Accessibility Example</title>
<desc>Names are listed in the column c1. Points are listed in both data columns, with the expected value in column c2 and the actual value in column c3.</desc>
<tgroup cols=”3″>
<colspec colname=”c1″/>
<colspec colname=”c2″/>
<colspec colname=”c3″/>
<thead>
<row>
<entry morerows=”1″> </entry>
<entry namest=”c2″ nameend=”c3″ id=”pts”>points</entry>
</row>
<row>
<entry id=”exp” headers=”pts”>expected</entry>
<entry id=”act” headers=”pts”>actual</entry>
</row>
</thead>
<tbody>
<row>
<entry id=”name1″>Mark</entry>
<entry headers=”name1 exp pts”>10,000</entry>
<entry headers=”name1 act pts”>11,123.45</entry>
</row>
<row>
<entry id=”name2″>Peter</entry>
<entry headers=”name2 exp pts”>9,000</entry>
<entry headers=”name2 act pts”>11,012.34</entry>
</row>
<row>
<entry id=”name3″>Cindy</entry>
<entry headers=”name3 exp pts”>10,000</entry>
<entry headers=”name3 act pts”>10,987.64</entry>
</row>
</tbody>
</tgroup>
</table>

I believe the way this would work in a reading browser is that it would recognize that the first column is meant to be a header, with “expected” and “actual” relating to “points”. Each of the people (Mark, Peter and Cindy) are explicitly identified, so I would expect Mark’s entry when read aloud by the browser to say:

“Mark expected points 10,000, Mark actual points 11,123.45”.

Contrast this to how it would normally be spoken: “Mark 10,000 11.123.45”. The new method simply makes it more explicit which value is to be associated with which person, instead of the user having to remember which column means what.

How Will this Work?
There are still some questions to be answered about this addition to table formatting in DITA, the primary one for me being: how would this be expressed at output? The proposal outlines ways in which HTML and FO output can be adapted to express the DITA content so that the accessibility features within the tables are preserved.

For HTML this is fairly straightforward, with the scope attribute added to identify distinct columns and rows. So I suspect the output would be transformed into the following (or something very similar):

<table>
<caption>Table Accessibility Example</caption>

<tr>
<th scope=”col” colspan=”2″></th>
<th scope=”col”>points</th>
</tr>

<tr>
<th scope=”row”>expected</th>
<td>expected</td>
<td>April 5</td>
</tr>

<tr>
<th scope=”row”>Beth</th>
<td>8</td>
<td>January 14</td>
</tr>

</table>
…which, when rendered, would look something like this:

I don’t know enough about FO to comment on the transforms that would be used to transform the DITA XML into PDF, but the PDF specification has a fairly robust set of accessibility guidelines that ought to make this sort of thing possible.

Look for future articles here on DITAWriter.com where I try to delve into other features that may be coming in DITA 1.3!