Feature Documentation: Table

Back to Accessibility Feature Documentation

OneNet Text Editor  UI

tablecolumns options

Accesible “Table” Features

Action item/conclusion/suggestion (Aug 23, 2016)

  • Improvement for the style options for the table–to present clear styling for the table.
  • Build consensus on requiring both header and column in feature documentation.

Accessibility test by table types:

  • Row & column headers
  • No row headers
  • No column headers
  • Two columns

Simple Tables

Test 1: Row & Column Headers

Name Age Sex Race
Doe, John 20 Male White
Doe, Jane 30 Female Black
Doe, Jack 40 Male Asian

Test 2: No Row Headers

Name Age Sex Race
Doe, John 20 Male White
Doe, Jane 30 Female Black
Doe, Jack 40 Male Asian

Test 3: No Column Headers

Name Doe, John Doe, Jane Doe, Jack
Age 20 30 40
Sex Male Female Male
Race White Black Asian

Test 4: Two Columns

Name Doe, John
Age 20
Sex Male
Race White


All tests above pass HTML Validation, FAE, WAVE, AChecker and Tenon.io, except that AChecker incorrectly (?) reports that Test 1 requires id and headers attributes.

In tests 2-4, JAWS (15) does not read row/column headers that are not marked up when using table reading commands.

Are all of these “accessible”?

References (emphasis added)

  • WCAG 2.0 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
  • Sufficient Technique H51: Using table markup to present tabular information:

    Information is considered tabular when logical relationships among text, numbers, images, or other data exist in two dimensions (vertical and horizontal)….

    Simple tables generally have only one level of headers for columns and/or one level of headers on the rows….

    Usually, for simple tables… Row 1 columns are not blank (i.e. they contain “column headings”), describe the contents of the entire column, and allow the reader to distinguish the difference in meaning between that column and other columns….

    Column 1 rows are usually not blank, they often contain “row headings” which describe the contents of the entire row, and allow the reader to distinguish the difference in meaning between that row and the other rows. Otherwise, the Column 1 would contain simple data.

  • Web Accessibility Tutorials: Tables with one header

    …This is only acceptable because it is such a small table and the data itself is distinctly different in each column, so that the relationship between the header and data cells is evident….

  • WCAG 1.0 5.1 For data tables, identify row and column headers.
  • Section 508 (g) Row and column headers shall be identified for data tables.

There seem to be two contradictions in the W3C references above:

  • Do tables require relationships in (at least) two dimensions, or is just one acceptable?
  • Is it OK for relationships to be evident or must they be programmatically determined?
Requirement Type Priority
Allow user to select from different styles of tables (choices for CSS classes), among some pre-formatted (and admin configurable) options. (e.g. row headers bold or not) High
Provide a means of inserting and editing a table; prompt users for numbers of rows & columns (discussion: can you have only row or column headers instead of both? Consider table for displaying days of month, periodic table of elements, etc.) High
Automatically use table header cells in first column and first row High
Automatically add id and headers attributes when table cells are merged High
Provide “table check” to visualize and confirm header/cell associations High
Provide obvious help/instruction on why and how to use tables High
Address screen reader issues with tabbing if tab is employed for automatic movement between <td>s and automatic creation of a new row if tab is pressed at last character in last <td> of <tr> Medium
Prompt user (with several options) to provide a caption/summary for the table (aria-label by the closest previous heading, visible caption… no non-visible attributes/fields–same experience for screen reader and sighted user). First pass is to make sure we have an accessible name for the table. Second pass is to allow for a longer description Real Time High
Allow user to set table width value (auto versus full) Medium
Option to add/remove/merge rows, cells, and columns (second pass: ability to right-click within a cell to pull up a context menu for performing these functions) High
Need an option for alignment (left, right, center) of content within a cell (second pass: ability to apply that alignment to entire row/column as one action) High
Nested tables NOT allowed High
Complex tables (and functions for managing them) are allowed (see OneNet, but may need a way to merge rows as well, as well as supported complex table patterns, below) High

Supported Complex Table Patterns

Besides obvious accessibility reasons, keeping data table <td>s from being merged keeps it in an importable machine readable format (e.g. into Excel).

All tables must have <th>s: both column and row headers.

Col 1 Col 2
Rowgroup 1
Row 1 data 1 data 2
Row 2 data 3 data 4
Rowgroup 2
Row 3 data 5 data 6
Row 4 data 7 data 8
Colgroup 1 Colgroup 2
Col 1 Col 2 Col 3 Col 4
Row 1 data 1 data 2 data 3 data 4
Row 2 data 5 data 6 data 7 data 8


Columns (complex non-table based layouts) would be a template-based feature and be available for list objects (multi-column list). Also, we’ll expose some options to apply CSS 3 multi-column properties to some objects (like lists). Also, may be able to handle some CSS visual layout (saving vertical space) using inline-block/auto-width.

We may want to expand this a bit to something like an “advanced layouts” menu that will insert some template content with stubs into the page. For columns it might be:

[selected from insert template drop-down: “two column layout”]

<div class=”a11y_row”>
<div class=”a11y_column”>
Content for column 1
<div class=”a11y_column”>
Content for column 2

We could inject some CSS <style> tags into the page to make it look okay with some default styling, but also give an option to toggle that CSS output off, in case the end user has added their own CSS to their site styles for this (or, additionally, and maybe preferably, have them include their custom styles so that it’s rendered the same-ish in the WYSIWYG as in the end-user view).

Requirement Type Priority
Provide means of creating columns using divs rather than tables
Provide obvious help/instruction on why and how to use columns