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

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Guidelines on this page are not meant to be enforced, and only serves as a resource for members of the WikiProject Accessibility. Some guidelines may be used on a few pages when relevant, but they are not supposed to be widely used.

Usability guidelines[edit]

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[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 to make 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 Sales 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
  • 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[edit]

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 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[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
Country Purpose
Australia
Canada
Japan govt
corp. and pers.
New Zealand 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
Country Purpose
Australia
Canada
Japan govt
corp. and pers.
New Zealand 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.


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[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]

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:[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]

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)[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 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[edit]

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[edit]

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,[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]

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[edit]

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[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 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[edit]

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[edit]

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.[WCAG-TECH 3] 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 €


Footnotes[edit]

Notes[edit]


References[edit]

  1. ^ Tables of data, Identifying rows and column information, WCAG10-HTML-TECHS
  2. ^ Associating header information with data cells, W3C
  3. ^ Avoid Tables with More than Two Levels of Row or Column Headers, Creating Accessible Tables, 2. Data Tables, WebAiM
  4. ^ a b Avoid Spanned Rows or Columns, WebAIM
  5. ^ WebAIM's guidelines for summaries

WCAG references[edit]

  1. ^ Cite error: The named reference H63 was invoked but never defined (see the help page).
  2. ^ H73: Using the summary attribute of the table element to give an overview of data tables, A accessibility level.
  3. ^ G115: Using semantic elements to mark up structure, A accessibility level.