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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Row and col scopes

Hello. I've just read a comment here which suggests we no longer need to explicitly add row and col scopes to tables for accessibility. Can someone confirm this or define the cases where we would still need to do this please? Thanks. The Rambling Man (talk) 08:22, 15 July 2013 (UTC)

Nah, it really means that class="wikitable" will auto-style things to look right without the explicit scopes, but that removing them will harm accessibility. It's physically impossible for a CSS class to insert HTML element attributes like scope= in a <th>. What's happened is that the scope was being used to help determined the style output, but this styles have been shuffled into the class. "we don't need to add scopes now" = "I can't see a difference in the GUI rendering".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:34, 14 July 2015 (UTC)

Good column heading example appears to be bad row heading example

Manual of Style Column headers in sortable table good example appears to make the rows not be accessible. If one goes down any random column other than the year or song name, there is nothing associating that cell with the song name. A screen reader, to my understanding, would read the year prior to reading the cell, not the song name prior to reading the cell.

I've seen templates where the corresponding appropriate non-first-column row header is marked as a header, but I still don't know whether a screen reader would handle that properly, especially without a scope attribute.

Thisisnotatest (talk) 01:36, 7 June 2015 (UTC)

JAWS just reads the song name when moving down by a random column. Graham87 09:14, 7 June 2015 (UTC)
Thank you Graham. I wonder how JAWS knows to do that. I don't see anything anywhere in the Wikicode that indicates the song name is the identifying information for each row. Thisisnotatest (talk) 09:48, 7 June 2015 (UTC)
Oh jeez ... did I actually write that? There was a misfire between brain and fingers there ... JAWS actually says no additional info(not even the song name) when traversing a random column. Which probably makes more sense. Graham87 15:30, 7 June 2015 (UTC)
No worries, glad I asked. It makes sense under the "do no harm" rule that you would only hear the cell. But if you use JAWS ability to announce the row header before the random cell content -- I don't know whether it's a verbosity setting or on-demand keystroke -- you would probably want to hear the song title, and I'm guessing JAWS would announce the year.
New Jersey Turnpike#Exit list is marked up with the 3rd column, mile, as the row header. I wonder whether, going down the 6th column, Destinations, whether screen readers that are set to read the row header before the cell contents would read the mile column as the row header.
Thisisnotatest (talk) 21:02, 7 June 2015 (UTC)
I have table titles set to "both row and column" (which I think is the default), and it still didn't say anything. At the New Jersey Turnpike example, however, JAWS does say the mile heading as I go down a column. Graham87 07:00, 8 June 2015 (UTC)
Graham, thank you. That's good news. Thisisnotatest (talk) 15:45, 8 June 2015 (UTC)
Thisisnotatest : Hi ! The purpose of the example Wikipedia:Manual_of_Style/Accessibility/Data_tables_tutorial#Column_headers_in_sortable_tables:_good_example was not to provide a perfect example. It was to present a very much improved version of the table compared to the previous situation. There are no row headers on purpose, and thus it is perfectly normal that no row headers are read aloud. JAWS had the expected behavior. :-)
Because of the structure of the list and the table, it seems that the number and the dates (the chronology) seems more important than the name of the song. At least this is how I understand it. Number and dates it this case would not make a good row header. Some tables are not made to have row headers, and I think this is one of those tables. I might be wrong though. Dodoïste (talk) 12:52, 14 July 2015 (UTC)

Discussion on complex tables and Wikipedia

Please join a discussion: Complex tables cannot be made accessible in Wikipedia and what to do about it Thisisnotatest (talk) 20:48, 7 June 2015 (UTC)

And of table summaries

Please see Wikipedia talk:WikiProject Accessibility#Expert review needed.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  15:35, 18 July 2015 (UTC)

Colspans

From my reading of this page, the objection to placing colspans in the middle of a table to visually separate it (as in the bad example) is that assistive technologies won't know which header(s) still apply to cells further down the table.

But doesn't that only apply if the colspan is actually treated as a header? (In the bad example, the row begins with an exclamation point: !colspan="5"|Representing {{URS}}.) What about in cases when the colspan is treated just like a normal cell? (In the bad example, the row would begin with a bar: |colspan="5"|Representing {{URS}}.) Wouldn't that then mean that assistive technologies would not read either "Representing Soviet Union" or "Representing Belarus" as headers, and that the table would therefore meet MOS:ACCESS?

