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

Archive 1

Archive 2

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:

• H63: Using the scope attribute to associate header cells and data cells in data tables.

• User:Timeshifter/Sandbox103.

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:Sorting. Section about sorting buttons in a separate row. Accessibility questions

Tracked in Phabricator
Task T35249

Please see Help:Sorting. 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:

• Help:Sorting#Sorting buttons in a separate row - it is a subsection of this:
• Help:Sorting#Options for more columns in a narrow screen

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

• Help talk:Sorting/Archive 3#"In a narrow space" empty headers are accessibility errors

Here is the current example table at Help:Sorting:

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) Archive 1 Archive 2