Back to Accessibility Feature Documentation
OneNet Text Editor UI
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 |
Notes
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
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>
<div class=”a11y_column”>
Content for column 2
</div>
</div>
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 |