Lotus Notes checklist

Checkpoint 5.5: Data tables

Avoid the use of data tables.


Applicable user interfaces

This checkpoint only applies to Lotus Notes applications viewed through the Notes client.

Note: Applications that support both the Notes client interface and the Web interface must complete both the Web checklist and the Lotus Notes checklist. When completing the Web checklist, related techniques and examples for Domino developers are found in Web checkpoint 1.3e – Tables.


Rationale

Tables used for layout may be used in Notes client applications, but large or complex data tables are not accessible when viewed in the Notes client, and should not be used. You cannot identify table headers in a Notes client application, so a screen reader cannot announce the headers when a user is navigating the cells of a data table. Screen readers read a table line by line as text. Small, simple data tables with a few columns may be used if the table contents are unique per column, identifiable when read as a line, and there are no empty or complex (joined) cells. The rationale is that a user can gain understanding and maintain orientation reading line by line in a small table that meets these criteria. Users become lost or cannot determine context in tables with many columns, many rows, empty cells, joined cells, or indistinguishable data.


Required development techniques

The following techniques are the minimum required to meet Checkpoint 5.5 from the Lotus Notes Application Accessibility Checklist:

  1. Layout tables do not require additional markup for accessibility.
  2. Large or complex data tables are not accessible when used with the Notes client, and should not be used. Small data tables may be used with judgment.

Examples of required techniques

  1. Layout tables do not require additional markup for accessibility.

    How to recognize a layout table: In a layout table there are no associations. Each cell that provides information does so in a manner in which the information is stand-alone and does not require any additional information for clarification. One cell in the table does not contain information that is directly related to another cell and where the visual relationship is crucial to the understanding of the information in either cell.

  2. Large or complex data tables are not accessible when used with the Notes client, and should not be used. Small data tables may be used with judgment, as described.

    How to recognize a data table: In a data table, the information in one table cell is somehow visually associated with the information in another cell, either in the same row or the same column. Most often, a column header or a row header, or both, will define the meaning of the contents of the cell.

    How to determine if a table may be used:

    A table must be small enough and have sufficiently identifiable data that enables the user to understand the relationships between the cells when the screen reader reads it line by line, (i.e., left to right with no pauses, next row, left to right, etc.) When deciding whether a data table may be included, the following gives guidance in making the judgment call:

    1. The table must be simple with no complex cells. A simple data table has only one row of column headings and/or one column of row headings, with no joined cells.
    2. There must only be a few columns, generally four or fewer. The user will hear the content of every cell on every row read in sequence as a line. More than a few columns will lead to confusion of the identity of the columns.
    3. The data must be identifiable and unique. The user will hear the line read without any reference to the column header. The user should be able to identify the column based on the data being read. For example, names, titles, and status would generally be identifiable if appearing in only one column. Side-by-side columns of numbers are generally not sufficiently identifiable or unique. Some text columns side by side may not be distinguishable when read as a line.
    4. The data must be complete. Empty data cells in the table can cause the user to lose track of which column the next data is read from. The screen reader does not inform the user there is a blank cell, making empty cells inaccessible.
    5. The number of data rows must not be excessive. Because there is no way to programmatically determine where the table begins or ends, the user must navigate past all the data rows to get to content preceding or following the table. Too many rows makes traversal unreasonably time consuming. Generally the number of rows should be fewer than 10. Data tables with more than 20 rows should not be considered. The content of the table should also be considered when determining table size. It can be much easier to work with a table of words than a table of numerical values.
    6. The table should be unique on the page. Multiple tables with similar data cannot be distinguished without navigating to the header and reading it. This is not accessible.

Testing should be conducted with a screen reader to verify that a user can understand each specific table and the meaning of its contents.


Recommended development techniques

The following techniques are recommended to enhance accessibility of data tables:

  1. Avoid using images as cell backgrounds. On the Table / Cell Background tab of the Table Properties box there are options to use images as the cell background. These background images may make it difficult for someone with low vision to see the table data.
  2. When using layout tables to structure fields on a form, verify that the tab order within the table is logical. If a table has multiple columns, by default the tab order will go from top to bottom and left to right. This may not make sense if the user should fill out the first column of information and then the second column of information.

Required test techniques

Test the application to ensure that it complies with accessibility requirements.

Tools

Install the following tool to test this checkpoint:

Techniques

The following techniques are required to verify this checkpoint:
Action Result
1. For layout tables, verify the screen reader reads the page in a logical order. Pass:
Fail:
2. If data tables are used, determine if a user can maintain context and understand when reading with a screen reader, line by line. Listen to the rows read by a screen reader, and use your judgment to verify the following compliance criteria:
Pass:
Fail:

©2009 IBM Corporation

Last updated August 25, 2009.