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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
WikiProject iconAccessibility
WikiProject iconThis page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.AccessibilityWikipedia:WikiProject AccessibilityTemplate:WikiProject AccessibilityAccessibility articles

Rowgroups and plainrowheaders[edit]

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

@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)[reply]
@Jroberson108: Thanks! --PresN 22:24, 20 March 2022 (UTC)[reply]
This is now fixed. --PresN 17:56, 22 March 2022 (UTC)[reply]

Row with blank data[edit]

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

@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 [1]). 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)[reply]
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)[reply]
Thank you for the in-depth response on this. I played around with the table, although it is very limited, and both seem to sort in the same manner. I guess with the widespread use of the template and outside style manuals saying that is more preferable, I think I can end the edit war with using that template.EnigmaMcmxc (talk) 17:25, 9 July 2022 (UTC)[reply]

Does this violate accessibility guidelines?[edit]

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

I changed it to this:

Year Title Character(s) Actor Notes Country Ref(s)
1968 The Mercenary Ricciolo (Curly) Jack Palance Italy [1][2]
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)[reply]

@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)[reply]
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)[reply]

References

  1. ^ a b Ridley, Jim (8 December 2012). "The Mercenary, Locked and Loaded Two Nights Only". Nashville Scene.
  2. ^ a b Bell, Nicholas (7 November 2017). "The Mercenary (1968) | Blu-ray Review". Ioncinema.com.

MOS:COLHEAD potential workaround?[edit]

Can MOS:COLHEAD violation in this case be worked around by adding "id=colX is empty. In row13 you can found...." or a hidden comment with a similar message to indicate to screen readers that more content can be found in the next row instead of rearranging the rows? Qwerty284651 (talk) 23:55, 2 June 2024 (UTC)[reply]

That whole table is messed up so trying to workaround one bad part of it, won't really "fix" it. Look at the "Career statistics" section, 5 of the 9 rows have cell content unrelated to the column headers. Separate the tables, make better column headers, remove bad usage of bold. Not everything needs to be in one giant table. Gonnym (talk) 06:30, 3 June 2024 (UTC)[reply]
@Gonnym, I proposed an improved version (pinging those involved in creating the new design @Fyunck(click) and Unnamelessness:) which passes MOS:COLHEAD in my project's community, but people are used to one design, prevalent in 100s of tennis BLPs. The new look meets accessibility criteria WCAG for screen reader users but offsets the sighted who are used to the old design...a balancing act.
Maybe remove the rows and replace them with {{notes}} or {{efn}}? Qwerty284651 (talk) 16:42, 3 June 2024 (UTC)[reply]
Yeah, not surprised. There are some places I'll never touch just because I don't want to deal with that type of editors. Gonnym (talk) 16:48, 3 June 2024 (UTC)[reply]
@Gonnym, I get you. I am going to make a push in favor of the visually impaired. Hopefully, it sticks. The minority needs to be tended to as well not just the ones blessed with the gift to see. Qwerty284651 (talk) 16:54, 3 June 2024 (UTC)[reply]
That is something I originally proposed, but you know, some kinds of compromise have to take as this is Wikipedia. :) Unnamelessness (talk) 06:08, 4 June 2024 (UTC)[reply]
I know. It is the bitter sweet truth. You can't please everybody. Qwerty284651 (talk) 10:21, 4 June 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Accessibility/Data_tables_tutorial&oldid=1227444682"