Jump to content

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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Manual of Style | Accessibility
This is an old revision of this page, as edited by Timeshifter (talk | contribs) at 06:44, 7 January 2022 (→top: Archiving format). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
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

Question

Should a wikitable include a "caption" if its just a copy and paste of the article's name? I thought the caption should be descriptive. But just copying and pasting the article's name to the table as a caption is in my opinion, redundant. For example, in this article [1] - the editor added a caption to the table which is the exact name of the itself.TheHotwiki (talk) 02:09, 25 April 2020 (UTC)[reply]

Hotwiki, What would be a better caption for this table? ―Justin (koavf)❤T☮C☺M☯ 02:12, 25 April 2020 (UTC)[reply]
Well that table does not need a caption, well not the "caption" you added which is just the name of the article. You are just repeating the title of the article. I read the guidelines regarding captions. It clearly states "descriptive". Copy and pasting the name of the article isn't.TheHotwiki (talk) 02:18, 25 April 2020 (UTC)[reply]
Per MOS:TABLECAPTION, it states: A data table needs a table caption that succinctly describes what the tables about. While I see the pros and cons of including/not including, I have to also believe that MOS:ACCESSIBILITY for the visually impaired needs to be considered in this. And since the MoS — which we need to follow — calls for a caption that is "succinct," which means it should be brief and concise, I don't see the need for drawn out caption. Visually impaired users benefit from these captions, no matter how redundant or unimportant they may appear to those of us who may not require them, or how repetitive of the page and/or section they belong to. livelikemusic talk! 02:25, 25 April 2020 (UTC)[reply]
Hotwiki, That doesn't answer my question. See also many, many articles that include tables from other articles, which you know exist: e.g. List of The Real Housewives of Cheshire episodes. The table captions for individual tables do not repeat the title of that article. The function of table captions is not the same semantically as the H1 header of a document on the Web, so again, I'm asking: what would be a better caption for this table? Since we have established that data tables need captions (or at least for the purposes of this conversation, assume that they do), I would be very interested in any feedback you can give me on improving cwithout just repeating the kaptions and accessibility on this site. ―Justin (koavf)❤T☮C☺M☯ 02:43, 25 April 2020 (UTC)[reply]
A related question, i've been using article subheadings as the titles for tables ===== table name ===== is that bad? should i switch to "|+table name" within the table?
I use subheadings because it means that table can be opened for editing by itself, without having to have surrounding material in the edit window.
Is there a way to do both - be screen-reader-friendly and allow the table to be edited by itself without opening too much other stuff - without just repeating the heading?
Irtapil (talk) 10:33, 8 May 2020 (UTC)[reply]
Irtapil, Hi, I just saw your question: you certainly make the heading and the caption different and there may be very good reasons to do this. You may also want to consider if a given section can or should have more information than purely the table itself. I personally don't prefer it but you can also use {{sronly}}. ―Justin (koavf)❤T☮C☺M☯ 21:30, 28 May 2020 (UTC)[reply]

is this an accessible use for a table?

