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.

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.

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.^{[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

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

Good example of row headers

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."

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.

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.

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

• 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

• 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

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

Good example

With correct headers as well:

Providing a summary

• 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]}

{| summary="List of Television appearances and roles"
|+ Television
…

{| 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).

Avoiding rowspan/colspan

• 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

Example from Zachary Bennett

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:

See User:RexxS/Accessibility for further examples.

Issues with sortable tables

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.

WCAG references