Wikipedia:Manual of Style/Accessibility/Data tables tutorial

In contrast with simple tables, which only have headers spanning one column (! scope="col" | ) or one row (! scope="row" | ), some headers may span multiple columns or rows with the use of the colspan or rowspan attributes. To clearly define relationships and avoid accessibility issues, use ! scope="colgroup" colspan="2" | when a column header spans two columns and ! scope="rowgroup" rowspan="2" | when a row header spans two rows, adjusting the number if spanning more.^{[WCAG 4]}

{| class="wikitable"|-! scope="col" rowspan="2" | column header 1! scope="col" rowspan="2" | column header 2! scope="colgroup" colspan="2" | column header group|-! scope="col" | column header 3! scope="col" | column header 4|-! scope="rowgroup" rowspan="2" | row header group! scope="row" | row header 1| data || data|-! scope="row" | row header 2| data || data|-! scope="row" colspan="2" | row header 3| data || data|}

For tables with headers that are more complex, it is recommended to simplify the table or split it up into smaller tables. When this isn't possible, you have to associate each cell to their respective header(s) using the id and headers attributes instead of scope. On the headers, set the id to an unspaced value that is unique on the page. On the cells that are described by headers, set the "headers" to a spaced list of the describing "id" values in an order that a screen reader should read them.^{[WCAG 5]} For example, the following markup has the "Company" header describing the "ABC" company (! id="col1" | Company and | headers="col1" | ABC).

Below is an example of a complex table with headers that aren't visually clear, but uses id and headers instead of scope to associate column and row headers to individual cells. Again, it is recommended to simplify the table so headers are visually clear by splitting it into a "d" and "e" table if possible where the text in the "d" and "e" cells are moved to each table's caption.

{| class="wikitable"|-! id="a" | a! id="b" | b! id="c" | c|-! colspan="3" id="d" | d|-! id="w" headers="d a" | w (d a)| headers="d b w" | d b w| headers="d c w" | d c w|-! id="x" headers="d a" | x (d a)| headers="d b x" | d b x| headers="d c x" | d c x|-! colspan="3" id="e" | e|-! id="y" headers="e a" | y (e a)| headers="e b y" | e b y| headers="e c y" | e c y|-! id="z" headers="e a" | z (e a)| headers="e b z" | e b z| headers="e c z" | e c z|}

Note that colors and images with contrast conforming to accessibility requirements will print nicely in grayscale as an induced effect (among other benefits).

Images

• Priority: high (accessibility level: A)
• Difficulty: unknown (needs more testing and feedback for a precise rating)

Images inside a table should meet the general requirements in Wikipedia:Alternative text for images. However, small icons are the principal case encountered in a table. They fall into two categories:

1. icons of symbols ought to have minimal alt text that conveys the same information as the icon (example: if indicates an increase it has |alt=increase);
2. decorative icons (icons carrying no information or associated with a text providing similar information) need to be unlinked and have an empty alt text (|link=|alt=). When they are not able to be unlinked, a minimal alt text will suffice.

Note that images in headers can be particularly annoying for screen reader users if they are badly handled. If the image does not comply with the above criteria, the filename will be part of the header title. The filename will be read aloud in every cell under the header containing the icon. The alt text will also be repeated like the filename, which can also be a nuisance if it is irrelevant to the subject or is too long.

Color

• Priority: high (accessibility level: A)
• Difficulty: medium (needs testing and feedback for a precise rating)

Colors inside a table should meet the requirements for color.

• Color contrast – measured by the free Color Contrast Analyser – needs to be sufficient.
• A very simple tool that can be helpful for choosing contrasting colours is Color Oracle, a "free color blindness simulator for Windows, Mac and Linux".

But more importantly, information should not be conveyed by color alone. Information should also be available textually. A footnote or a textual sign^{[note 5]} can also be used to show a cell has a particular meaning.

Bad uses of color

From Fiscal calendar#Chart of Different Fiscal Years:

Good uses of color

Note: This is an example of using color rather than of providing accessible tables. Having the table caption in a table header instead produces a non-accessible table.

Legend: cells marked with "✓" are included in the fiscal year.

From Dwain Chambers (with improved table caption and structure; but the original use of color is good):

• Priority: high (accessibility level: A)
• Difficulty: unknown (not yet rated)

Nested tables can be confusing for screen reader users, however with correct usage they can be navigated as well as any other coding approach to the desired display.

The key principle in their design and implementation is to maintain normal flow, i.e. to ensure that the ordering of the content in the page code matches the order in which the content is to be presented. This also applies to other coding approaches, such as divs with CSS styling, or rowspan and colspan HTML cell attributes.

Nesting data tables with header cells also makes it difficult for assistive readers to parse them sensibly, and should be avoided.

Nesting tables may be the most appropriate method where cells of the parent table are to be subdivided with uneven internal row or column breaks. Note that each table must begin on a new line.

In the following example, nested tables are used to display sub-tables of varying cell heights:

{| class="wikitable"|{| class="wikitable"| Insert 1up|-| Insert 1down:<br>&nbsp;<br>Taller than insert 1up|}|{| class="wikitable"| &nbsp;<br>Insert 2<br>full height<br>&nbsp;|}|{| class="wikitable"| Insert 3up<br>&nbsp;<br>Tall cell here|-| Insert 3down|}|{| class="wikitable"| Insert 4up<br>&nbsp;|-| Insert 4down<br>Same as above|}|}

By comparison, using rowspan would not only need careful juggling of the positions and values but would break normal flow, splitting up each data subset and even causing Insert 3down and Insert 4down to be read in the wrong order:

{| class="wikitable"| Insert 1up| rowspan="4" | full height| rowspan="3" | Insert 3up<br>&nbsp;<br>Tall cell here| rowspan="2" | Insert 4up|-| rowspan="3" | Insert 1down:<br>&nbsp;<br>Taller than insert 1up|-| rowspan="2" | Insert 4down<br>Same as above|-| Insert 3down|}

CSS also has table display properties which can be applied to other elements such as divs, and could be used to create the layout with correct normal flow. But it requires a custom stylesheet defining the various classes of substitute entity. Moreover, it breaks the formal separation of HTML structure vs. CSS styling by using the styling language to render the correct structure onscreen. It is unnecessary and is not recommended.

Additional information can be found at Data tables tutorial/Internal guidelines‎‎. However, this guideline is not meant to be enforced, and only serves as a resource for members of WikiProject Accessibility.

These are examples of tables read aloud by screen readers. They may be useful as concrete examples to show to the community, when the community has difficulty in understanding how an accessible table benefits a screen reader user.

• Table using SCOPE attributes^{[dead link]} (NVDA using the Crystal voice from NaturalSoft)
• Table using ID attribute^{[dead link]} (NVDA using the default eSpeak voice)

WCAG references