This is from something i'm working on in my sandbox, i'm not sure whether this is classed as the "using tables for layout" thing that is discouraged? My reasons for doing it are related to "layout", but for the purpose of also readability. This is what i'm trying to do and some things i'm finding tricky:
what i'm trying to do
  • I want the English text, Urdu text, and image (i've not made the images yet, the neon images below are just placeholders) to be clearly associated with each other, without the reader needing to follow hyperlinks or scrolling up and down (it already links to another table, providing some extra detail).
  • I want the Urdu text in column 2 to be enlarged so readers who are unfamiliar with it can clearly see the detail. If i have that outside of a table, it will be confusing, it will look like a major heading in the wrong language for en.wiki? or it will take up a lot of vertical space and disrupt the flow of the article?
difficulties and complications
  • Putting right-to-left text and left to right text at opposite ends of the same line can cause some confusing and unpredictable effects when editing.
  • Putting images next to text often doesn't work very well? The text and image can end up a long way apart depending on screen size and zoom? I could do the text as image captions, but that's probably even less accessible than a table?
So, is a table a sufficiently accessible way to present this info, and if not, what's a better way to do what i'm trying to do?
Irtapil (talk) 09:44, 8 May 2020 (UTC)[reply]
illustration illustrated text note

نستعلیق
^ Nastaliq: This may not display as Nastaliq style, depending on which fonts you have installed on your device. [end note]
ں ◌٘ ھ ڑ ے ^ Start forms vs staring words: No Urdu word begins with ے , ھ , ڑ , or ◌٘ / ں but some of these forms appear following a non-joining letter ا و د ڈ ذ ر ڑ ز ژ in the middle of a word.
ے ^ Baṛī ye: "greater yē" (بڑی يے) is used only at the end of a word.
ک گ ^ Kaf and Gaf before tall letters: Simpler fonts, including early fonts developed for Arabic, usually have just two or three forms of each letter. But in Urdu's usual Nastaliq script, letters can have more than three position forms depending on which letters they are attached to. This is sometimes simplified by digital fonts - even modern Urdu Nastaliq fonts - which do not perfectly replicate the nuance of handwriting, but in the case of Gāf and Kāf it is prominent.

لا   لا

^ Lam Alef ligature: Lam ل followed by Alif ا forms a specific ligature لا in most Arabic writing styles but this is less dramatic in Urdu Nastaliq script.
Irtapil (talk) 10:22, 8 May 2020 (UTC)[reply]
Irtapil, This seems very sensible and intelligible to me. Make sure that you use scope="col"}, scope="row", and a caption on your table. Additionally, ensure that there is enough contrast on the images: it seems like the blue-on-blue may not be enough to be visible. ―Justin (koavf)❤T☮C☺M☯ 03:43, 27 May 2020 (UTC)[reply]
Thank you, Koavf.
How do  scope="row"  and  scope="col"  help? i don't think i have ever seen them used.
By caption do you mean the "|+" heading? Can you think of a way to do that without is looking to redundant if the table also has an indexed  "===headding==="  title?
Irtapil (talk) 09:54, 27 May 2020 (UTC)[reply]
Irtapil, No problem. Here is more about scopes: Help:Table#Scope and yes, the caption is |+Caption for the table. All data tables need captions: even if the words are literally the exact same as a heading, they are not redundant, as they serve different purposes and can appear in different contexts. ―Justin (koavf)❤T☮C☺M☯ 10:04, 27 May 2020 (UTC)[reply]
Koavf, i mean when the whole section is a table and it ends up like this:
additional letters in other languages
additional letters in other languages
Header text Header text
table body cell one table body cell two
table body cell three table body cell four
or unformatted:
=== additional letters in other languages ===
{| class="wikitable"
|+ additional letters in other languages
Irtapil (talk) 15:59, 27 May 2020 (UTC)[reply]
Irtapil, If it's really necessary, then that's okay: captions have to exist on data tables. You may consider deleting the section heading or combining sections or expanding a section to include more than just a table, etc. ―Justin (koavf)❤T☮C☺M☯ 18:29, 27 May 2020 (UTC)[reply]
Thanks @Koavf: I guess i could have "table of (section header)" for the table, but that still looks odd. Can you think of a rephrasing or re-framing strategy which might be a bit more informative than "table of..."? what have you seen that works well? (Then I can apply it to any other un-captioned tables i find too.)
Is "table" sufficient as a caption? i've been assuming not, but i'm not really sure how it works, so i realised i should check that assumption.
Would it work to make an invisible caption e.g. in transparent text? or would that cause problems?
Or is there a way that's specifically designed to attach an audio description caption to a table which doesn't show for readers who don't need it, like for an image?
One main reason i make the table header a section beading is so i can edit it without opening up anything else, but i guess i could just add a header when editing and remove it after if necessary, i should add an {{in use}} notice for big edits anyway.
Irtapil (talk) 05:26, 30 May 2020 (UTC)[reply]
Irtapil, A table caption shouldn't say "Table of..." really. It should just say what this table is about. Just ask yourself: "Hey, Irtapil, what am I about to be seeing here?" or "If someone couldn't access the table, what would he be missing out on?" and come up with a succinct way to say it. That could be "Vowels in Hassaniya Arabic" or "Studio albums by R.E.M." or "Award nominations for Kathryn Hahn". "Table" would not be a sufficient caption anymore than "Alt text" would be sufficient alt text. I personally don't like invisible captions but I provided a link to {{sronly}} elsewhere in this page which does just that. ―Justin (koavf)❤T☮C☺M☯ 05:31, 30 May 2020 (UTC)[reply]

color oracle

I added a second colour selection tool, Color Oracle, a "free color blindness simulator for Windows, Mac and Linux". It also has a greyscale option which might work for choosing printer-friendly colours. I've been using it for years and it's very user friendly. It seems to be much simpler than the recommended tool. I think we should keep both, unless the one i added gives misleading results? Irtapil (talk) 02:18, 9 May 2020 (UTC)[reply]


audio description

I didn't spot this on the page, but if it exists, it would be good to include.
Is there a way to put a custom audio description on a cell? if what is shown there is a symbol or a lot of abbreviations that a screen-reader is likely to not recite very intelligibly?
e.g. If there's a table where a person interpreting it visually would need to check back and forward with a legend or key, or interpret slightly abstract symbols, because a text version would be too big to display.
For example in these tables below modified from the guide page. I imagine the one i called "words version" is better than the one i called "ticks version"? but if whatever the words would say doesn't feasibly fit for visual displays, is it possible to display the "ticks version" but have a screen reader read out the words version?
ticks version
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 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
words version
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
Irtapil (talk) 15:24, 11 May 2020 (UTC)[reply]
Irtapil, "Is there a way to put a custom audio description on a cell?" Yes. Instead of using the Unicode character <✓>, you could use a template that inserts an image and add alt text to it. E.g. {{dagger|alt=Yes}} or somesuch. ―Justin (koavf)❤T☮C☺M☯ 04:38, 27 May 2020 (UTC)[reply]
thank you, Koavf. Is there a way to make it say something other than the default for the character? Or apply it to an abbreviation in standard English letters? e.g. the text in the cell shows "Aus" but the audio description says "Australia"? Irtapil (talk) 10:01, 27 May 2020 (UTC)[reply]
Irtapil, Oh wow, good question. If you use {{abbr}}, then a screen reader will read audio of the expanded abbreviation. So {{Abbr|Aus.|Australia}} would be read as "Australia" or "A-U-S for Australia" or something. To be clear, the example I gave before of {{dagger|alt=Yes}} would have the screen reader say, "Yes" when it got to the decorative image. If the code were {{dagger|alt=Irtapil is cool}} then it would read "Irtapil is cool" (or at least, it would try to, since "irtapil" isn't going to be in its dictionary...) ―Justin (koavf)❤T☮C☺M☯ 10:06, 27 May 2020 (UTC)[reply]
Re abbr, a screen reader would usually only read the expanded version if told to (and the user has to know to do that). But honestly that's generally not a big issue. Graham87 16:39, 27 May 2020 (UTC)[reply]
Graham87, Brilliant. Good to know--it's been ages since I've used a screen reader. This reminds me to actually do that and to look at some of this with Lynx to see how it displays. If you have any suggestions on what I can do to make things more accessible and to help fix common problems that you encounter interacting with the site, please let me know. ―Justin (koavf)❤T☮C☺M☯ 21:33, 28 May 2020 (UTC)[reply]

Row headers versus data cells in the first column of a simple table

@Graham87: Please see past discussion from April:

That discussion refers to this sandbox:

I copied that sandbox to here:

It is the same as User:Timeshifter/Sandbox103 except that all row header cells were changed to data cells.

I have the same question as before: As a screen reader user can you check out the example tables on that new user sandbox page, and tell me if the basic table at the end without scope=col and scope=row is a problem?

Also, what difference, if any, does it make that the cells in the first column of the tables are data cells instead of row header cells. --Timeshifter (talk) 14:09, 13 August 2020 (UTC)[reply]

@Timeshifter: There are no problems with those tables, and having the row headers replaced with data cells makes no difference. Graham87 14:40, 13 August 2020 (UTC)[reply]
@Graham87: Thanks again! --Timeshifter (talk) 15:37, 13 August 2020 (UTC)[reply]

@Graham87: Most tables on Wikipedia are simple ones like the ones in the 2 sandboxes. The tables have a row of column headers, and sometimes a first column with row headers.

Are most users of screen readers able to understand those tables without scope=row and scope=column? The reason I ask is because of this: H63: Using the scope attribute to associate header cells and data cells in data tables | Techniques for WCAG 2.0. It is from the Web Content Accessibility Guidelines of the World Wide Web Consortium (W3C). It states: "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."

I looked at the screen readers article. It seems there are more and more screen readers. Including some free and open source ones. --Timeshifter (talk) 19:45, 13 August 2020 (UTC)[reply]

Look at your Sandbox111. Of course JAWS reads it the same as your Sandbox103 because JAWS takes notice of the scope="row" in the second cell of each row. That's precisely why we tell editors to use scope. It would not have the same result if you had a table without scope or header markup, because it would then pick the first cell in the row as the row header.
In addition, your Sandbox111 is invalid html5. In html5, data cells no longer support the scope attribute, so you can no longer write | scope="row | Cell contents. The fact that JAWS tolerates invalid html is beside the point. We don't write invalid html here.
Finally, we don't give different advice to editors depending on different configurations of the table. That allows them to produce 100% accessible tables without guesswork. --RexxS (talk) 00:06, 14 August 2020 (UTC)[reply]
Indeed; I'm by no means an HTML expert. Graham87 04:02, 14 August 2020 (UTC)[reply]
Please see the new talk section. I corrected my errors and created another sandbox. --Timeshifter (talk) 07:53, 14 August 2020 (UTC)[reply]

Comparing tables with and without scope=col and scope=row

@Graham87: Let's start over. I had forgotten the row number column on some of the tables in previous sandboxes. Please see User:Timeshifter/Sandbox112. In this sandbox I have corrected my error, and now all the tables have the row number column. I also added a 4th table at the bottom without row headers and without scope.

As a screen reader user can you check out the example tables on that new user sandbox page, and tell me if the 2 tables at the end without scope=col and scope=row are a problem? --Timeshifter (talk) 07:52, 14 August 2020 (UTC)[reply]

Nope, they're not a problem either. But this is not a reason to make guidelines more complicated. Graham87 08:08, 14 August 2020 (UTC)[reply]

Wikipedia article table. With and without scope and rowheaders

@Graham87: Please see User:Timeshifter/Sandbox113. It is a table excerpt from an article I created: COVID-19 pandemic death rates by country.

As a screen reader user can you check out the 3 tables in that sandbox, and tell me if the 2 tables at the end without scope=col and scope=row are a problem? --Timeshifter (talk) 08:41, 14 August 2020 (UTC)[reply]

They're fine on the *latest* versions of screen readers (which people may or may not have for various reasons), but not per the Manual of Style, which is even more important here. Please do not ask me about these ever again unless consensus changes that scope tags are not allowed in the Manual of Style. Graham87 08:54, 14 August 2020 (UTC)[reply]
@Graham87: People do not add scope tags to nearly all tables on Wikipedia. I have been an editor of Wikipedia since 2005. I have long edited Help:Table, Help:Sorting, and other guides for tables. RexxS is the first person in a long time that I can remember pushing for scope tags. Now I see why. No one really sees a use for them. So the Manual of Style is ignored.
Editors are volunteers. Adding scope tags is a lot of extra work. So many tables are minimally edited. Many tables are regularly updated. Many country lists for example. None of the tools for rapid updates add scope tags. And I have yet to see a single example of why anybody should care. I am trying to go through all the table types in order to find out which ones really need scope tags. Then I can emphasize those table types in the help pages. Otherwise the general admonitions to always add scope tags will be the only guidance on those help pages. And they will continue to be ignored.
So I next want to test tables with multi-row headers with you. Here is the current guidance for complex tables with multi-row headers:
https://www.w3.org/WAI/tutorials/tables/irregular
So if a real need is found for scope tags for complex column headers, then that is not a problem. It is not difficult to add scope tags to column headers. Updates of long country lists often use the same wikitext for the headers. The update is pasted below it. So the scope tag work is done only once in that case.
But adding scope tags to row headers, especially complex ones, is a lot more work, and will be ignored unless a genuine reason is found for volunteer editors to do the extra work. Even then it probably won't be done if it has to be re-added for each update.
--Timeshifter (talk) 09:45, 14 August 2020 (UTC)[reply]
@Timeshifter: I just got this message because After-the fact pings don't work. And I'm still not going to do any mor testing for you. Various parts of the Manual of Style are hard to do or ignored by most editors. That's what we have WikiGnomes for. Graham87 14:40, 14 August 2020 (UTC)[reply]
@Graham87: Wow. Is there something I wrote that personally offended you? Most tables I see don't get any WikiGnomes helping add scope tags. I actually want to help with the tables that need it most. I guess I will find another user of screen readers to do tests, and who appreciates the help. --Timeshifter (talk) 15:39, 14 August 2020 (UTC)[reply]
@Timeshifter: It's not anything you *said*, but what you *did* ... ask me for my opinion on random tables without giving me any context about the other relevant discussions you were having about this issue. Admittedly I hadn't read the archived discussion you linked above properly, but still, what you've been doing is very underhanded. You're also annoying the heck out of RexxS, one of the most patient people re accessibility on this project ... see his last message at Help talk:Table#Web Content Accessibility Guidelines and scope. I suggest you just drop the stick. Graham87 16:17, 14 August 2020 (UTC)[reply]
There was nothing underhanded about asking a screen reader user, you, what they were seeing. Calling me underhanded for doing that is a personal insult. And it is common scientific procedure not to bias a scientific experiment ahead of time by providing reasons for you not to give an honest opinion. I see I was correct, because you and RexxS go back a long time.
Like I said at Help talk:Table#Web Content Accessibility Guidelines and scope you guys can put whatever MOS info you want in Help:Table. You can censor any WCAG info you want that contradicts it. You can put all kinds of admonitions and warnings on Help:Table about the all-powerful MOS. See how far it gets you. There are many recommendations at Help:Table that are routinely ignored by volunteer editors. This will be just one more. Because it requires extra work. And editors are volunteers. I want to give those volunteers reasons to add scope tags where they are needed most; complex tables. Because volunteers work out of logic and caring, not demands from people like RexxS. --Timeshifter (talk) 16:41, 14 August 2020 (UTC)[reply]
Just take a look at the 3,656 featured lists to see how comically wrong you are. Volunteers care about ensuring tables are accessible, but don't want to have work out whether a table will screen-read the same without scopes or not. Following the simple advice to add row headers and scopes gives them the assurance that the table will be accessible regardless of future changes to its content or the age of the screen reader being used. --RexxS (talk) 16:58, 14 August 2020 (UTC)[reply]
That's a very small number of tables. There are probably hundreds of thousands of tables in Wikipedia. --Timeshifter (talk) 17:38, 14 August 2020 (UTC)[reply]
And all of the ones that are rated as the highest quality are properly marked up with headers and scopes. --RexxS (talk) 21:49, 14 August 2020 (UTC)[reply]
@Timeshifter: Most editors don't add scope tags because they make no visual difference to tables in themselves, since their value is for screen reader users. Nevertheless, once it is pointed out to editors that they can improve the experience for readers using assistive technology by following the simple advice at MOS:DTT, they almost invariably adopt the guidance. The Featured List project requires tables to meet that guidance, and numerous WikiProjects, such as you can find at Wikipedia:WikiProject Discographies/style, incorporate them into all of their examples.
Improving accessibility on Wikipedia is not a quick process and it's something that a number of us have been working on for more than ten years. As you have observed, there is still a lot of room for progress to be made, and it is particularly frustrating to see you attempt to undermine that work by needlessly complicating advice, purely because you use an external tool to create wiki-tables that don't comply with it. --RexxS (talk) 16:44, 14 August 2020 (UTC)[reply]
I am not trying to undermine it, and I am trying to focus on where scope tags are needed the most. There are very few tools that are useful for fast table updates. And there are many tables that are not updated because people don't even know about those fast tools. You will need to talk to those tool creators. They are volunteers like me. Good luck trying to get them to do anything with your rude imperious methodology. --Timeshifter (talk) 17:38, 14 August 2020 (UTC)[reply]
That's simply untrue. You want quick shortcuts that produce low quality, potentially poorly accessible content. I don't. I'm prepared to fix the messes you make because it improves the encyclopedia. The tool makers are actually not volunteers like you: they are volunteers who know what they are talking about. --RexxS (talk) 21:49, 14 August 2020 (UTC)[reply]
Somewhat related, I tried finding the page that is responsible for the table creation from the drop-down toolbar, but couldn't find it. It would be helpful if that table came with the scopes already. --Gonnym (talk) 16:56, 14 August 2020 (UTC)[reply]
@Gonnym: See phab:T252350 for a related patch for the table caption. The code is part of mediawiki/extensions/WikiEditor and the change for the caption code is documented at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiEditor/+/595495/ --RexxS (talk) 17:09, 14 August 2020 (UTC)[reply]

Scope tags really shouldn't be obligatory. It make it harder to read the black text with a dark grey font.--Aréat (talk) 00:40, 15 August 2020 (UTC)[reply]

@Aréat: I don't think adding scope attributes makes any difference to the visual presentation that a browser renders. What do you mean by "the black text with a dark grey font"? Can you give an example? --RexxS (talk) 12:58, 15 August 2020 (UTC)[reply]

Combining rows

@Izno: This edit in question which you reverted. The previous text explicitly mentions confusion about column headers. No concern about rows. So how is this improved version confuses anything? It's still clear what is the row/cell contents AND which column header applies. So what's the issue? cherkash (talk) 23:03, 5 March 2021 (UTC)[reply]

Just because one thing is or is not mentioned does not mean that thing is or is not acceptable accessibility practice. It's clear to you. It may not be clear to a screen reader. --Izno (talk) 21:48, 6 March 2021 (UTC)[reply]

Table values as manual separators (List of countries by median age#By population division)

See updated link below At List of countries by median age#By population division table values are used as manual separators. What is the best way to fix this? A separate table for each? --Emir of Wikipedia (talk) 17:20, 7 March 2021 (UTC) (please Reply to icon mention me on reply; thanks!)[reply]

@Emir of Wikipedia: I actually think that usage is not too bad. From your description here, I pictured some colspanned rows like the dividers here. But the table you're pointing at has rows which include data in all columns, and aren't so much dividers (especially after sorting by Region, say, or "1970") as they are just aggregations of other (groups of) rows. I'd prefer to see the table right-aligned (except for the Type column), the headers need scope attributes, and the caption needs its caps corrected, but otherwise, the table seems nicely accessible to me. Even the presence of the Type column means that the colors aren't the only indicator of aggregate rows. I wouldn't separate anything. — JohnFromPinckney (talk) 00:17, 8 March 2021 (UTC)[reply]
If other people think it alright then it might be fine, just looked like a very strange way to do a table to me. Emir of Wikipedia (talk) 15:20, 20 March 2021 (UTC)[reply]
Two things:
  1. I have changed the section heading pointed to above, as it turns out "population division" is an office or team or department of the UN, not a different way of organizing the data. The new target for the discussion here is List of countries by median age#UN figures.
  2. I'm no longer so sure I like that table. It's copied pretty much directly from the UN's Excel file, where those dividers and aggregates seem to make more sense. I'll have to think about this some more, but (or even: therefore) if anybody else has some input I'd be keen to hear/see it.
Warm regards, — JohnFromPinckney (talk) 06:27, 23 March 2021 (UTC)[reply]
Thanks for taking more time to consider this. Looks like it was more complicated than I thought. Emir of Wikipedia (talk) 15:48, 27 March 2021 (UTC)[reply]

Wrong for 11 years

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

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

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

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

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Accessibility/Data_tables_tutorial&oldid=1064219197"