I'm thinking specifically about the article Official Classical Singles Chart. I would like to include colspans to visually separate the table by year (as here). As I understand it, the table doesn't treat the colspans as headers, so I don't see why they would fail MOS:ACCESS. Any feedback would be welcomed. Thanks, A Thousand Doors (talk | contribs) 16:00, 31 January 2018 (UTC)

They are both bad (as a header cell or a data cell) because they are not fundamentally data but instead layout, as the other reason to advise strongly against colspanned elements as in the current page. Graham over on the main talk page noted that row/colspans "in the middle" tend to cause issues even in current screen readers. --Izno (talk) 15:41, 25 September 2018 (UTC)

Column headers in sortable tables: "good" example

Following on from a discussion here, and despite what I may have said six years ago, I'm really not convinced that adding an extra column to a sortable table (as in the "good" example) is a decent solution to the problem. Adding an additional column if often not practical for some tables, as it will just squash up the contents of the others. We tend not to have rowspans in sortable tables anyway, given how they break up unappealingly whenever the table is sorted, and then can only be remerged by refreshing the page.

In the case of the "good" example, the Year column is entirely redundant, as the Reached number one column already states the year. Also, the visual separation between consecutive years is now considerably less clear (it's basically just one thin line in the Year column). I believe that the good example should be removed, and that we should try to come up with an alternative solution (e.g. finding a way to make colspans meet MOS:ACCESS). Thanks, A Thousand Doors (talk | contribs)

It's been over a month and there's been no discussion. I'm just going to be bold and remove the "good" example for the reasons that I've listed above. Thanks, A Thousand Doors (talk | contribs) 15:58, 24 September 2018 (UTC)
I inadvertently reverted you, not knowing that this had been removed recently....
The solution in question is still excellent where the number of columns is already few, or where the sortability desire overrides the width concern. (While I would tend to advise against wide tables, that's not per se an accessibility concern.) I have not seen We tend not to have rowspans in sortable tables anyway, given how they break up unappealingly whenever the table is sorted, and then can only be remerged by refreshing the page. to be true whatsoever.
I agree that in the specific example removed, year and date almost duplicate each other. (Consider Christmas-time albums, which may release in December but may not 'reach' anything meaningful until the week of January 1 the next year.) --Izno (talk) 15:38, 25 September 2018 (UTC)

Article section headers as column headers

Column headers in the middle of the table fails accessibility according to the guidelines here Wikipedia:Manual of Style/Accessibility/Data tables tutorial#Avoiding column headers in the middle of the table. Is there a difference if the column header is used also as an article section header like in List of Marvel Cinematic Universe television series actors? --Gonnym (talk) 09:59, 31 December 2018 (UTC)

@Gonnym: Is there a difference? Yes, that's much worse. For starters, just try clicking on the 'edit' link for any of those "sections" — you end up editing the wikicode for a partial table, with none of the header rows visible. That article is an accessibility nightmare, a formatting nightmare, and just a general readability nightmare. I'm actually sort of afraid to try looking at in on mobile... oh, yeah, it's a nightmare of narrow columns, and horizontal scrolling over wide swaths of empty space.
There is no reason for something that claims to be a "list" article to be organized into tables like that. The same information could be presented coherently in list form. It seems like the tables are organized around the ability to associate characters with the shows/seasons they appear in (which is weird, for an "actors" list), and then to associate different actors with the same character when they appear in different contexts — but that almost never happens. (In a quick eyeball scan of the ABC section, I only spotted three relatively-minor characters not played by the same actor in all of their appearances, and that's counting the Andrew Garner / Lash situation.) Meanwhile, the tabular organization forces the actors from Inhumans — a show that did not cross-pollinate with the rest of them — into one narrow column that's off the right edge of my browser window unless I scroll.
Purely in my personal opinion, that article is a disaster. And the section headings inside the tables are only part of the reason why. But they are definitely up there, on the list of its sins. -- FeRDNYC (talk) 00:47, 13 February 2019 (UTC)

Color contrast checking

The section on color presents an offsite link to the "free Color Contrast Checker" — an installable software application only available for Windows and MacOS. That's not very helpful to users of other operating systems, users of mobile devices, users at public computers, or just users who don't wish to install new software on their computer.

It seems to me that, in this day and age, there are lots of resources out there, both online and off, that would be more generally... well... accessible, to abuse a term. This list seems like a good starting point, though I just plucked it from the results of an obvious google search that anyone else could also undertake. I'm a Linux user, so I can't say what the Paciello Group software has going for it — is there some feature that would recommend it above all other options? -- FeRDNYC (talk) 01:01, 13 February 2019 (UTC)

BTW, WCAG Color Contrast Analyzer (from the list I linked to above) sounds especially interesting:

This Chrome extension differs from other tools in being able to analyze text set on images or gradients as well as regular online text. It converts a page to an image and highlights areas where the edge between colors are different enough to meet the contrast requirement selected.

— Best Color Contrast Checkers for Accessibility Testing
It's Google Chrome only, which again isn't great, but that's kind of my point about the options out there: Even Chrome users on Windows and MacOS might find that extension useful, vs. the software application that's currently presented as the (implied) only option. -- FeRDNYC (talk) 01:08, 13 February 2019 (UTC)

Row headers in sortable tables?

I tried to add row headers to List of coal-fired power stations in Turkey but could not figure out how to do it without messing up the sorting. Could anyone help?Chidgk1 (talk) 19:21, 23 December 2019 (UTC)

Should the "summary" section of this guide be deleted?

I am confused whether I need to add a summary to List of coal-fired power stations in Turkey as this tutorial says:

"This subsection was added in July 2015, and post-dates expert review as of September 2010 of the guideline, which is probably due for re-review anyway"

Presumably screen-reader tech has advanced since 2010 so is the guideline going to be re-reviewed please?

And do I need to add a summary to this particular table?Chidgk1 (talk) 19:49, 23 December 2019 (UTC)

As a screen reader user (though not an expert in the web accessibility field), I don't think a summary is needed on that table. Graham87 23:45, 23 December 2019 (UTC)
Thank you - if you or anyone else have any other suggestions (on accessibility or anything else) on that article I will be happy to hear them on Talk:List of coal-fired power stations in Turkey — Preceding unsigned comment added by Chidgk1 (talk • contribs) 06:28, 24 December 2019 (UTC)
per [1] the summary attribute in HTML5 has been deprecated. The guide should be updated to reflect this. --Gonnym (talk) 09:31, 19 February 2020 (UTC)
Do you mean I should delete the "summary" section in this guide?Chidgk1 (talk) 15:46, 19 February 2020 (UTC)
@Chidgk1: I think that section should be removed from this guide. Summaries should not be used in HTML5 according to the w3.org (World Wide Web Consortium) guideline that User:Gonnym found:
Using the summary attribute of the table element to give an overview of data tables. "In HTML5 the summary attribute is obsolete. Assistive technologies may or may not continue to support the attribute. Authors should consider alternatives and only use with caution."
@Dodoïste: Do you have an opinion on this? I notice you haven't made any edits on English Wikipedia since 2015. And only 2 edits on French Wikipedia since 2017.
@Graham87: As a screen reader user what do you think of this? --Timeshifter (talk) 07:57, 17 April 2020 (UTC)
@Timeshifter: It probably should be removed (or maybe a caution should be added), but I don't have any strong feelings about this. Graham87 08:32, 17 April 2020 (UTC)
Deleted but I don't have any expertise so if wrong please correct. Chidgk1 (talk) 06:00, 18 April 2020 (UTC)

Are scope=row and scope=column needed nowadays on basic wikitables using class=wikitable?

Please see links to the W3C guideline, and example tables here:

I am asking about this because I edit Help:Table and it recommends using scope=col and scope=row.

According to the W3C guideline scope is not necessary for simple tables: "Note 1: 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 see some very old discussion here and elsewhere. From what I read the W3C guideline has not changed over the years concerning this. And I assume screen readers have improved since then too.

So are there any thoughts on this? I want to clarify Help:Table to note that the scope tags are not necessary on basic wikitables.

@Graham87: As a screen reader user can you check out the example tables on that user page, and tell me if the basic table at the end without scope=col and scope=row is a problem? --Timeshifter (talk) 08:42, 17 April 2020 (UTC)

FWIW all those tables read identically to me on the latest version of JAWS and a fairly recent version of NVDA. Graham87 08:44, 17 April 2020 (UTC)
Thanks. I have some other questions I will post later in another new talk section here. --Timeshifter (talk) 09:13, 17 April 2020 (UTC)

Help:Sortable tables. Section about sorting buttons in a separate row. Accessibility questions

Tracked in Phabricator
Task T35249

Please see Help:Sortable tables. See the section currently called "Sorting buttons in a separate row".

It discusses that option as a way to allow more columns in a narrow screen. It is a very useful option. But there is a question about accessibility.

The direct links (while they still work) are:

Past discussion on accessibility of putting sorting buttons in a separate row is at:

Here is the current example table at Help:Sortable tables:

name data columns another column
data more data

cats 273 53 1
dogs 65 8,492 2
mice 1,649 548 3

@Graham87: As a screen reader user what do you think of that table, and the past discussion?

Here is the same table below without the separate added row just for the sorting icons:

name data columns another column
data more data
cats 273 53 1
dogs 65 8,492 2
mice 1,649 548 3

--Timeshifter (talk) 17:04, 21 April 2020 (UTC)

@Timeshifter: I'd prefer not to have the sorting icons in a separate row ... they just appear as empty/clickable cells (depending on settings). Graham87 03:44, 22 April 2020 (UTC)
@Graham87: That's what they are: "empty/clickable cells". The problem is that the Mediawiki developers refuse to put the sorting buttons below the header text. If they did that, then there would be no need to create a separate row of empty clickable header cells.
It sounds like your screen reader is reading the cells correctly. So I am wondering how is that a problem?
People have to choose between making tables fit better in more screens, versus better accessibility for users with screen readers. But I still don't understand how it is an accessibility problem. Are you able to read the table with the separate row of empty clickable cells?
I found a Phabricator thread discussing this:
T35249. Option for sort indicator to be below the table header text
It was marked as resolved when it became possible to add a separate row of empty header cells that contained the sorting buttons. The resolved status can be changed. For example; due to accessibility problems. --Timeshifter (talk) 06:44, 22 April 2020 (UTC)
@Timeshifter: It's still very readable with the empty/clickable row, it's just more annoying to have to go past blank cells; I know they can occur in other circumstances, too. Perhaps this is one of these cases where a minor accessibility improvement loses out for now to better display on screens. Also pings after the fact don't work. Graham87 15:19, 22 April 2020 (UTC)
@Graham87: Thanks for the pinging info. "Note that the post containing a link to a user page must be signed; if the mention is not on a completely new line with a new signature, no notification will be sent."
I guess if I add a ping later, I also have to add a new signature.
It would be nice if the developers would put the sorting button below the header text. That would solve all the problems. I think I am going to remove "resolved" from that Phabricator task, if possible. Then I will point them here. --Timeshifter (talk) 16:34, 22 April 2020 (UTC)
@Graham87: I left a message at Phabricator task T35249 and pointed them here. --Timeshifter (talk) 19:55, 22 April 2020 (UTC)


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)


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 [2] - the editor added a caption to the table which is the exact name of the itself.TheHotwiki (talk) 02:09, 25 April 2020 (UTC)

Hotwiki, What would be a better caption for this table? ―Justin (koavf)❤T☮C☺M☯ 02:12, 25 April 2020 (UTC)
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)
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)
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)
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)
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)

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

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

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)

@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)
@Graham87: Thanks again! --Timeshifter (talk) 15:37, 13 August 2020 (UTC)

@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)

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)
Indeed; I'm by no means an HTML expert. Graham87 04:02, 14 August 2020 (UTC)
Please see the new talk section. I corrected my errors and created another sandbox. --Timeshifter (talk) 07:53, 14 August 2020 (UTC)

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)

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)

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)

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)
@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:Sortable tables, 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)
@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)
@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)
@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)
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)
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)
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)
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)
@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)
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)
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)
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)
@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)

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)

@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)

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)

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)

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!)

@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)
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)
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)
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)

Wrong for 11 years

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

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