Wikipedia:Manual of Style/Accessibility/Data tables tutorial/Internal guidelines

Advice on this page is not meant to be enforced, and only serves as a resource for members of the WikiProject Accessibility. Some advice may be used on a few pages when relevant, but it is not all meant to be widely used.

Usability guidelines

Status: Complete. Reviewed by an accessibility expert.

These guidelines are not accessibility guidelines. They are usability guidelines that makes it better for everyone, and especially the disabled. These are not accessibility requirements, because with the previous guidelines screen readers already have access to the information and are able to use the table. However, the following guidelines makes it easier and more comfortable for them to use the table.

Making relevant row headers

• Priority: middle (bonus guideline)
• Difficulty: middle (needs more testing and feedback for a precise rating)

When read by screen readers, headers are repeated in every corresponding cells. So headers must be closely related to their corresponding cells to produce a meaningful result. This is often an issue in row headers in Wikipedia.

For example, the discography tables do not use any row headers as the first cell in the rows are dates. In this case, dates would not be relevant as row headers. It's not "1989" that was sold 1.7 million times; it's "Bleach". The albums column should be switched with the dates. It would allow making relevant row headers out of the albums first cells.

Bad example of row headers

From Wikipedia:WikiProject Discographies/style (date is used as a row instead of the album):

Year	Album details	Peak chart positions										Sales	Certifications
		US	AUS	AUT	FIN	NLD	NZ	NOR	SWE	SWI	UK
