Layout tables and repair techniques

Monday, 7th January 2013

<table role="presentation">
⋯
</table>

Author: Gez Lemon

Layout tables

Although using role="presentation" stops redundant table information being announced to screen reader users, form controls within a fieldset are not reliably announced by JAWS with the context of the legend element to provide a label for the group. In the following example, when a JAWS user navigates through the radio buttons, they hear something like, "radio button not checked maybe 1 of 3", "radio button not checked yes 2 of 3", and "radio button not checked no 3 of 3" without the context of "Attending" (Firefox with JAWS provides the context when navigating forwards to a radio button in the group, but not when navigating backwards to a radio button in the group. IE with JAWS completely ignores the context provided by the legend element).

<fieldset>
<legend>Attending?</legend>
<table role="presentation">
<tr>
  <td>
    <input type="radio" 
           id="att1" 
           name="att" 
           value="maybe">
  </td>
  <td><label for="att1">Maybe</label></td>
</tr>
<tr>
  <td>
    <input type="radio" 
           id="att2" 
           name="att" 
           value="yes">
  </td>
  <td><label for="att2">Yes</label></td>
</tr>
<tr>
  <td>
    <input type="radio" 
           id="att3" 
           name="att" 
           value="no">
  </td>
  <td><label for="att3">No</label></td>
</tr>
</table>
</fieldset>

If the layout table isn't included, a JAWS user hears "Attending" as the context for the radio button in the group that receives focus. Continuing to navigate through the radio buttons in the group only announces the radio button information, as the context has already been provided.

Repair techniques

When form controls are in a layout table within fieldset/legend elements, the context information is lost in JAWS, even when the table semantics are removed with role="presentation". The obvious solution is to remove the layout table, but sometimes this option is too costly and developers just want a solution that works. One solution is to use WAI-ARIA's aria-describedby attribute. To do this, add an id attribute to the legend element, and use aria-describedby on the radio buttons that references the id attribute set on the legend element.

<fieldset>
<legend id="attleg">Attending?</legend>
<table role="presentation">
<tr>
  <td>
    <input type="radio" 
           id="att1" 
           name="att" 
           value="maybe" 
           aria-describedby="attleg">
  </td>
  <td><label for="att1">Maybe</label></td>
</tr>
<tr>
  <td>
    <input type="radio" 
           id="att2" 
           name="att" value="yes" 
           aria-describedby="attleg">
  </td>
  <td><label for="att2">Yes</label></td>
</tr>
<tr>
  <td>
    <input type="radio"
           id="att3" 
           name="att" 
           value="no" 
           aria-describedby="attleg">
  </td>
  <td><label for="att3">No</label></td>
</tr>
</table>
</fieldset>

This technique works with JAWS, but requires using aria-describedby for each element in the fieldset. This approach also has the undesirable effect of announcing the context after the radio button information, rather than before the radio button, as the user would be used to with regular elements within a fieldset/legend section. It also means that screen readers that do announce the group label provided by the legend element also announce the description afterwards, which is overly verbose.

Ideally, we want a group label that is announced just once the first time the group is visited, so a more effective solution would be to use a role of group (or region if the section is significantly important) on the table element instead of the presentation role, and use aria-labelledby to provide the name for the group. Steve Faulkner pointed out that child element roles are unaffected by a parent role of group, so the table semantics are still present and need overriding with role="presentation". This should result in the same relationship as fieldset/legend without the layout table.

<fieldset>
<legend id="attleg">Attending?</legend>
<table role="group" aria-labelledby="attleg">
<tbody role="presentation">
<tr role="presentation">
  <td role="presentation">
    <input type="radio" 
           id="att1"
           name="att"
           value="maybe">
  </td>
  <td role="presentation">
    <label for="att1">Maybe</label>
  </td>
</tr>
<tr role="presentation">
  <td role="presentation">
    <input type="radio" 
           id="att2" 
           name="att" 
           value="yes">
  </td>
  <td role="presentation">
    <label for="att2">Yes</label>
  </td>
</tr>
<tr role="presentation">
  <td role="presentation">
    <input type="radio" 
           id="att3" 
           name="att" 
           value="no">
  </td>
  <td role="presentation">
    <label for="att3">No</label>
  </td>
</tr>
</tbody>
</table>
</fieldset>

This arrangement works in Firefox, and ensures that the context is reliably provided before the radio button information just once when the group is visited forwards or backwards, in the same way as when the layout table isn't present with fieldset/legend. Unfortunately, it is completely ignored in IE with JAWS, and announced twice in browsers that do announce the legend content as a label for the group.

As this attempt used lots of role="presentation" markup, I decided to wrap the table in a div element and moved the role="group" and aria-labelledby markup to the containing div element, and put the table role back to role="presentation". This arrangement didn't work either. After further discussion with Steve Faulkner, he pointed out that IE doesn't suppress the semantics of table cell elements when role="presentation" is used on the table element (it should do). I added role="presentation" to each of the table cells, and it finally worked as expected.

<fieldset>
<legend id="attleg">Attending?</legend>
<div role="group" aria-labelledby="attleg">
  <table role="presentation">
  <tr>
    <td role="presentation">
      <input type="radio" 
             id="att1"
             name="att"
             value="maybe">
    </td>
    <td role="presentation">
      <label for="att1">Maybe</label>
    </td>
  </tr>
  <tr>
    <td role="presentation">
      <input type="radio" 
             id="att2" 
             name="att" 
             value="yes">
    </td>
    <td role="presentation">
      <label for="att2">Yes</label>
    </td>
  </tr>
  <tr>
    <td role="presentation">
      <input type="radio" 
             id="att3" 
             name="att" 
             value="no">
    </td>
    <td role="presentation">
      <label for="att3">No</label>
    </td>
  </tr>
  </table>
</div>
</fieldset>

Conclusion

The table element should only be used for describing data tables, rather than using tables for layout purposes. If layout tables absolutely cannot be avoided, then using role="presentation" is effective at ensuring that redundant table information isn't announced to screen reader users. However, this can't be relied on alone when form controls within fieldset/legend elements are in layout tables for JAWS users.

If it's impossible to avoid layout tables for the whole website, at least avoid using tables for layout within fieldset/legend elements. If this isn't possible, then the repair technique is to wrap the table in an element with role="group" and an aria-labelledby attribute that identifies the group label (the legend), and the table element and each table cell must be overridden with role="presentation".

The repair technique for ensuring that form controls in a layout table within fieldset/legend elements is probably more complicated than not using layout tables in the first place, and duplicates the group label for assistive technologies that correctly ignore layout tables with role="presentation". Sometimes, it's difficult to find a repair technique that works in all situations, but using the most semantically appropriate elements will always result in a more accessible experience.

Category: Accessibility.