Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial

Wrong for 11 years

This advice guide has been wrong since it was created in 2010 by Dodoïste. Dodoïste wrote the following:[1]

A data table needs a table caption that roughly describes what the the table is about. It is to a table what a section header is to a paragraph.

Dodoïste referred to an online style guide at W3.org titled H39: Using caption elements to associate data table captions with data tables. The W3 guide is concerned that a table may shift around in an HTML setting, and they are making sure that your table doesn't lose its context. The only accessibility concern was that the table might slip out from under the parts that give it context.

Here on Wikipedia, the context is almost always very clear. A table is always in an article with a unique title. The table is almost always in a section which has a section heading. So right there we have all the proper context; we do not have to repeat this information. For instance, the Vital Level-3 Featured Article Logarithm has a table listing four base counting methods. The table is in a section titled Particular bases. This is enough context for the reader to know that the table is about logarithm bases—we don't need a table caption repeating that information.

This guideline should make it clear that a "caption" for a table (really we are talking about a table header, not a caption) is an option for any time that the table context is unclear, for whatever reason. We should not be saying that it is required for accessibility. Binksternet (talk) 17:47, 18 September 2021 (UTC)

@Binksternet: Yes, but the problem is that screen readers identify tables by captions and sometimes determine whether a table is worth alerting a user to by the presence or absence of a caption. See Wikipedia talk:Manual of Style/Accessibility/Archive 15#RfC on table captions. TFor cases where it's highly undesirable for a sighted user to see the caption there's {{Screen reader-only}}. Graham87 07:10, 19 September 2021 (UTC)

Avoiding column headers in the middle of the table - outdated and incorrect

The section on Avoiding column headers in the middle of the table is outdated and has been for 10 years. I recall having a discussion on this 10 years ago when were were designing tables at Tennis project and asking those with screen readers to tell us if there were any issues. There were none. We did follow not putting in ! to start rows in the middle of tables and used | instead, but modern screen readers flew through both. A few years back we were also told that using the "scope" command makes using ! perfectly fine. Perhaps when this passage was written for wikipedia there were still those with Commodore 64s or Amigas with old archaic screen readers, but it's 2021 now and screen readers have no issues with it.

Do we need an rfc on changing this outdated advise? Multiple tables often look messier or adding an extra column turns into a bunch of redundant words, where a simple new row statement can take care of thing with a snap. If it looks better, and today's screen readers have no issues at all, then having statements such as "Assistive technologies will get confused as they cannot know which previous headers still apply to parts of the table after the first one," are false and a disservice to our readers. The whole section is not true (or perhaps I should word that as no longer true) and should be scrapped or reworded. Fyunck(click) (talk) 19:32, 22 September 2021 (UTC)

Please link to these discussions; I've tried to search for them. I did however find this discussion at the WikiProject's talk page, this thread on my talk page, and this thread on the WikiProject Tennis guidelines talk page. I don't know if a full RFC would be necessary but a notification on the main accessibility talk page would probably be helpful, since this section has an attached shortcut and all. For what it's worth the bad example in the tutorial is still problematic here with JAWS. Graham87 06:37, 23 September 2021 (UTC)

I can't speak for tables that use ! without using the scope command, since we tried to remove those from tennis project guidelines upon request. But here's what's interesting. Years ago, In our designing the table used in every tennis article we had readers that use JAWS climb up and down and sideways. I think you might have been one of the editors that helped us. There was another popular screen reader at the time whose name eludes me. We talked with accessibility over and over, and no issues were found. We had checked and doubled checked it. It uses the same principle but avoids using the ! to signify an actual header change. The bad examples on this article all use ! for headers in the middle of tables. If that's what it's trying to convey it should be more specific not to use !. And if an old screen reader has trouble using ! in the middle of a table, then why can we use ! with the scope command in the middle of a table like we do in the good example?. That should cause the same issues.

