Wikipedia:Manual of Style/Accessibility/Data tables tutorial/Internal guidelines
![]() | This is an explanatory essay about Wikipedia:Manual of Style/Accessibility. This page provides additional information about concepts in the page(s) it supplements. This page is not one of Wikipedia's policies or guidelines as it has not been thoroughly vetted by the community. |
WikiProject Accessibility |
---|
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
[edit]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
[edit]- 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.[WCAG-TECH 1] 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
[edit]From Wikipedia:WikiProject Discographies/style (date is used as a row instead of the album):
Year | Album details | Peak chart positions | Verkauf | Certifications | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
US | AUS | AUT | FIN | NLD | NZ | NOR | SWE | SWI | UK | ||||
1989 | Bleach | 89 | 34 | 26 | 24 | — | 30 | — | — | — | 33 | 1.7 million (US) | Platinum (US) |
1991 | Nevermind
|
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
[edit]Titel | Album details | Peak chart positions | Verkauf | Certifications | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
US | AUS | AUT | FIN | NLD | NZ | NOR | SWE | SWI | UK | ||||
Bleach | 89 | 34 | 26 | 24 | — | 30 | — | — | — | 33 | 1.7 million (US) | Platinum (US) | |
Nevermind |
|
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
[edit]- 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
[edit]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 | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Land | Purpose | ||||||||||||||||||||||||
Australien | |||||||||||||||||||||||||
Kanada | |||||||||||||||||||||||||
Japan | govt | ||||||||||||||||||||||||
corp. and pers. | |||||||||||||||||||||||||
Neuseeland | govt | ||||||||||||||||||||||||
corp. and pers. |
Good example of cell merge
[edit]"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 | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Land | Purpose | ||||||||||||||||||||||||
Australien | |||||||||||||||||||||||||
Kanada | |||||||||||||||||||||||||
Japan | govt | ||||||||||||||||||||||||
corp. and pers. | |||||||||||||||||||||||||
Neuseeland | govt | ||||||||||||||||||||||||
corp. and pers. |
Special case where wrong rowspans can hardly be avoided
[edit]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.
Des. | Extended comments | Maker | No. | Owner | Typ | Winding | Kommentare |
---|---|---|---|---|---|---|---|
H | Arnold & Dent | 261 | Fitz-Roy | one-day | Assessed by Fitz-Roy as "rather good" | ||
K | Parkinson & Frodsham | 1042 | Regierung | 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
[edit]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
[edit]- 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:[1]
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[2], 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
[edit]- 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)[3]. 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.[4]
Example from Chad Hedrick and Template:PersonalRecords. The contents of {{PersonalRecordsTop}} and {{PersonalRecordsSport}} should be merged in a table caption.
Bad example
[edit]Note that headers are only visual as they are made of cells and bold:
Personal records | ||||
Men's speed skating | ||||
Distance | Zeit | Date | Standort | Notes |
500 m | 35.52 | 2009-12-26 | Salt Lake City | |
1000 m | 1:07.33 | 2009-12-13 | Salt Lake City |
Good example
[edit]With correct headers as well:
Distance | Zeit | Date | Standort | 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
[edit]- 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,[5] 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.[WCAG-TECH 2]
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).
State & First | State & Sixth | State & Fifteenth | Fifteenth & Morrison |
---|---|---|---|
4:00 | 4:05 | 4:11 | 4:19 |
Avoiding rowspan/colspan
[edit]- Priority: bonus (this criterion is not part of any accessibility referential and has limited impact[4])
- 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
[edit]Example from Zachary Bennett
Year | Titel | 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
[edit]The exact result may vary depending on the assistive technologies used. But it will be similar to the following table:
Year | Titel | 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
[edit]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.[WCAG-TECH 3] It makes the cell's content unintelligible for users with CSS styles disabled or unavailable. See also this issue report.
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
[edit]- ^ Tables of data, Identifying rows and column information, WCAG10-HTML-TECHS
- ^ 4.9.10 The th element, W3C
- ^ Avoid Tables with More than Two Levels of Row or Column Headers, Creating Accessible Tables, 2. Data Tables, WebAiM
- ^ a b Avoid Spanned Rows or Columns, WebAIM
- ^ WebAIM's guidelines for summaries