1989	Bleach Released: June 15, 1989 Label: Sub Pop (SP #34) Format: CD, cassette, LP	89	34	26	24	—	30	—	—	—	33	1.7 million (US)	Platinum (US)
1991	Nevermind Released: September 24, 1991 Label: DGC (DGC #24425) Format: CD, CS, LP	1	2	2	1	5	2	2	1	2	7	10 million(US) 26 million (worldwide)	Diamond (US) 2× Platinum (UK)

Good example of row headers

Nirvana albums, compilations and box sets

Title	Album details	Peak chart positions										Sales	Certifications
		US	AUS	AUT	FIN	NLD	NZ	NOR	SWE	SWI	UK
Bleach	Released: June 15, 1989 Label: Sub Pop (SP #34) Format: CD, cassette, LP	89	34	26	24	—	30	—	—	—	33	1.7 million (US)	Platinum (US)
Nevermind	Released: September 24, 1991 Label: DGC (DGC #24425) Format: CD, CS, LP	1	2	2	1	5	2	2	1	2	7	10 million(US) 26 million (worldwide)	Diamond (US) 2× Platinum (UK)

Avoid merging cells not meant to duplicate the same information

• Priority: middle (bonus guideline)
• Difficulty: middle (needs testing and feedback for a precise rating)

Most importantly, it can cause severe confusion when unrelated cells (in relation to their corresponding headers) are merged. This confuses everyone so it's not an accessibility-specific issue. However, the result can be far more confusing for screen reader users than sighted users.

Bad example of cell merge

Example from Fiscal year#Chart of Different Fiscal Years. This table is only visually structured, and is wrong from a data point of view. "Australia is under the column headers "Country" and "Purpose". Sighted users can understand the cell under "Purpose" is supposed to be blank because of the visual empty space. But machines (including screen readers) can only understand: "Country: Australia. Purpose: Australia." or "Country, Purpose: Australia."

By Country
Country	Purpose
Australia
Canada
Japan	govt
	corp. and pers.
New Zealand	govt
	corp. and pers.

Good example of cell merge

"Japan" and "New Zealand" are good example of merged cells.

Note: having the table caption in a table header instead is suboptimal and annoying. Screen readers might read "By Country" in every cell. As of September 2010, this table header is necessary for the collapsible script to work. Until the script is improved we should continue to use this syntax. These tables are directly under a header. In this case a table caption more precise than "By Country" is unnecessary as it would duplicate the header.

By Country
Country	Purpose
Australia
Canada
Japan	govt
	corp. and pers.
New Zealand	govt
	corp. and pers.

Special case where wrong rowspans can hardly be avoided

Disclaimer: This example is not considered as a good example. It is used to improve rare cases where a table has an incorrect structure, and consensus cannot be reached to change the whole structure of the table. This example solves accessibility issues for screen readers only, and people with different or multiple disabilities may have trouble with this table. Since this table has no semantic structure, robots, search engines and other machines cannot reuse their content correctly. A better solution would be to move the chronometers' long descriptions out of the table into a paragraph.

Example: If merging non-similar cells is essential, while not ideal, a work-around is to create a hidden column. This column can be given an appropriate heading name, that will not appear to sighted readers but will be recognized and read by screen readers. The following example is a snippet of a table from List of chronometers on HMS Beagle.

Chronometers on second voyage

Des.	Extended comments	Maker	No.	Owner	Type	Winding	Comments
H		Arnold & Dent	261	Fitz-Roy	pocket	one-day	Assessed by Fitz-Roy as "rather good"
K		Parkinson & Frodsham	1042	Government	pocket	one-day	Assessed by Fitz-Roy as "rather good"
	Chronometer K was used as the journeyman chronometer, carried to the place of measurement in its box (despite being a "pocket" chronometer). On most days, while under sail, the place of measurement was the ship's deck to determine the ship's position at sea. It was compared with the two best chronometers (the standards) immediately before and after each use and always agreed with the standard.
L		Arnold	634	Fitz-Roy	box	two-day	Assessed by Fitz-Roy as "rather good"

Bonus guidelines

The main purpose of these bonus guidelines is to provide information and prevent mistakes. Guidelines in this section are not supposed to be enforced. It is meant to provide guidance about low priority accessibility improvements, and mostly set them aside. They can eventually be used when relevant, but with caution and prior discussion.

Providing abbreviations for long headers

Status: Complete. Needs to be reviewed by an accessibility expert.

• Priority: negligible (was a WCAG 1.0 criterion, dropped in WCAG 2.0)
• Difficulty: high (Because of the confusing way this abbreviation works, editors are very likely to misunderstand and misuse them. It would be better to avoid using this technique.)

Voice browsers might read aloud this data table in the following order:

Caption: [caption text]
[column header 1]: [row header 1], [column header 2]: [cell 1,2], [column header 3]: [cell 1,3]
[column header 1]: [row header 2], [column header 2]: [cell 2,2], [column header 3]: [cell 2,3]

...

Note that each column header is repeated when reading every row, so an abbreviation could be added to long headers using the abbr="..." attribute, for example:

{|
|+ [caption text]
|-
! scope="col" abbr="Wikipedian" | Wikipedia editor
! scope="col" abbr="Edits"      | Number of edits
! scope="col"                   | Last edit
! scope="col" abbr="Donations"  | Donations (US$)
|-
...

In this example all column headers have an abbreviation except the column with the date of the last edit, which is short enough.

Avoiding more than two levels of headers

Status: Complete. Needs to be reviewed by an accessibility expert.

• Priority: unknown (recommended by WebAIM techniques)
• Difficulty: ... (needs testing and feedback for a precise rating)

Tables should not contain more than two levels of headers (which means 1) headers 2) sub-headers; but no 3) sub-sub headers). When relevant, it can also be encouraged to merge some levels of headers in order to simplify the headers and to make them more useful.

Example from Chad Hedrick and Template:PersonalRecords. The contents of {{PersonalRecordsTop}} and {{PersonalRecordsSport}} should be merged in a table caption.

Bad example

Note that headers are only visual as they are made of cells and bold:

Personal records
Men's speed skating
Distance	Time	Date	Location	Notes
500 m	35.52	2009-12-26	Salt Lake City
1000 m	1:07.33	2009-12-13	Salt Lake City

Good example

With correct headers as well:

Personal records in men's speed skating

Distance	Time	Date	Location	Notes
500 m	35.52	2009-12-26	Salt Lake City
1000 m	1:07.33	2009-12-13	Salt Lake City

Providing a summary

Status: Complete. Needs to be reviewed by an accessibility expert.

• Priority: high (A accessibility level)
• Difficulty: hard (Same issue with alt texts for images containing a lot of information (charts, etc.): it takes a lot of time to write, and editors don't have the slightest idea what to write in it. Average users don't benefit from it, so it doesn't blend in with editorial practices at all. We are not yet sure if table summaries should be encouraged in Wikipedia because they might be misused.)

A summary provides a brief overview of the table's contents, highlighting the most important data, or a brief explanation of how to navigate the table. The summary makes this information available to people who use screen readers; the information is not displayed visually.

Note that a summary is not needed in most of Wikipedia's tables. The summary is useful when the table has a complex structure (for example, when there are several sets of row or column headers, or when there are multiple groups of columns or rows). The summary may also be helpful for simple data tables that contain many columns or rows of data.

The summary attribute may be used whether or not the table includes a caption element. If both are used, the summary should not duplicate the caption.

Good and bad uses of table summaries

Bad use

Good use

{| summary="List of Television appearances and roles" |+ Television … Example taken from this diff. In this case a table summary is not needed because the table is fairly simple and standard.

{| summary="Intersections are listed in row 1. Find the intersection closest to your starting point or destination, then read down that column to find out what time the bus leaves that intersection. Service begins at 4:00 AM and ends at midnight."> |+ Schedule for Route 7 going downtown ! scope="col" | State & First ! scope="col" | State & Sixth ! scope="col" | State & Fifteenth ! scope="col" | Fifteenth & Morrison |- |4:00 |4:05 |4:11 |4:19 |- … |}

Result: the summary is invisible for most users, but users who need it will be able to use it (with the corresponding assistive technology).

Schedule for Route 7 going downtown

State & First	State & Sixth	State & Fifteenth	Fifteenth & Morrison
4:00	4:05	4:11	4:19

Avoiding rowspan/colspan

Status: Complete. Needs to be reviewed by an accessibility expert.

• Priority: bonus (this criterion is not part of any accessibility referential and has limited impact)
• Difficulty: hard (Users like those attributes for presentation and are reluctant to remove them. We should not force them otherwise they might feel disgusted about accessibility. This change can only be done with volunteer users and is fragile as anyone can jump in and disagree.)

Old screen readers, text-to-speech systems and text browsers like Lynx do not support rowspan and colspan. The result can be very confusing for users of these technologies. It's part of the responsibility of the developers of those user agents to provide good table support in their software, and to improve their UAAG conformity.

However, it might be appropriate to avoid using spanned cells when it doesn't cause any problems. Which means: if other users agree to avoid spanned cells, go ahead and remove them. If they don't, it would be best to respect their choice since avoiding spanned cells is not an accessibility requirement but a bonus.

As of September 2010, the most widely used assistive technologies do support these attributes. For example, JAWS has supported them since JAWS 6.0 (March 2005).

Example of table using spanned cells

Example from Zachary Bennett

Year	Title	Role	Notes
1989	Friday the 13th	J.B.	Episode: "A Friend to the End"
	Looking for Miracles	Sullivan Delaney	TV movies
1990	Back to Hannibal: The Return of Tom Sawyer and Huckleberry Finn	Marcus
	Lantern Hill	Jimmy-John Meade
	The Ray Bradbury Theater	Hank Walterson	Episode: "The Black Ferris"
	Road to Avonlea	Felix King	1990–1996 (91 episodes)

Result in assistive technologies that doesn't support spans

The exact result may vary depending on the assistive technologies used. But it will be similar to the following table:

Year	Title	Role	Notes
1989	Friday the 13th	J.B.	Episode: "A Friend to the End"
	Looking for Miracles	Sullivan Delaney	TV movies
1990	Back to Hannibal: The Return of Tom Sawyer and Huckleberry Finn	Marcus
	Lantern Hill	Jimmy-John Meade
	The Ray Bradbury Theater	Hank Walterson	Episode: "The Black Ferris"
	Road to Avonlea	Felix King	1990–1996 (91 episodes)

See User:RexxS/Accessibility for further examples.

Issues with sortable tables

Status: Complete. Needs to be reviewed by an accessibility expert.

This is only meant to provide information and should not be acted upon. Sortable tables should not be avoided because they are very useful. Trying to remove them would only lead to endless and unnecessary debates.

Templates like {{Sortname}}, {{Number table sorting}} and {{Sort}} generate hidden data in the table. That data contains sort keys hidden in every cell instead of standard metadata. It makes the cell's content unintelligible for users with CSS styles disabled or unavailable. See also this issue report.

Example of sortable table using {{Number table sorting}} template

Result shown with CSS enabled	Real content of the table cell shown when style="display:none" is not supported
47.15 €	7001471500000000000 47.15 €
7.15 €	7000715000000000000 7.15 €

References