This came to the surface because someone said a screen reader might have trouble with this example here. Fyunck(click) (talk) 07:27, 23 September 2021 (UTC)

Row headers when table contains only two columns

This issue has bugged me for ages and I'd like some guidance, although I confess I'm not at all familiar with some of the terminology involved in table creation.

On a few album articles, I've seen editors reformatting a charts table so that, where previously the two columns (national chart/compiler; peak position) both appeared in what I'd describe as a shade of light grey or off-white, now the left-hand column is rendered with a dark grey background, just like the column headers. In my opinion, this treatment looks over the top and something of an eyesore, because – since the chart names take up far more width than a one-, two- or three-digit chart position – the vast majority of the table becomes a mass of heavy, dark grey.

As an example, the Rubber Soul article looked like this until recently; it now looks like this. I think the first example is perfectly clear and easy on the eye. Also, it's not as if tables such as reviewer ratings boxes get the same heavy treatment, eg at Rubber Soul again. And I see tables where there are several more rows (in which case, you'd think the row header aspect was far more important) but all are set with the lighter, off-white background: eg 2016 Olympics medal table, 2012 Olympics host city election. (In addition, I've come across pages like Help:Sorting where none of the examples have this treatment either.)

So my question is, is it possible/permissible to still set these two-column charts tables without the heavy background? I guess it's an issue to do with "plainrowheaders"(?), the term used by an editor to explain a similar change in another album article. They cited MOS:ACCESS, although I have to say I couldn't find any reference to plainrowheaders on that MOS page – which is why I've ended up here, in fact. Thanks, JG66 (talk) 01:57, 10 October 2021 (UTC)

A big problem is that blind people using screen readers can't really know just how annoying a grey background is. They can't see it.

Also, another problem is that some editors, especially some of those that camp out on this talk page, are trying to put scope tags on all header and column rows, even though almost no other websites do. Because other websites look at the actual Web Content Accessibility Guidelines at the source, and not as they are interpreted by some people on Wikipedia. --Timeshifter (talk) 02:48, 10 October 2021 (UTC)

Thank you for the speedy reply but ... um, I don't know if your opening paragraph is a dig at my complaint or ...? Sorry, could just be the way I'm reading it. I'm an optimist – I'll take it that it isn't a dig(!)

I fully appreciate the importance of accessibility to all. So I suppose the question is whether ensuring the best access for screen readers (via "wikitable sortable", "plainrowheaders"?) necessarily has to dictate how that process or code is visually rendered in a table. As mentioned, this approach hardly seems consistent – eg, how are screen readers coping with the two-column reviewer ratings box?

Again, I emphasise that I'm completely ignorant about table formatting. I'm sure that tests the patience of regulars here, but I would like to get to the bottom of it if possible. MOS:CHARTS says "The chart positions should be organized into one table, and the table should be formatted using class="wikitable sortable"." Well, that was already in place before the recent changes at one or two album articles I watch; it seems to have been the introduction of these plainrowheaders that creates the darker grey background. JG66 (talk) 03:25, 10 October 2021 (UTC)

JG66. No dig intended. I deleted my first answer. Here is my second answer. See:

H63: Using the scope attribute to associate header cells and data cells in data tables | Techniques for WCAG 2.0. It says:

"Note: For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope."

See: Tables Concepts • Tables • WAI Web Accessibility Tutorials. It says:

"Tables with one header for rows or columns: For tables with content that is easy to distinguish, mark up header cells with <th> and data cells with <td> elements."

But when you go to the fine print it says "For tables with unclear header directions, define the direction of each header by setting the scope attribute to col or row."

I think most tables on Wikipedia do not have unclear header directions. The column headers are on the top. The row headers are on the left.

H51: Using table markup to present tabular information | Techniques for WCAG 2.0. "Simple tables generally have only one level of headers for columns and/or one level of headers on the rows." Example 1 is definitive as far as I am concerned. There is no requirement for scopes on such simple tables.

I did some tests awhile back that confirmed this:

Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial#Comparing tables with and without scope=col and scope=row. Please ignore the heated tone of some of the discussion. I apologize for my part in the heated tone.

Getting to your questions. I don't see the need for designating row headers in the 2 column table examples you gave. Screen readers will read the column header for each data cell. It will be obvious to the user what the relationship is between the the 2 cells in each row, even without row headers. And scopes are total overkill in that example.

--Timeshifter (talk) 10:41, 10 December 2021 (UTC)

Thanks, Timeshifter. You've given me a fair bit of homework, and I can't promise I'll jump on it immediately ... As I've said, I'm hopeless with table terminology ("scope"?).

I'm all for ensuring good accessibility for screen readers, but I'm confused as to why a simple, two-column table has to be rendered in the current way. And/or: why it is that the screen-reader-friendly input needs to even register visually when one reads the page "normally". (Why do we need to see what that software handles differently?) As I've said, my concern is with the two-column tables for record charts. Not only is it so simple in presentation that one questions whether info in the left-hand column really is a row header, but the table ends up such an eyesore, because the darkened-out LH column is usually far wider than the RH column, which contains just a single or double digit.

Anyway, don't feel the need to reply to that. I obviously need to do some reading. JG66 (talk) 15:57, 10 December 2021 (UTC)

JG66. I agree. I don't see the need for the gray background of the row headers. Or the bold font. It is obvious what are row headers in most tables when the row headers are on the left side of the table. And screen readers only need the scopes or <th>.

I think a gray background with black text is not enough contrast. Especially when the gray is too dark as in Wikipedia tables. And I keep my monitor brightness turned down. As recommended by many eye doctors. That makes the contrast even less.

It is annoying. So it would be nice to have truly plain row headers with a white background and a regular (non-bold) font. Then people would be more likely to add scopes for row headers. At least for more complex tables. Scopes are not needed on simple tables. --Timeshifter (talk) 02:25, 11 December 2021 (UTC)

Rowgroups and plainrowheaders

Hi, currently in the `Complex tables` section (but not in any section previous), it is recommended to use scope=rowgroup for row headers that are part of a rowspan. I was going to add this to my accessibility reviews at WP:FLC, but quickly found out that the 'plainrowheaders' table class doesn't seem to affect scope=rowgroup cells, only scope=row. Is this a known issue? For example:

Awards and nominations received by Anne Hathaway

Organizations	Year	Recipient(s)	Category	Result
Academy Awards	2009	Rachel Getting Married	Best Actress	Nominated
	2013	Les Misérables	Best Supporting Actress	Won
Alliance of Women Film Journalists	2009	Rachel Getting Married	Best Ensemble Cast	Won

plainrowheaders is affecting the second non-spanned row but not the first, spanned row. --PresN 15:10, 20 March 2022 (UTC)

@PresN: I created an issue for it here: MediaWiki talk:Common.css#Plainrowheaders row and rowgroup scopes. Jroberson108 (talk) 21:25, 20 March 2022 (UTC)

@Jroberson108: Thanks! --PresN 22:24, 20 March 2022 (UTC)

This is now fixed. --PresN 17:56, 22 March 2022 (UTC)

Row with blank data

I created a table, which has became the subject of an edit war between admins and an anon editor. The table is as below (prior to the edit war):

List of special service brigades

Formation name	Date formed	Wartime date ceased to exist	Location(s) served	Notable campaign(s)	Notes	Source(s)
1st Special Service Brigade	November 1943	N/A	Italy, UK, France, Belgium, Netherlands, Germany	Allied invasion of Sicily, Normandy, Allied advance from Paris to the Rhine, Western Allied invasion of Germany	Redesignated as 1 Commando Brigade, on 6 December 1944.	Source info here

The following is the edit that is made, which has been reverted.

List of special service brigades

Formation name	Date formed	Wartime date ceased to exist	Location(s) served	Notable campaign(s)	Notes	Source(s)
1st Special Service Brigade	November 1943	—	Italy, UK, France, Belgium, Netherlands, Germany	Allied invasion of Sicily, Normandy, Allied advance from Paris to the Rhine, Western Allied invasion of Germany	Redesignated as 1 Commando Brigade, on 6 December 1944.	Source info here

Does the template {{N/A}} conform to the MOS for a table such as this? Should it be used or not?EnigmaMcmxc (talk) 11:55, 8 July 2022 (UTC)

@EnigmaMcmxc: I couldn't find any recommended styles for empty cells. Maybe someone else might find something? I found a similar unanswered question here: Wikipedia talk:Manual of Style/Tables#Empty cells. If the intention is to indicate that the data wasn't overlooked as a blank cell might suggest, then using either one seems sufficient to me. Template:N/a, which displays an em dash, is used on approximately 47,000 pages, so in a way you could say it is an acceptable option. I don't know the number of "N/A" uses, but N/A indicates that it is a "common abbreviation in tables". Using one over the other seems more like a preference since to me they both indicate the same thing. Regardless of which one is used, it should match the same usage in other tables found on the same page and follow consensus.

Just to see what other manuals of style suggest, I searched and found the Chicago Manual of Style suggested using an em dash, ellipsis, n/a, or n.d. with some rules around the latter two abbreviations (see [2]). Note, the Chicago MoS doesn't dictate Wikipedia's MoS.

Section 3.65: Empty cells. If a column head does not apply to one of the entries in the stub, the cell should either be left blank or, better, filled in by an em dash or three unspaced ellipsis dots. If a distinction is needed between "not applicable" and "no data available," a blank cell may be used for the former and an em dash or ellipsis dots for "no data" ... If this distinction is not clear from the text, a note may be added to the table. (Alternatively, the abbreviations n/a and n.d. may be used, with definitions given in a note.) A zero means literally that the quantity in a cell is zero.... Jroberson108 (talk) 13:46, 8 July 2022 (UTC)

As an added note, the "N/a" template uses the "data-sort-value" attribute, so sorting it versus the "N/A" text may order them differently unless the same attribute is used on the text version. Jroberson108 (talk) 14:14, 8 July 2022 (UTC)

Does this violate accessibility guidelines?

Recently, I edited List of feature films with gay characters to change the chart from a format where all the countries are bunched together into one column, as the below example shows:

Year	Title	Character(s)	Actor	Notes	Country	Ref(s)
1968	The Mercenary	Ricciolo (Curly)	Jack Palance		Italy, Spain, United States

I changed it to this:

Year	Title	Character(s)	Actor	Notes	Country	Ref(s)
1968	The Mercenary	Ricciolo (Curly)	Jack Palance		Italy
					Spain
					United States

One user reverted this, saying "Do not add rows just for countries. Don't muck up the list and its formatting. Don't make the table more complicated for editors to edit" while I said that "putting all the countries into one row makes the chart inaccessible... and I'd argue it violates WP:ACCESSIBILITY. And it doesn't add too much complexity and it can be easily followed". Instead of changing anymore of the page, I decided to post here. If this isn't the right place, then I'd be glad to post this somewhere else instead. Is the change I did in line with MOS for a table such as this? Should it be used? Historyday01 (talk) 19:50, 8 July 2022 (UTC)

@Historyday01: Both are accessible, but the second one is more complex for the screen reader to read making it more difficult to understand, so simpler table structures are always preferred. In addition, the simpler comma delimited list better follows MOS:NO-TABLES recommendations when comparing a comma list to cells. Jroberson108 (talk) 20:29, 8 July 2022 (UTC)

Hmm. That makes sense. I will admit that I've done the second option more than the first as I believed that using the commas would mess up the "country" category. But, I'm totally ok with a simpler table anyhow, as it makes it easier to edit. Historyday01 (talk) 21:38, 8 July 2022 (UTC)