Manual of Style (MoS) | |||||||
---|---|---|---|---|---|---|---|
By topic area
|
|||||||
WikiProject Accessibility |
---|
Article guidelines
|
Template guidelines
|
For impaired users
|
This tutorial is a guideline which, as part of Wikipedia's Manual of Style, is intended to assist those creating data tables (or more often lists) in ensuring the content is accessible to all.
Guidelines on this page are ordered primarily by priority, then difficulty. The priority levels are determined by the Accessibility Success Criteria rankings A, AA, and AAA (in descending order of importance as accessibility considerations) of the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0.[WCAG 1] The difficulty indicates if it seems easy or not for Wikipedia users to comply to the guidelines.
Guidelines here essentially follow WCAG 2.0's approach, and some additional reputable sources, like WebAIM, when relevant. A review by an accessibility expert was necessary to ensure WCAG 2.0 was interpreted correctly; this review was made in September 2010.[note 1]
Overview of basics
- Priority: high (accessibility level: A)
- Difficulty: easy (the syntax is fairly simple and editors get used to it; the layout might changes users' habits)
{| class="wikitable" |+ [caption text] |- ! scope="col" | [column header 1] ! scope="col" | [column header 2] ! scope="col" | [column header 3] |- ! scope="row" | [row header 1] | [normal cell 1,2] || [normal cell 1,3] |- ! scope="row" | [row header 2] | [normal cell 2,2] || [normal cell 2,3] ... |}
which gives:
[column header 1] | [column header 2] | [column header 3] |
---|---|---|
[row header 1] | [normal cell 1,2] | [normal cell 1,3] |
[row header 2] | [normal cell 2,2] | [normal cell 2,3] |
- Caption (
|+
) - A caption is a table's title, describing its nature.[WCAG 2]
- Row and column headers (
!
) - Like the caption, these help present the information in a logical structure to visitors.[WCAG 3] The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request.[1]
- Scope of headers (
! scope="col" | and ! scope="row" |
) - This clearly identifies headers as either row headers or column headers[note 2] Headers can now be associated to corresponding cells.[WCAG 4]
Layout of table headers
As can be seen in the example above, row headers are formatted by default as bold, centred and with a darker background. This is the common behavior across the Internet, and the default rendering in most browsers. In some circumstances it might be desirable to apply a style customized for a specific case. The class plainrowheaders
will apply left-aligned and normal-weigh formatting so that editors do not feel the need to override the header formatting with inline CSS declarations for each cell.[note 3] Used by itself, plainrowheaders
will make headers appear similar to unmodified data cells, except for the darker background.
To use plainrowheaders
, place it (like wikitable
) in the class=
attribute at the beginning of the table. The example below shows custom row header style using a larger font instead of boldfacing:
{| class="wikitable plainrowheaders" ! scope="row" style="font-size: larger;" | [row header 1]
Proper table captions and summaries
Table markup provides for both captions and summaries, both of great utility for making tables accessible. The caption provides a descriptive heading for the table and the summary provides a "nutshell" of its content. If you like, you can think of them as analogous, respectively, to an journal paper's title and its abstract.
Caption
- Priority: high (accessibility level: A)
- Difficulty: easy (the syntax is fairly simple and already in use; the layout slightly changes users' habits)
A data table needs a table caption that succinctly describes what the table is about.[WCAG 2] It plays the role of a table heading, and is recommended as a best practice.[2] You would usually need some kind of heading or description introducing a new table anyway, and this is what the caption feature exists for. Table captions are made with |+
.[note 4] A caption can be styled with CSS, and may include wikilinks, reference citations, etc. It may be explicitly put to the left like other Wikipedia headings with style="text-align: left;"
(a good idea especially on wide tables). Captions are not used for layout tables (these are deprecated on Wikipedia as well as more broadly, but some editors temporarily resort to them until later editors wikicode whatever it was they were trying to achieve.)
A temporary case for not using the |+
caption is in certain situations when using a collapsible table. As of September 2010, the "[hide]" / "[show]" collapse control has to be inside a table header (until the collapsibility script is improved), and it must be large enough to contain it. If the table has no header, or only a very small header, a common solution has been to put the caption text in a table header to which the collapse controller may attach.[clarification needed]
Example of a proper caption from Tobin Bell#Filmography:
Title | Year | Role | Notes |
---|---|---|---|
Equalizer, TheThe Equalizer | 1988 | Episode: "The Day of the Covenant" | |
Perfect Witness | 1989 | Dillon | TV film |
Alien Nation | 1990 | Brian Knox | Episode: "Crossing the Line" |
Captions should be concise; if the table needs an extended introduction, provide one in normal article prose, then provide a simpler caption. However, table captions consisting of a single word like "Actor", "Film" or "Television" – as in a previous revision of Tobin Bell's filmography – are inadequate, as they are not descriptive enough.
Summary
- Priority: high (accessibility level: A)[under discussion]
- Difficulty: variable (the syntax is simple; summarizing table content ranges from easy to challenging, like writing an article lead or a plot synopsis)
A table summary provides an overview of the information in a table and its presentation, for the visually impaired (or for text-only browsers with no table-rendering feature).[WCAG 5] It does not normally display in graphical browsers. The summary does not simply repeat the caption and is not a substitute for it, but serves a similar purpose to descriptive alt
text for an image. A summary cannot be styled, wikilinked, or otherwise marked up, but must be simple, plain text. It cannot even include italics. A table summary is made with summary="Summary text here."
, on the same line as the {|
that opened the table,[note 4] along with any class=
and other parameters for the table as a whole. As with captions, the summary attribute is never used with layout tables.
For short, simple tables, a summary may not be necessary. For more complex tables, summaries should be used to explain how the data is organised.[3] They explain the data structure to inform navigation in a screen reader, especially to somewhat offset the accessibility problems associated with nested tables and with rowspan
and colspan
,[4] if these are used despite the accessibility problems they pose.
In cases where a caption is not used for some reason, it is recommended to begin the summary with what probably would have been the caption. A case to not do this is when what amounts to a table caption is put inside a table header at the top of the table, as documented above, for collapsible table purposes.
Wiki markup example showing left-aligned caption with a source citation, and a summary re-presenting the short table's data in plain text:
{| class="wikitable" summary="The first column indicates the year and the remaining four columns indicate the region." |+ style="text-align: left;" | Data reported for 2014–2015, by region<ref name="Garcia 2015" /> |- ! scope="col" | Year !! scope="col" | Africa !! scope="col" | Americas !! scope="col" | Asia & Pacific !! scope="col" | Europe |- ! scope="row" | 2014 | 2,300 || 8,950 || ''9,325'' || 4,200 |- ! scope="row" | 2015 | 2,725 || ''9,200'' || 8,850 || 4,775 |}
As it appears in a browser:
Year | Africa | Americas | Asia & Pacific | Europe |
---|---|---|---|---|
2014 | 2,300 | 8,950 | 9,325 | 4,200 |
2015 | 2,725 | 9,200 | 8,850 | 4,775 |
If this table presented ten years of data, a more appropriate summary might (depending on the nature of the data) be something like: summary="Data presented for four regions (columns), over ten years (rows). The highest numbers by year were: 2005 – Europe: 10,100. 2006 – Americas: 9,550. [...] See cited report for more details."
If it presented 25 years of data, something like the following might be more useful: summary="Data presented for four regions (columns), over 25 years (rows). The Asia & Pacific region had the highest numbers in 12 of these years with a peak of 11,775; the Americas had the highest in 10 years, peaking at [...] See cited report for more details.
. However, an in-depth explanation of the data in terms that included, e.g., the range of values for each year, the range for each region, the highest and lowest reported values in the data, trends over time, etc., would be an analysis that any readers could be interested in, and would be better presented as article text, with the table summary used to convey the table structure only.
Avoiding column headers in the middle of the table
- Priority: high (accessibility level: A)
- Difficulty: medium (requires large changes to tables, editors seem reluctant to split tables, needs more testing and feedback)
Do not place column headers in the middle of a table to visually separate the table. Assistive technologies will get confused as they cannot know which previous headers still apply to parts of the table after the first one.
For example, a screen reader reading the cell "Stuttgart, Germany" might associate the cell with the following headers: "Venue, Representing Soviet Union, Representing Belarus". Three headers are read aloud. The first and the third are correct and expected. But "Representing Soviet Union" does not apply to the lower half of the table, and a machine does not understand that. Thus, a machine will not be able to associate header and cells correctly, and will provide misleading information about the table structure to the user.
In most cases, the easier solution is to split the table into several sub-tables with explanatory sub-headings (first example).
Column headers: bad example
From Vasiliy Kaptyukh and produced by {{AchievementTable}}:
Year | Competition | Venue | Position | Notes |
---|---|---|---|---|
Representing ![]() |
||||
1985 | European Junior Championships | Cottbus, East Germany | 3rd | |
1986 | World Junior Championships | Athens, Greece | 3rd | |
1990 | European Championships | Split, Yugoslavia | 4th | 63.72 m |
Representing ![]() |
||||
1993 | World Championships | Stuttgart, Germany | 7th | 61.64 m |
1995 | World Championships | Gothenburg, Sweden | 3rd | 65.88 m |
IAAF Grand Prix Final | Monte Carlo, Monaco | 4th |
Other similar examples can be found at Yvonne van Gennip, Masters Athletics World Records and Comparison of layout engines (Cascading Style Sheets)#Selectors.
Column headers: good example
The first solution where the table is split in several sub-tables.
Year | Competition | Venue | Position | Notes |
---|---|---|---|---|
1985 | European Junior Championships | Cottbus, East Germany | 3rd | |
1986 | World Junior Championships | Athens, Greece | 3rd | |
1990 | European Championships | Split, Yugoslavia | 4th | 63.72 m |
Year | Competition | Venue | Position | Notes |
---|---|---|---|---|
1993 | World Championships | Stuttgart, Germany | 7th | 61.64 m |
1995 | World Championships | Gothenburg, Sweden | 3rd | 65.88 m |
IAAF Grand Prix Final | Monte Carlo, Monaco | 4th |
Column headers in sortable tables: bad example
Example of a complex sortable table from list of Hot 100 number-one singles of the 2000s (U.S.):
No. | Reached number one | Artist(s) | Single | Record label | Weeks at number one |
Ref |
---|---|---|---|---|---|---|
2000 | ||||||
851 | January 15, 2000 | Christina Aguilera | "What a Girl Wants" | RCA | 2 | [ref] |
852 | January 29, 2000 | Savage Garden | "I Knew I Loved You" | Columbia | 4 | [ref] |
853 | February 19, 2000 | Mariah Carey & Joe & 98 Degrees | "Thank God I Found You" | Columbia | 1 | [ref] |
2001 | ||||||
868 | February 3, 2001 | Shaggy & Ricardo 'Rikrok' Ducent | "It Wasn't Me" | MCA | 2 | [ref] |
869 | February 17, 2001 | Outkast | "Ms. Jackson" | Arista | 1 | [ref] |
870 | February 24, 2001 | Joe & Mystikal | "Stutter" | Jive | 4 | [ref] |
Column headers in sortable tables: good example
In cases of long sortable tables, splitting the table would reduce its utility as a sortable table. A solution is to move the year headers ("2000", 2001", ...) to a dedicated column at the front of the table and make them spanned rows. It is tricky to explain, so please refer to the example below.
In the example, the first cell in the row is spanned across several rows. This spanned cell contains the year of the single, which is not the main subject of the row. The main subject of the row is in fact the name of the single. Thus, the first cell in the row should be a normal data cell instead of a row header.
Year | No. | Reached number one | Artist(s) | Single | Record label | Weeks at number one |
Ref |
---|---|---|---|---|---|---|---|
2000 | 851 | January 15, 2000 | Christina Aguilera | "What a Girl Wants" | RCA | 2 | [ref] |
852 | January 29, 2000 | Savage Garden | "I Knew I Loved You" | Columbia | 4 | [ref] | |
853 | February 19, 2000 | Mariah Carey & Joe & 98 Degrees | "Thank God I Found You" | Columbia | 1 | [ref] | |
2001 | 868 | February 3, 2001 | Shaggy & Ricardo 'Rikrok' Ducent | "It Wasn't Me" | MCA | 2 | [ref] |
869 | February 17, 2001 | Outkast | "Ms. Jackson" | Arista | 1 | [ref] | |
870 | February 24, 2001 | Joe & Mystikal | "Stutter" | Jive | 4 | [ref] |
Images and color
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:
- 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
); - 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. Also, 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:
By Country | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Country | Purpose | J | F | M | A | M | J | J | A | S | O | N | D | J | F | M | A | M | J | J | A | S | O | N | D |
Australia | |||||||||||||||||||||||||
Canada |
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. 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.
Legend: cells marked with "x" are included in the fiscal year.
Fiscal years by country | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Country | Purpose | J | F | M | A | M | J | J | A | S | O | N | D | J | F | M | A | M | J | J | A | S | O | N | D |
Australia | x | x | x | x | x | x | x | x | x | x | x | x | |||||||||||||
Canada | x | x | x | x | x | x | x | x | x | x | x | x |
Fiscal years by country | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Country | Purpose | J | F | M | A | M | J | J | A | S | O | N | D | J | F | M | A | M | J | J | A | S | O | N | D |
Australia | 1st of July to 30th of June | ||||||||||||||||||||||||
Canada | 1st of April to 31st of March |
From Dwain Chambers (with improved table caption and structure; but the original use of color is good):
Competition | Year | Venue | Position | Event | Notes |
---|---|---|---|---|---|
European Championships | 1998 | Budapest, Hungary | 2nd | 100 metres | |
IAAF World Cup | Johannesburg, South Africa | 3rd | 100 metres | ||
Commonwealth Games | Kuala Lumpur, Malaysia | 1st | 4×100 metres relay | ||
European Cup | 1999 | Paris, France | 1st | 100 metres | |
IAAF World Championships | Seville, Spain | 3rd | 100 metres | ||
2nd | 4×100 metres relay |
Avoiding nested data tables
- Priority: high (accessibility level: A)
- Difficulty: unknown (not yet rated)
Nested tables are very confusing for screen reader users, as explained below. Thus, they should be avoided.
Visitors using screen readers and Braille displays can chug through pages one word after another or navigate from one “item” to another, where “items” are defined by HTML markup. The commands to move through the items on a page vary from system to system, but we will model this process as akin to pressing the Tab key.
You can tab to a table and tab within a table. And here is where the problem starts. For simple layout tables not nested within other tables, it is no problem to move from cell to cell. With nested tables, though, a screen-reader user ends up working from within a maze formed by one table inside another.
Where a sighted visitor would appreciate the net appearance of all the nested tables put together, a screen-reader user navigates the underlying structure. As you know from attempting to code nested tables, the structure is damnably difficult to figure out. Now try reverse-engineering that structure via speech output.
In effect, by using nested tables, you conscript blind visitors into debugging the coding of your page by audio alone.— Joe Clark, Tables and frames, joeclark.org[5]
Bad example of nested data tables
See inclusions of Template:CompactTable, in Basketball at the 2000 Summer Olympics for example.
Resources
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 (NVDA using the Crystal voice from NaturalSoft)
- Table using ID attribute (NVDA using the default eSpeak voice)
Footnotes
Notes
- ^ This page was reviewed by fr:User:Lgd, an accessibility expert from the French Wikipedia, in September 2010. Any other review by an expert is welcome, if someone has a concern about a guideline. For example, WebAIM experts can be contacted.
- ^ See HTML5 differences from HTML4, 3.6 Absent Attributes: "
scope
attribute ontd
" will be deprecated in HTML 5. To prepare for the change we should use solelyscope
attribute onth
. - ^ See the discussions at MediaWiki talk:Common.css some wikitable ideas and bold row headers.
- ^ a b Table captions can also be made with
<caption>Caption here</caption>
, and summaries with<table summary="Summary text here.">
, but wikisyntax should be preferred in articles. - ^ But avoid Unicode characters, per Wikipedia:Manual of Style (accessibility)#Text. See also Graham87's explanation in the context of a featured list candidate.
References
- ^ Table cells: The TH and TD elements, W3C
- ^ "Ensure table captions are provided explicitly". Accessibility Management Platform (AMP). San Francisco, California: SSB BART Group. 2015. "Best Practices" section. Retrieved 13 July 2015. GSA Schedule 70. Cites multiple standards besides WCAG, including: JIS X 8341-3: 2004 - Technical Standards Subpart 5; KWCAG; 47 CFR 14. Advanced Communication Services, §14.21 Performance Objectives; HHS HTML 508 Checklist; and US Telecommunications Act Accessibility Guidelines 1193.41–43.
- ^ Eggert, Eric; Abou-Zahra, Shadi (2 March 2015). "Caption & Summary". Web Accessibility Initiative. World Wide Web Consortium. Retrieved 14 July 2015.
- ^ "Provide summary attributes for tables when appropriate". Accessibility Management Platform. SSB Bart Group. 2015. "Best Practices" section. Retrieved 13 July 2015.
- ^ Tables and frames, joeclark.org. Note: this source is outdated, but the part concerning nested tables is still valid as of October 2010.
WCAG references
- ^ Web Accessibility Initiative (5 May 1999). Chisholm, Wendy; Slatin, John; White, Jason, eds. "Web Content Accessibility Guidelines 2.0". W3.org. Cambridge, Massachusetts: World Wide Web Consortium (W3C). Retrieved 11 December 2008. Confusingly, the WCAG 2.0's rankings A, AA (or Double-A), and AAA (Triple-A) are used for two different but interrelated concepts, the second of which may be counter-intuitive:
- The one used in this Wikipedia guideline – the relative importance of a particular "Success Criterion" at achieving accessibility, in which A is the most essential or impactful, and AAA represents less urgent accessibility allowances a site should make, with AA being of medium urgency. Each criterion is explained at a "How to Meet" link in the section in WCAG 2.0 for each of its accessibility recommendations, and collected at "How to Meet WCAG 2.0: A customizable quick reference"
- The compliance level of a website, with "A" representing the minimum level of conformance to the accessibility recommendations, and "AAA" being the most accessible, meeting all Level A, AA, and AAA Success Criteria. Thus, "Level AAA Compliance" means the opposite of "only compliant with Level AAA Success Criteria". Wikipedia naturally strives for Level AAA Compliance, prioritizing on proceeding from A to AA to AAA compliance to meet the most essential accessibility requirements the soonest, where practical.
The present system replaces the 1999 WCAG 1.0 system of Conformance Levels (also A, AA, and AAA) with a checklist of Priority 1, 2, and 3 recommendations; while those roughly correspond to the current A, AA, and AAA success levels, 2.0 has added many criteria that were not present in 1.0. See "How WCAG 2.0 Differs from WCAG 1.0"
- ^ a b "H39: Using caption elements to associate data table captions with data tables", accessibility level: A.
- ^ "H51: Using table markup to present tabular information"
- ^ "H63: Using the scope attribute to associate header cells and data cells in data tables", accessibility level: A
- ^ "H73: Using the summary attribute of the table element to give an overview of data tables"; provides details about and examples of table summaries; accessibility level: AAA (priority: 3).