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

Unbulleted lists

At the risk of increasing the number of templates in an article, there is a space-saving template called {{Unbulleted list}} which might be useful when tables become wide. It produces the correct semantic markup for a list, which is exactly what is needed when a data cell contains a lower hierarchy of data (in this case a list). Here's an example:

List of albums

Title	Album details	Peak chart positions										Sales	Certifications
		US	AUS	AUT	FIN	NLD	NZ	NOR	SWE	SWI	UK
Bleach	Released: June 15, 1989 Label: Sub Pop (SP #34) Format: CD, cassette, LP	89	34	26	24	—	30	—	—	—	33	1.7 million (US)	Platinum (US)
Nevermind	Released: September 24, 1991 Label: DGC (DGC #24425) Format: CD, CS, LP	1	2	2	1	5	2	2	1	2	7	10 million(US) 26 million (worldwide)	Diamond (US) 2× Platinum (UK)

would become:

List of albums

Title	Album details	Peak chart positions										Sales	Certifications
		US	AUS	AUT	FIN	NLD	NZ	NOR	SWE	SWI	UK
Bleach	Released: June 15, 1989 Label: Sub Pop (SP #34) Format: CD, cassette, LP	89	34	26	24	—	30	—	—	—	33	1.7 million (US)	Platinum (US)
Nevermind	Released: September 24, 1991 Label: DGC (DGC #24425) Format: CD, CS, LP	1	2	2	1	5	2	2	1	2	7	10 million (US) 26 million (worldwide)	Diamond (US) 2× Platinum (UK)

This also removes some of the the superfluous column widths (if you must have them, use ems because you don't know the metrics of the client's browser font) as well as the deprecated <br /> tags that are being used to visually mimic a list. Also, style="text-align:center" is much better than setting a td to the deprecated align=center. As usual, this isn't compulsory, but it is much better practice. The extra whitespace indenting in the unbulleted lists is only there to help make the structure clearer. I don't expect every editor to cope with this sort of markup, but there's no reason why experienced editors can't improve this as they clean-up tables. --RexxS (talk) 14:47, 10 September 2010 (UTC)

1. I do agree about the widths. Widths do make the table look prettier. But they should be made of em rather than pixels. A good practice that I forgot to apply here. Thanks for reporting. :-)
2. I agree about style="text-align:center" as well.
3. Now I'm not sure about this particular use of unbuletted lists. Sure the principle is good and all. But I'm not sure it's worth the effort here. In the "Album details" column it saves a little space. And in "Sales" and "Certifications" column it can sometimes indicate a list of two items. It's a lot of code for a small change. However, The Prodigy discography contains a few examples where unbuletted lists would really be useful (lists of 4 to 7 items). It needs some more thoughts (and possibly feedback from users) on my opinion.

Among tables, there are some far more urgent use of {{Flatlist}} (with another layout) in {{Navbox}} for example. I'd rather work on a large-scale important improvement on Navbox than a few lists here and there. Priorities, priorites. ;-) Dodoïste (talk) 04:35, 11 September 2010 (UTC)

1. At a second thought, the widths are set to create a cellpadding. And ems doesn't work in the width attribute. Maybe the % would be a good solution but I'm not sure. Is there a reason why cellpadding="5" doesn't work with class="wikitable"? Cellpadding would definitely be the simplest solution.
2. If cellpadding are used it also solves the issue with centered text as text becomes centered by default: align=center becomes useless. Regards, Dodoïste (talk) 17:29, 12 September 2010 (UTC)

The element 'td' has a deprecated attribute 'width' which can only be a number or a percentage. The number is taken as a 'hint' for number of pixels, and the percentage is a 'hint' for the percentage of the table width. Neither of them is a good idea, and doesn't offer the flexibility of 'style', although having a single definition of padding is convenient. Padding is defined in the 'wikitable' class:

.wikitable th, .wikitable td { 
border-top-color: #aaaaaa;
border-left-color: #aaaaaa;
border-right-color: #aaaaaa;
border-bottom-color: #aaaaaa;
border-top-width: 1px;
border-left-width: 1px;
border-right-width: 1px;
border-bottom-width: 1px;
border-top-style: solid;
border-left-style: solid;
border-right-style: solid;
border-bottom-style: solid;
padding-top: 0.2em;
padding-right: 0.2em;
padding-bottom: 0.2em;
padding-left: 0.2em;
}

Since that applies to each cell, it overrides the value "inherited" from a cellpadding attribute in the table element. The best I can suggest is to either apply style="padding: 0.2em 0.8em;" to each cell that requires padding, or to apply it to each row if you want it throughout the table. Example on a 'per-cell' basis:

List of albums

Title	Album details	Peak chart positions										Sales	Certifications
		US	AUS	AUT	FIN	NLD	NZ	NOR	SWE	SWI	UK
Bleach	Released: June 15, 1989 Label: Sub Pop (SP #34) Format: CD, cassette, LP	89	34	26	24	—	30	—	—	—	33	1.7 million (US)	Platinum (US)
Nevermind	Released: September 24, 1991 Label: DGC (DGC #24425) Format: CD, CS, LP	1	2	2	1	5	2	2	1	2	7	10 million (US) 26 million (worldwide)	Diamond (US) 2× Platinum (UK)

The style="text-align:center" (not align=center !!) for the number cells may still be needed if we have cells in the column with different amounts of information in them. Otherwise, for example, '1' would line up left-aligned below '89' which looks horrible. Semantically, it's now fine (look at the page source), although it does seem a lot of effort just to make it look pretty. --RexxS (talk) 19:37, 12 September 2010 (UTC)

Thanks for the information about padding in the wikitable class.

We'll use more code if necessary. But I would be best to choose this option only as a last resort. For the numbers of the second row a non-breakable space "& nbsp;" produces the same result. Is it better? Regards, Dodoïste (talk) 01:44, 21 September 2010 (UTC)

Avoiding more than two levels of headers

The table given as the good example could be improved by using row headers (in this case the distances). Remember, screen readers are capable of non-linear navigation, so the ability to announce the [column header][row header] before any cell value can be more effective when row headers are present, particularly on larger tables. --RexxS (talk) 15:05, 10 September 2010 (UTC)

In theory I agree of course. In this particular case I was unsure the distance would made relevant row headers. But at a second thought – and after I saw more use cases – I think you are right. :-) Dodoïste (talk) 15:16, 10 September 2010 (UTC)

 Done Dodoïste (talk) 17:31, 12 September 2010 (UTC)

Images and color

Collapsible tables can also work without the faux header:

Sorted by country alphabetically

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
Australia								x	x	x	x	x	x	x	x	x	x	x	x
Canada					x	x	x	x	x	x	x	x	x	x	x	x

But some people may not find it as "pretty". --RexxS (talk) 16:27, 11 September 2010 (UTC)

Interesting. So the script chooses the first header and add the "show/hide" button to it. It's a pity we can't choose the header on the far right. "Show/hide" buttons are always on the right. Usability-wise it would be better to have consistent types of contents. I wish the usability team would complete their Style Guide and ask users to comply to it. It's a good practice on Web projects. For example, we decide that link are blue and underlined on mouseover and onfocus. This behavior should never change on Wikipedia: it becomes a rule. It should be kind of similar with collapsible content: the appearance and behavior should never change.

The best solution would be to improve the script. So that it adds the "show/hide" button to the caption instead. It's a lot of work as every table using this collapsible script should be fixed (and probably manually). Still, it's definitely something we will have to do sooner or later. I believe it would be better to gain experience with other simpler tasks. And afterwards we should make a task force for this job. Regards, Dodoïste (talk) 01:20, 12 September 2010 (UTC)

If we could ensure every table had a caption, then it would be the perfect place for the show/hide trigger. One day, maybe ...

Incidentally, my links are whatever colour I want, as anyone can override most global style choices in their own /[skin name here].css file. For example, I like to be able to pick out recently visited pages on my watchlist, but I'm somewhat colour-blind between the default blue link and the default for a visited link, so I set

• a:visited { color: #8800C0; }

Similarly, anyone can override default behaviour for classes, such as the class="external text" to change the style of external links only. Of course, all of this works as simply as that, only if we don't embed in-line styles in elements.

You've made a lot of progress with giving good accessibility advice here, and all of it will also be useful for those working on the usability project – good accessibility and good usability have a habit of going together. Cheers --RexxS (talk) 04:06, 12 September 2010 (UTC)

Yes, one can override most global choices in their own skin css file and it's a good thing. It's very important accessibility-wise. Users can select/add a style sheet directly in their browser and have it applied for all websites (or may even be able to have website-specific style sheets). The !important declaration is made especially for this purpose: it overrides the website's style sheet and inline styles.

Still, the default appearance should not change. When users customize style sheets it's their responsibility and choice (and needs). The default appearance should be consistent nonetheless.

"I'm somewhat colour-blind between the default blue link and the default for a visited link": as many of us average users. The usability team received a lot of complaints about it. But strangely - especially for a usability team - they did not take this feedback into account. WTF?

Thanks. :-) I'm glad to be able to help. Yes, accessibility and usability projects should collaborate more. For example, the only solution to solve most of the contrast issue with colors in articles and templates is through usability. It's far too complicated for the average user to test color contrasts with the Color Contrast Analyzer and corresponding guidelines. It's easier to decide that "for usability reasons the colors used in Navbox should be ... (insert relevant choice here) and that rule should never change".

Also, did you notice how I make the navigation in this Wikiproject? I used two usability recommendations that are almost never used on Wikipedia: a breadcrumb, links in the menu are organized in sub-menus that do not contain more than Seven plus or minus two items. How about we organize help pages like that? It would surely make it easier for newcomers. Regards, Dodoïste (talk) 16:01, 12 September 2010 (UTC)

Open question on missing cells

In several tables cells are not created when they should be blank. Example: Dwain Chambers. Is it an accessibility issue? Does it makes the table confusing for screen reader users? Regards, Dodoïste (talk) 20:18, 13 September 2010 (UTC)

It's actually a UAAG issue. See Calculating the number of columns in a table:

• "... if the TABLE element contains no COLGROUP or COL elements, user agents should base the number of columns on what is required by the rows. The number of columns is equal to the number of columns required by the row with the most columns, including cells that span multiple columns. For any row that has fewer than this number of columns, the end of that row should be padded with empty cells."

So user agents should supply empty cells (rather than failing to provide anything). Agents that conform to h-11.2.4.3 will not cause any accessibility issues specific to disabled users; but may have accessibility implications for all users of text-only agents (since they generally do not distinguish between empty and row-spanned cells). --RexxS (talk) 21:58, 13 September 2010 (UTC)

OK, thanks RexxS. :-) Dodoïste (talk) 22:05, 15 September 2010 (UTC)

Avoiding rowspan/colspan

"Old screen readers and user agents that do not conform to UAAG do not handle rowspan / colspan efficiently. The result can be very confusing for users of these technologies." - this seems to imply that user agents that do conform to UAAG don't have problems with rowspan/colspan. Since I don't think any user agent fully conforms to UAAG, what are we saying? This opinion is reflected in Wikipedia already (Web Accessibility Initiative#User Agent Accessibility Guidelines (UAAG)). For example, I believe that Lynx conforms to UAAG as much as IE8 does, yet the rowspan vs empty cell problem demonstrably exists with Lynx. You may need to distinguish between graphical browsers and text-only browsers to give meaningful advice. --RexxS (talk) 22:42, 13 September 2010 (UTC)

That's right, thanks for reporting this issue. I'll take it into account when I will complete this section. :-) Dodoïste (talk) 22:31, 15 September 2010 (UTC)

I tried my best to reword this sentence. Is it okay or still confusing?

Now this tutorial is complete. I will ask an expert to review it. :-)

I'd like to apologize for my rudeness a few weeks ago. I did not realize you were willing to compromise on this issue. I appreciate your participation and comments. And I'm looking forward to work with you in this accessibility project. :-) Again, please accept my apologies.

Are you okay with the content of this section? If you still disagree on something it's time to bring up the issue. Or if you would like to rephrase a few paragraphs, go ahead. :-)

If you agree with this compromise, could you comment on Wikipedia talk:WikiProject Discographies/style#Time to update accordingly? That way we will be able to move forward, and do the same thing with other WikiProjects. :-) Kind regards, Dodoïste (talk) 01:35, 21 September 2010 (UTC)

First of all, let me say that you've done an excellent job here, and it's much appreciated.

Next, there's no need for you to apologise, as vigorous debate between editors usually produces better content in the end. I should however apologise for often seeming intransigent in my own views – I didn't realise I was such a villain! You come to the issue of accessibility from a background of improving it for those with disabilities. While I appreciate the rigour WCAG brings to that area, my background is in systems analysis and web design, and my instinct is to emphasise the problems for users who only have older technology, limited bandwidth, etc. They don't have an organisation like WCAG to advocate for their interests, so I often need to present my own research, rather than being able to point to a source.

Nevertheless, I'm convinced by your arguments that "perfection is the enemy of good enough", and I'll happily go along with making improvements incrementally. It will be a long time before more than a small proportion of Wikipedians acquire anything more than a basic understanding of the issues here, and I accept that we need to "sell" these ideas slowly enough that we don't provoke rejection.

The content is fine, by the way. Nothing on Wikipedia is a finished work, and I expect others will eventually refine and improve what you have started.

I've commented at the Discographies style page, and I'm encouraged by the reception you've had there. Let me know when you approach other projects, and I'll do my best to help and to mobilise folks like Jack (who is clueful and has his heart in the right place). --RexxS (talk) 04:45, 21 September 2010 (UTC)

Very interesting answer. I wanted to provide a detailed answer a long ago, but that answer was too long to write. :D

At any rate, this guideline is currently being reviewed. It will be ready to be implemented in a few days. :-) Dodoïste (talk) 00:59, 26 September 2010 (UTC)

Does using transparent borders instead of merging make it better or worse? That can give the same aesthetic, but without navigation issues for those who are not navigating visually?

The catch would be, it means whatever point the merge is showing is not available to non visual readers?

- or do screen readers tell you about colour etc?

- or is the kind of flagging of "this run of cells all have the same value" less relevant to someone navigating through cell by cell?

obviously the cells would need to all contain the relevant value, the transparent borders would just shows they match? if the transparent borders join empty cells to look like a merge without being one, that would be much worse? possibly shading neighbouring cells is a better strategy to point it out visually without causing screen reader problems? though, i have heard, some sighted people find too much colour kind of disorienting.

Irtapil (talk) 15:22, 11 May 2020 (UTC)

Layout for wikitable row headers

This is a reminder about the request on MediaWiki talk:Common.css to improve the default layout. It is definitely a good idea that should be adopted somehow. How do we gather consensus? Should we make a request for comment or something?

Note that I implemented this suggestion on the french Wikipedia the 22th of August, following Jack Marridev's good proposal. Regards, Dodoïste (talk) 22:04, 15 September 2010 (UTC)

Minimum font-size recommendations

I spend a lot of my time fiddling with music articles, which means I work a lot with discography tables as used in the examples here (no doubt taken from the discogs style page). This example (in both the "good" and "bad" cases) uses style="width:2em;font-size:75%" for the column headings. The setting of 75% for the font-size is widespread among the music articles, and (or because) it closely simulates the <small></small> that was the typical formatting before the CSS got added.

What I'd like to see addressed is what minimum font-size Wikipedia should be recommending or mandating. I think 85% is plenty small, thank you, considering that it's already 15% smaller than what the sighted user's preferred and expected font-size. The 75% used in the recommended examples here is even smaller.

I assume that the profoundly blind, using text-to-speech AT, won't care about this, but users with weak vision (and I just might be talking about visitors over about 40) would probably find accessibilty enhanced if they didn't need to squint and strain so much to tell "NL" from "NZ" apart. Is this an appropriate place to address this? Or am I better off pursuing my little crusade at Wikipedia:WikiProject Discographies/style? Thanks for the good work here. — JohnFromPinckney (talk) 11:18, 21 September 2010 (UTC)

It's certainly an accessibility issue and the Accessibility Manual of Style should give guidance. The place would be at Wikipedia:WikiProject Accessibility/Manual of Style draft#Text, but it's not written yet. There is a wide variety of browsers, screen sizes, and resolutions, so the problem is not the same for everyone. Personally I now have difficulty reading text on a 17" full-HD laptop without using the browser zoom, so I sympathise. I actually think that article text needs to be rendered at close to 100% as a minimum (since even 85% may be difficult for some), but it may be necessary to compromise in some cases, and 85% may be sensible target minimum for now. There's no reason why you shouldn't raise the issue with any project: I'm sure you'll be able to count on the members of WikiProject Accessibility to also discuss it and provide useful advice. --RexxS (talk) 19:20, 21 September 2010 (UTC)

Thanks for your useful input JohnFromPinckney. :-)

I already had to fight this issue several times on french wikis. Several users love small text and it's a pain to deal with this issue. That's why I hesitated to bring it up. But since we agree on that it might be worth trying to solve this issue.

I'd say this is mostly a usability issue. People with weak vision and others are technically able to zoom, so it's not really an accessibility issue. However, a surprisingly large number of users do not know how to zoom with their browser (Ctrl +/-). And for those who know, they have to zoom in and out just for these table headers. It's a pain, and it's unnecessary.

Small text affects readability a lot, and has been thoroughly studied by usability experts: small text is way harder to read for everyone. Usability guidelines recommend a default font size of at least 12 points (about 16 pixels, but pixels are evil).

There is any number of useful resource about readability on the Web. But those three stand out:

• An overview of readability best practices
• Research on readability, for advanced users or Wikiproject members
• List of further references

Since this issue is mostly interesting from an usability point of view, I suggest to bring this issue at the usability project first. Let's make a guideline about readability there. And afterward I suggest to bring the issue to Wikipedia:WikiProject Discographies/style and try to convince them.

Usability and accessibility have a lot in common, and I believe this topic is an great occasion to improve the collaboration between these two projects. Kind regards, Dodoïste (talk) 20:15, 21 September 2010 (UTC)

Have you already raised this with the Usability project? It seems we're already going ahead with the 100% size in the samples in this tutorial, and it's already getting incorporated into Discographies/style, but I'm not aware if or how the Usability people are getting involved. I don't know where to find them; is it here? — JohnFromPinckney (talk) 05:53, 28 September 2010 (UTC)

Yup, that it. Wikipedia:WikiProject Usability. Well, I'm not sure they are really active right now. But it's worth a try. :-) Dodoïste (talk) 07:37, 28 September 2010 (UTC)

Just to let you know that I've left a message at Wikipedia talk:WikiProject Usability#Readability issues and small text size. You might want to comment there. ;-) Dodoïste (talk) 01:03, 29 September 2010 (UTC)

Scope and simple tables, WCAG 2.0 H63.

I don't want to get into a long debate over this and it has already been discussed here but I got told to come here. W3C says "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." (TH elements can effectively be read as wikitable syntax). I got told that maybe I shouldn't believe everything the guideline says, and that this has been "reviewed by an accessibility expert". Forgive my sceptisim, but the Essjay controversy now makes me cautious over matters like this. I'd much prefer to see something in a reliable source to back up these claims. Rambo's Revenge (talk) 23:47, 20 October 2010 (UTC)

Thanks for coming here. Such discussions in "public" are going too fast compared to the time we need to get an answer from an expert. And the editors tend to lose faith in accessibility guidelines quickly in such cases. It's always harder to rebuild the faith once again afterwards.

"Shouldn't believe everything the guideline says" is not exactly what I meant to say. This guideline is reliable indeed. As for the definition of what is considered to be a "simple table", this guideline is vague on purpose. The interpretation of what is a "simple table" is best left to experts in this case, as they know when this technique is useful (per their feedback from users, and knowledge of assistive technologies).

This has always been a delicate matter on Wikipedia. I met the expert in question in real life, and went to several of his conferences (where I met fellow accessibility experts). I won't tell his real identity because he doesn't want to, but I can assure you he is reliable for sure. Unfortunately, Web accessibility is a job where you need experts to intervene in the process: someone cannot possibly jump in, read a handful of pages and claim he knows. It takes months of training to become a real expert. Sure, the basics are quite straightforward and simple, a passionated developer can learn them in a handful of days. But the approach to follow in Wikipedia's case is particular because of its very nature, therefore not always documented in online resources.

As promised I just sent an e-mail to the expert, to have further explanations on the matter. Yours, Dodoïste (talk) 00:57, 21 October 2010 (UTC)

The accessibility expert replied to my mail. I'll detail it further this evening. But it turns out, WCAG 2.0 TECHS, H63 is mistaken on this particular detail. Reliance on the "simple table" criteria is creating various problems, including in assistive technologies. And it doesn't comply to other related WCAG 2.0 guidelines.

It's the second time I've seen such a mistake. I'll report the mistake to the corresponding working group of the WCAG like I did last time, and start a discussion at their mailing list. Yours, Dodoïste (talk) 10:11, 21 October 2010 (UTC)

If they update their stance, fine. But I follow reliable sources so would believe the World Wide Web Consortium over some editor I know nothing about (no offense). Rambo's Revenge (talk) 15:25, 21 October 2010 (UTC)

We're following W3C's WCAG approach, for sure. But it is not supposed to be applied blindly by someone who is not familiar with the process. We're not writing an article here, we're deciding our site-wide guidelines.

I've just send you an e-mail with the copy of the previous exchange I had with the WCAG working group, to show you how it works there.

As for the sudden reply at the FL discussion: I'm sorry, I didn't expected the expert to reply that quickly. As for the details of this discussion, it is best to keep them here as my detailed reply will be fairly complex for non-technical users. Yours, Dodoïste (talk) 16:38, 21 October 2010 (UTC)

This guideline has it wrong, and it's a known fact to accessibility experts. See, there are several application methodology for WCAG 2.0. Section 508 has WebAIM section 508 checklist, for example. And about this particular issue, WebAIM explicitely says that "The scope attribute should be used on simple data tables". The ITAA guideline says the same. And other application methodologies around the world, like Euracert and the French RGAA says the same. They all agree that W3C made a slight mistake here, and this mistake is likely to be fixed in later versions of the WCAG 2.0 guideline. Dodoïste (talk) 17:59, 7 November 2010 (UTC)

"Good" example

In this section of the tutorial, it is claimed that a caption of "Representing {{URS}}" is considered to be "good". I would argue this is completely incorrect, how does that caption help a reader understand the content of the table he or she is about to read? Also, can I just get confirmation that screen-readers and visually impaired readers would have the {{URS}} suitably transliterated for them? Cheers. The Rambling Man (talk) 17:44, 7 November 2010 (UTC)

Sure, the captions there can be improved. It wasn't the point of the section, so I didn't pay too much attention to it. I'd say "Vasiliy Kaptyukh achievements representing {{URS}}" would be fitting. What do you say?

{{URS}} has no link and the alt text is blank. Since the useful information follows the icon flag, there is no loss of information here. This template is compliant to accessibility guidelines. Thanks for your interest in these matters. :-) Yours, Dodoïste (talk) 18:02, 7 November 2010 (UTC)

Could I make a suggestion? If you wish to create tutorials as part of the MOS, please try to ensure they themselves meet the MOS? "Three headers are red aloud. The first and the third are correct and expected. But "Representing Soviet Union" doesn't apply to this part of the table anymore and a machine doesn't have any hint to understand it." is not great. I guess "red aloud" should be "read aloud" and we avoid contractions throughout. It's not clear what you mean by "doesn't have any hint to understand it" either. I guess, before suggesting this is used mainstream, it's copyedited and reviewed. Saying it's not the point of the section really misses the point. If you want people to comply with the MOS, make the MOS and its tutorials comply with the MOS.

Also, in the "good" example, col widths change from table to table, which is clearly not good for sighted viewers. I suggest that's modified too. The Rambling Man (talk) 18:20, 7 November 2010 (UTC)

I've now added a disputed tag because it appears my concerns have been read but not addressed or responded to. Cheers. The Rambling Man (talk) 21:20, 7 November 2010 (UTC)

The tutorial was reviewed, and copyedited mostly by Graham87 whom I thanks for his great help.

I've just asked the French expert at fr.wiki to provide details about table captions, and their content. I aasked him the especially review the discography cases, and this tutorial. Let's see what his answer is.

What is the clarification you asked about the expert?

This is my last edit until tomorrow evening, I'm going to bed. Kind regards, Dodoïste (talk) 22:03, 7 November 2010 (UTC)

Perhaps it needs another copyedit by someone familiar with the rest of the MOS. I think most of us want to understand what makes the expert the expert. As you know, we don't want another Essjay saga. The Rambling Man (talk) 08:22, 8 November 2010 (UTC)

Hmm. Complicated. I met the expert myself in real life several times, among other accessibility experts and dozens of Web quality experts (in their particular domain). This expert has a reputation to be one of the best French accessibility expert. I know other important facts about him. But last time I mentioned his identity and expertise, he didn't appreciated it.

Anyway, I'll soon have an accessibility training (7 to 10 December), where 5 accessibility experts are present. And this time, they are listed and can be precisely identified through the links provided on the page.

I can ask them any question you want, any accessibility issue you want to raise. And I'll get back at you with their answer.

You can also contact WebAIM guys, as what was did concerning alt text and what led to he change needed. See, there was a huge issue with WP:ALT, where a few users were claiming to be right against all. And the solution was the expert: he was the only one to have enough trust so that users will follow his advice. WP:ALT was then rewritten, and is now pretty good. Just want to point out that experts can bring something else than that Essjay controversy.

As for the need of an expert: WCAG 2.0 consists of 72 A level criteria, 28 AA level criteria and 36 AAA level criteria. And more than 300 techniques are related to them. Perhaps you can read it all in a few days, and understand it perfectly. Which would mean that you are a genius. I'm certainly not capable of that. That's why I need to be in contact with an expert. I'm doing my best, I'm using accurate sources, but I still need an expert to ensure I'm doing the right thing. Hope that makes it clearer. Yours, Dodoïste (talk) 19:12, 8 November 2010 (UTC)

I don't think I ever questioned the need for an expert, but it's fair enough for the community to ensure that the "expert" advice is really coming from an "expert". Cheers, The Rambling Man (talk) 19:29, 8 November 2010 (UTC)

Fair enough indeed. I can't provide the identity of this expert, but I can provide the identity of the experts I will meet at the accessibility training. Yours, Dodoïste (talk) 19:34, 8 November 2010 (UTC)

Well it's just about getting the confidence of the community. We're not trying to trick you, we just want to understand how "expert" this "expert" is. The Rambling Man (talk) 19:42, 8 November 2010 (UTC)

So, here is the answer from the expert. The examples at this tutorial are correct. Table captions may seem perfectly redundant to section headers is cases such as the DICOGS, from an average editor point of view. Table captions are fairly simple and straightforward; they are brief and efficient. They are not redundant from a semantic and accessibility point of view, however. And nothing is able to compensate the lack of a table caption.

My point of view is that we may overlook table captions in discographies for now, if users dislike the redundancy. Anyway, since it's something new, we'd better begin with tables captions that benefits to everyone, and that users feel like adding because they believe it is useful for them too. So I will being with some templates, and other kind of uses for those table captions. Maybe later on users will get used to it, and will add them spontaneously to the DISCOGs. Time will tell. Yours, Dodoïste (talk) 22:55, 15 November 2010 (UTC)

Sorry, perhaps you missed my question which was "how expert is te expert?" And why should I believe what you're saying that he's saying is correct? Captions for most tables in these lists are pointless right now, but that's not the main thrust of my concern. The Rambling Man (talk) 23:03, 15 November 2010 (UTC)

Didn't I told you already that I don't feel comfortable to answer this question? Even if I were to reveal his identity, it might be meaningless to you. For example, this expert is one of the authors of the French RGAA. This would mean a lot to users familiar with accessibility in France, but does it mean something to you? Dodoïste (talk) 06:20, 16 November 2010 (UTC)

So it's a concern that you're modifying style guides under the guidance of someone who claims to be an expert whose identity and qualifications will remain a mystery to the community. The Rambling Man (talk) 07:24, 16 November 2010 (UTC)

Well, well... The French RGAA is like the section 508 in the U.S. Except that the RGAA applies specifically to Websites. It is enforced by the French State. The expert I'm in contact with has enough trust and recognized expertise that he could be one of the authors of such an important application methodology of WCAG 2.0. This expert is also an accessibility trainer. Is that enough? There is much more to tell, but I don't want to get into the details, otherwise it would be a direct violation to his right to be anonymous.

If you want to make sure the guidelines provided by this expert are correct, please ask an expert from WebAIM (or any experienced accessibility expert) to review them. I can do that when I will be at my accessibility training too, just like I promised. But please don't go into wasteful and endless debates about the Essjay controversy. You don't have any facts that can prove this expert is a fake anyway, every guideline a my table tutorial is referenced by the W3C and WebAIM after all. ;-) Yours, Dodoïste (talk) 22:37, 16 November 2010 (UTC)

Well, TMR, if we accept what the expert says, and IIUC, the captions are not pointless. — JohnFromPinckney (talk) 07:34, 16 November 2010 (UTC)

JPF, although I've yet to see a good example of a caption being used in the context of lists (where section headings do the job), I'm not starting this discussion again as this section was intended to address the actually very poor example of a caption that was being cited as a "good" example. And we all know what happens when we "accept expert advice" from mysterious experts whose identity and qualifications are unknown. That's the parallel to alt text. No-one disputed alt text is a good idea, we just had "expert" advice there, the MOS changed, FLC and FAC were mandated to use it, then the advice turned out to be a crock. So little wonder people are overly cautious when these sort of things are rolled out. The Rambling Man (talk) 08:05, 16 November 2010 (UTC)

Just like I told you, discographies may not the best place to begin using table captions. And for the record, the accessibility expert in question and I were aware of the issues at WP:ALT before it became a public issue. And we weren't able to prevent the drama. So this drama should not discredit us, because we were right. Being overly suspicious is not helpful either. Yours, Dodoïste (talk) 22:37, 16 November 2010 (UTC)

I said "overly cautious", not "overly suspicious", and there's a huge difference. You need to prove this expert is worth listening to and has suitable qualifications. This is going to become another drama unless we get an open discussion. The Rambling Man (talk) 23:14, 16 November 2010 (UTC)

So the expert being an author of the French RGAA is not enough in your opinion? And you won't even contact an expert yourself to fond out by yourself? What do you wish for? Dodoïste (talk) 23:51, 16 November 2010 (UTC)

Evidence. Published evidence so we can all see it. It's very simple. The Rambling Man (talk) 00:10, 17 November 2010 (UTC)

So you want published evidence that an anonymous user account is owned by an expert? Impossible, Wikimedia does not make such authentications. I have any number of proofs that user:Lgd is an expert, but the account is anonymous and will forever be. I've been patient enough with you. I've told you about the expert being an author of the renown RGAA. I've suggested to contact other experts. But you don't even care about my replies. Unless you change your attitude and become cooperative, I won't discuss with you any further. Dodoïste (talk) 21:15, 17 November 2010 (UTC)

Dodoïste, did the expert take a look at the specific captions at WP:DISCOGSTYLE or what are currently in Rihanna discography? Did he have any statement to make about the length or approach of these specific examples (assuming the expert has some English fluency)?

You wrote, Table captions are fairly simple and straightforward; they are brief and efficient. It's not clear to me whether that's your phrase or the expert's, or whether that's a philosophical, general statement or an analysis of some specific captions. Is the brief here a condemnation of the 15-word captions I've been implementing?

I'm concerned about the parallel with alt texts, which are good, except that poor alt texts are of no help. Unhelpful or over-detailed captions are visible to all, unlike bad alt texts, so I'd like at least some hint that the suggestions so far go in the right direction, even if they are idealistic or overly optimistic. — JohnFromPinckney (talk) 07:34, 16 November 2010 (UTC)

The expert didn't have a look at the DISCOG captions, despite my request to do so. His English is professional, by the way. But he did say that "making a table caption is just as obvious as making section headers: it's exactly the same thing. In fact, so similar that it's instinctive, and lots of Wikipedia users have been doing it successfully for years relying on their instinct alone".

In short, yes. Don't blame yourself though, it's my responsibility for not having anticipated this issue, and not having enough time to address every issues that popped up recently.

"List of singles, with selected chart positions and certifications, showing year released and album name" is way too long. You wrote it thinking too hard about what a blind user might expect, believing that there is a significant difference between they way you and a blind person use a table. Truth is, there is not that much of a difference, at least not when the table is accessible. And you got confused because the guidelines were too vague. Instead, simply imagine that there is no section header before the table, and that you jump on the table without reading what was written above. You want a table caption, for yourself only. There are lots of possibilities. But you don't want to have a table caption that would take longer to read than figuring out the content of the table all by yourself. Here is a few possibilities:

• "The Prodigy singles and peak charts"; "peak charts" are relevant in the caption because it is the main content of the table.
• "List of The Prodigy singles" would be OK too, but "List of" may well be self-evident and unnecessary.

Those would be fine, it's not that complicated. Repeating the headers in the caption is redundant for blind users. If they want the main column headers read aloud, they can ask their screen reader to do so easily since the table is structured with scope="col/row". They simply want an efficient table header, no less and no more.

In cases where the table is hard to understand visually for sighted users too, table captions may become slightly more descriptive to fit the needs. But again it's trivial, and you'll know it yourself when the table caption is not descriptive enough or instead not concise enough. Yours, Dodoïste (talk) 22:37, 16 November 2010 (UTC)

For example, Template:Infobox US university ranking is a good enough example of table captions, albeit arguably not perfect. "US overall university rankings" might be better, but it would be too large for the infobox width, so it's OK. I'm pointing it out because I just fixed it today. Yours, Dodoïste (talk) 23:10, 16 November 2010 (UTC)

Issue with bold links in table headers

So now you have bold links in your "good caption" which seems to contravene MOSBOLD. Please work this out before you tell us to comply with it. The Rambling Man (talk) 23:00, 16 November 2010 (UTC)

Relax a bit with MOS bold rules, will you? We solved all the bold issues so far, so this is becoming routine. :D Dodoïste (talk) 23:10, 16 November 2010 (UTC)

No, MOS is MOS. FLC has to comply with MOS. Access changes MOS, we have to comply with it. Access turns out to be in contradiction with MOS itself. Problem. Work it out before enforcing it on the community. The Rambling Man (talk) 23:12, 16 November 2010 (UTC)

I have the feeling that you are following MOS rules more strictly than it is intended to be. Links in table headers are very common, even in featured articles (how much do you want to bet on that?). Plus some of them were not added by me, and taken directly from existing examples in the articles, so... This is kind of awkward. You should rather ask MOSBOLD if this guideline really applies to table headers, and make sure it does apply in this context before asking us to comply to it. Yours, Dodoïste (talk) 23:19, 16 November 2010 (UTC)

I have the feeling you don't read all of MOS. I don't need to ask MOSBOLD anything, it's there, it's a guideline that we've been following for years. And now, in your "good" example, you break the MOS. You choose. The Rambling Man (talk) 23:21, 16 November 2010 (UTC)

Right. How many featured lists comply to the bold links in the column headers for discographies? WP:DISCOGSTYLE have bold links in the column headers, most infoboxes does too, and so on. If MOSBOLD does not allow bold links it table headers, as a matter of fact MOSBOLD is ignored everywhere. Yours, Dodoïste (talk) 23:29, 16 November 2010 (UTC)

Bold in column headers? All of them.. Bold links? Hopefully few. Row headers? Hopefully very few. I think DISCOGSTYLE has been led astray by ACCESS and you know it. Point me to a featured list that has been promoted within the last year with a bold link in it. I challenge you. Go on. The Rambling Man (talk) 23:33, 16 November 2010 (UTC)

No, you're right. All infoboxes have bold links, and the guidelines suggest that that's just fine for a "caption". Well done MOS. It looks pitiful, but no reason to bend to the aesthetic appeal of 99% of our viewers in favour of no-one. The Rambling Man (talk) 23:39, 16 November 2010 (UTC)

(way too many edit conflicts) It took me 20 seconds. The first FL I found: Yeah Yeah Yeahs discography, promoted in March 3, 2009. Just so you know, the accessibility project entered in contact with the DISCOG in september 2010. I'm going to sleep, see ya! Dodoïste (talk) 23:41, 16 November 2010 (UTC)

Please make sure any "example" of captions for "data tables" etc you provide is fully MOS-compliant. Then there'll be no more problems. And let us know how "expert" this "expert" is, and then we'll start believing you. Don't give us another problem. DISCOG isn't the whole project. And rolling out changes to featured material isn't a matter for DISCOG, it's a universal issue. And you know that. So please, get your own house in order before trying to tell everyone else what to do. A half-arsed approach will just be a repeat of the alt-text nonsense, and no-one wants that, particularly as people who add good content to the Wikipedia wasted a lot of time complying with the advice of an "expert" who turned out to be a crock. See ya. The Rambling Man (talk) 23:46, 16 November 2010 (UTC)

What turns out to be a crock is your constant false claims about MOSBLOD. I'm dead sick of that. Do you have some kind of bold phobia? Seems like you have much more to understand about MOS criteria than me.

If you have sensible comments to add, or relevant suggestions for improvement to share, please go ahead. But stop repeating pointlessly "Essjay controversy" and "MOSBOLD". It's completely false, you don't even know what you're talking about, and it's going us nowhere. I won't bother to reply to such lame comments from here on. Dodoïste (talk) 21:23, 17 November 2010 (UTC)

Disputed

So a good example actually makes the column widths differ from section to section? It may be accessible but it looks awful to regular viewers. The Rambling Man (talk) 23:51, 16 November 2010 (UTC)

Go trolling elsewhere. This tutorial is about accessibility, not layout. We can sure improve the layout, but it's not the main concern of this tutorial. Am I clear enough? You sure know how to make a fuss about details. Dodoïste (talk) 23:55, 16 November 2010 (UTC)

No, this is a data table tutorial. It has to get it all correct otherwise it should not be part of the MOS. Am I clear enough? The Rambling Man (talk) 23:57, 16 November 2010 (UTC)

Improve the column widths yourself if you feel like it. I would have done it when I would have planned the change with the corresponding project, anyway. But there is no emergency to do it now. If you feel like working on this trivial detail, you're mature enough to do it yourself. Dodoïste (talk) 00:01, 17 November 2010 (UTC)

Take a break you two. In principle, yes the focus of this tutorial will be access based but in practice no-one will take anything seriously with glaring errors. See "1st of April to 31th of March" in the colour section, for an example. Additonally there I thought col and row spans were a problem for screen readers. If what you offer looks worse (even if it is more accessible) people won't warm to it. My advice, take dispute tags etc. as constructive criticism. Rambo's Revenge (talk)

Agreed. All I ask if for a "MOS tutorial" to comply wholesale with "MOS", not just the bits it wants to. Lazy. Especially when projects use this "tutorial" as "gospel". Night all. The Rambling Man (talk) 00:04, 17 November 2010 (UTC)

@The Rambling Man: Graham87 was able to copyedit without placing a "disputed" tag, hopefully. The Rambling Man, you're really not helping me. I know you have good faith and all, but a real troll would help me just as much as you do now. Take a break or whatever, but stop focusing on details.

I do not understand your comment, Rambo's Revenge, but it seems useful and instructive. Please explain the issue with ""1st of April to 31th of March" in the colour section", it is not self-evident to me. Nor is "there I thought col and row spans were a problem for screen readers". But I'm sure it will be constructive, so please provide details. :-) Dodoïste (talk) 00:25, 17 November 2010 (UTC)

31st of March. And see the #Avoiding rowspan/colspan section above (you even commented there). The second supposedly good table uses col spans. This is why things need to be consistent. Advice in one part of the tutorial is ignored in other tables. Rambo's Revenge (talk) 00:30, 17 November 2010 (UTC)

Done, thanks. The advice about rowspan/colspan does not cause any issue with most assistive technologies, and is not supposed to cause any. The advice about rowspan/colspan is supposed to be ignored. Or should I say, I wrote it because some users at the accessibility project believed there was an issue with rowspan/colspan. I wrote it to explicitly say: the issue with rowspan/colspan is negligible, and not considered to be an issue by WCAG 2.0. Any attempt to remove rowspan/colspan will be refused by users anyway, so it's not even worth trying. Dodoïste (talk) 00:38, 17 November 2010 (UTC)

I intended to move those guidelines to a dedicated page to prevent such confusions a long time ago. It's now done: Wikipedia:Manual of Style (accessibility)/Data tables tutorial/Internal guidelines. Thanks. :-) Dodoïste (talk) 01:07, 17 November 2010 (UTC)

Thanks Rambo's Revenge for placing tags at the top of the page that reflect correctly the issue. Could you point out some example of inconsistencies between this guideline and others, like MOS? That would really help me. Because, apart a few false claims about MOSBOLD, I don't see any inconsistency. Of course, I haven't read most MOS guidelines, and I'm only "en-3" - not a native speaker. Still, no matter how hard I think, I don't see any evident issue. Yours, Dodoïste (talk) 21:32, 17 November 2010 (UTC)

If no valid example of inconsistency with other guidelines is provided in a few days, I will remove the tags at the top of the page. Dodoïste (talk) 01:19, 19 November 2010 (UTC)

Just like I thought, there is no valid examples of inconsistencies. Only false claims about MOSBOLD. I'll remove these tags. Dodoïste (talk) 14:33, 21 November 2010 (UTC)

Specify

Please specify the expert and his relevant experience. We don't want another Essjay controversy, do we? The Rambling Man (talk) 08:34, 18 November 2010 (UTC)

So you want published evidence that an anonymous user account is owned by an expert? Impossible, Wikimedia does not make such authentications. I have any number of proofs that user:Lgd is an expert, but the Wikipedia account is anonymous and will forever be.

The expert has not allowed me to reveal his identity, he wants to remain anonymous to some extend. Like I wrote before, get another expert to review this page. If you feel the necessity, at least. There isn't any controversy worth it for now, on my point of view. But I understand that you want to prevent issues. Then get another expert to review the page, one that allows to publish his name. Contact WebAIM. I won't do it for you. I'm not your personal secretary and I'm not supposed to work hard trying to fix every small issue that you bring up. DIY.

I did provide this reply several times now. I've been patient enough with you. I've told you about the expert being an author of the renown RGAA. I've suggested to contact other experts (WebAIM), to have a third party review the page. But you don't even care about my replies, and you keep asking the same question, over and over again. Unless you change your attitude and become cooperative, I won't discuss with you any further. Dodoïste (talk) 01:15, 19 November 2010 (UTC)

Never mind. The Rambling Man (talk) 08:09, 19 November 2010 (UTC)

Tooltips

Why does this "tutorial" include information that you only see if you "hover" over it, in direct contravention of WP:ACCESS which states "Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text."? The Rambling Man (talk) 19:14, 2 January 2011 (UTC)

The mouseover effect comes from the use of the html tag <abbr>. A screen reader will then read correctly the months abbreviated into a letter (JFMAMJJASOND). The use of the alt parameter for images also causes hover effect. --Anneyh (talk) 10:29, 3 January 2011 (UTC)

Okay, so this is a little confusing because the screen reader will read JFM etc without the tooltips. The guidance saying to not use tooltips/hover tips etc seems strange in light of the example which moves from plain text to text with tooltips/hover tips. The Rambling Man (talk) 10:37, 3 January 2011 (UTC)

In the case of JAWS, it won't expand the abbreviations in the <abbr> element unless the user asks it to do so. Unfortunately, it also gives no indication that there is a tooltip. IMO use of the abbr element is harmless, but not usually benificial, for JAWS users. Graham87 14:25, 3 January 2011 (UTC)

Sorry, I should have said may read. Actually in the case of monthly tables, using Jan, Feb, etc. could be a better practice for everybody ? BTW is it a common practice to get negative examples of articles in a tutorial? --Anneyh (talk) 14:38, 3 January 2011 (UTC)

I'm trying to establish why tooltips arrive in the "good" example. It is implied that these are part of the "good use of colors" modification, whether that's the intention or not. I don't think, unless they are explicitly discussed, they should be used in this example, as it is confusing (as I found). The Rambling Man (talk) 16:00, 3 January 2011 (UTC)

(EC) Using three-letter month abbreviations and removing the tooltips sounds like a good idea to me. Graham87 16:01, 3 January 2011 (UTC)

I added an exception for abbreviations in the guideline about tooltips. The {{abbr}} template is using the semantic tag "abbr" that was specifically made to improve accessibility. It is always better to have J. than "J." as it explains the abbreviation. The fact that most screen readers do not read the out loud by default (unless asked to) is an issue specific to screen readers. And most screen readers provide an preference setting to allow users to choose if they want all abbreviations to be spoken out loud by default or not. Of course it's not perfect. But it's not perfect today, and screen readers might find a better solution later on.

Concerning their presence in this tutorial, they are not needed. Abbreviations are low priority, and are not the subject of this tutorial. They can be removed if it appears that is confuses editors (as The Rambling Man suggests).

Using three-letter month abbreviations is indeed a good solution, when there is enough space to allow it. But even then, it should still be marked as an abbreviation. For example, {{abbr|Jan.|January}} produces Jan. Regards, Dodoïste (talk) 21:31, 15 January 2011 (UTC)

"plainrowheaders"

It seems this is used indiscriminately throughout this "tutorial" without any advice as to why or how. It needs to be discussed otherwise the unbold scoped row headers will be confusing to users. The Rambling Man (talk) 20:33, 2 January 2011 (UTC)

Sure, will do. I did not find it necessary at the moment. But seeing the questions below it is necessary indeed. Dodoïste (talk) 02:58, 2 June 2012 (UTC)

Sortability/unsortability and scope

I tried to edit a table to include the "scope" parameters. The table has class="wikitable sortable", and two of its five columns are unsortable. I found that adding ! scope="col" clashed with the class="unsortable". Is there a way around this? In case my explanation is as clear as mud, the table I was trying to change was in Listed buildings in Poulton-le-Fylde. --BelovedFreak 13:17, 19 February 2011 (UTC)

Sorry for not having replied earlier, I was on a break and did not see your message. There should normally not be any kind of problem while mixing ! scope="col" and class="unsortable". It appears to me you managed to solve your problem in the meantime, isn't it? However, if you still need assistance, or if you have questions about accessibility, feel free to ask. Yours, Dodoïste (talk) 23:04, 2 June 2012 (UTC)

Colspan/Rowspan and colgroup/rowgroup scope

I've noticed there's not really any mention of the use of merged headers in using "colspan" and/or "rowspan". I've also noticed in looking at the source material that when setting the scope of a header, not only can it be set to "col" and "row", but also "colgroup" and "rowgroup" for those merged headers. It seems a good idea to mention that here somewhere to get this as accurate as possible. Now if we shouldn't be using merged headers, then none of what I've just typed means much and everyone can ignore this.  Afaber012  (talk)  06:34, 26 August 2011 (UTC)

Sorry for the long wait. I was on a break and did not see your message.

Colspan/Rowspan: it's best to avoid these when you can. Although, if you use it for data table and not for layout, it's okay. But only merge cells that contain the same information. Concerning headers, If you have one first row header, and several sub-row headers, you might want to use rowspan to make the first row header. Need an example?

Colgroup/rowgroup scope: This code is available, and could be useful indeed... but for whom? Me, you, and some developers? We can do everything without this feature, it does not add any functionality. It only enable more efficient formatting of tables. As always, the price is an increase of code complexity for 99% of users. Our users are already leaving because of this issue, and I'm not going to make this worse. Yours, Dodoïste (talk) 21:19, 6 June 2012 (UTC)

Colgroup and rowgroup are required to make complex tables accessible. See irregular tables. Thisisnotatest (talk) 22:43, 6 June 2015 (UTC)

WP:AWB and plainrowheaders

I have noticed recent edits by AWB that are adding "plainrowheaders" to the preamble class="wikitable" on tables, and the edit summaries pointed me here to WP:DTT. I was rather surprised to find no mention of plainrowheaders in the tutorial, so I am wondering if this is a valid rationale for AWB to be adding them, and what exactly it is fixing or extending here? Elizium23 (talk) 21:51, 9 May 2012 (UTC)

Sorry for the long wait. I was on a break and did not see your message.

"plainrowheaders" only affect the layout. It makes row headers look "plain", more like a normal cell, so it doesn't stand out. "plainrowheaders" is not necessary, but it's also harmless. Adding it with AWB might add more consistency, but might also displease users that like bold row headers.

Could you provide links to the edits you mention? Yours, Dodoïste (talk) 03:04, 2 June 2012 (UTC)

I have added a section about layout and plainrowheaders in the tutorial. Cheers, Dodoïste (talk) 03:34, 2 June 2012 (UTC)

Thanks for responding. I haven't seen any of these edits since around the time I posted the original message here. I should have added diffs at the time; they have long fallen off my watchlist and out of my short memory. I can't honestly think of a compelling reason to introduce it into most articles. It seems to me that it might help if there is a lot of text in the headers, and bolding them causes the font to be larger than usual? Otherwise, I would think that bolded row headers slightly aid in distinguishing them from data cells. Elizium23 (talk) 06:08, 2 June 2012 (UTC)

OK. I agree with you, as I also like to distinguish row headers from data cells. And I would not encourage to blindly add "plainrowheaders" to each and every table.

"Plainrowheaders" was created for users who refused to make row headers because of the bold. And this strategy was successful, these editors started to make row headers with "plainrowheaders". It improved accessibility. :-)

According to the description of events you are reporting, it might have been applied to a set of articles within a wikiproject. If decided by a wikiproject, that might be perfectly in the intent of "plainrowheaders". It's only a hypothesis though. Yours, Dodoïste (talk) 09:29, 2 June 2012 (UTC)

Column headers in the middle of the table

Removing column headers that span several rows by dividing the list into smaller tables, each with its own caption header, makes sense in the good example listed on this page. But what is the protocol when it is necessary for the table to remain as one for sorting purposes, as in, for example, List of Hot 100 number-one singles of the 2000s (U.S.)? Dividing up the table here would mean sacrificing the ability to sort within the entire decade. What's the standard practice in cases like this? Thanks, A Thousand Doors (talk | contribs) 00:41, 1 June 2012 (UTC)

Interesting question indeed. :-) Fortunately there is another way. I would add a column "year", and place it as the first column. Thus, years like "2000" can be set as row headers spanned across several rows. The "years" column can be sortable too, thus it even improves your table.

I'll post an example of my suggestion at Talk:List of Hot 100 number-one singles of the 2000s (U.S.). Yours, Dodoïste (talk) 00:30, 2 June 2012 (UTC)

That seems like a good idea. Thanks a lot for the suggestion – I'll start implementing it into some of the lists that I update. So cells that span over several rows are allowed under MOS:DTT? A Thousand Doors (talk | contribs) 17:41, 3 June 2012 (UTC)

Yes, spanned cells are allowed when they are merging cells that contains exactly the same data. Instead of repeating 12 times "2000" we can merge them into one cell.

Concerning accessibility, most screen readers and accessibility-related tools support spanned cells. For example, the most popular screen reader JAWS support it since 2005. It is true that some seldom used software does not support spanned cells, but it is their fault for not being up-to-date. So spanned cells is not a problem for accessibility.

We are not promoting spanned cells, because they can easily be misused. For example, when a cell is empty in a table, users might try to merge it with a nearby cell containing a different data for aesthetic purpose. That should be avoided, because it provides wrong information to screen readers and machines trying to extract and reuse the data.

In conclusion: we should remain cautious about using spanned cells, but it is allowed under MOS:DTT. Dodoïste (talk) 21:13, 3 June 2012 (UTC)

I made a slight change about the new table I suggested at Talk:List of Hot 100 number-one singles of the 2000s (U.S.). In this case, it might be preferable to mark the years ("2000", "2001") as normal data cells, instead of row headers. The year of the single is a vague information that is not specific to the row. Thus it is not useful to mark the row as a header. But that is only a detail, and both versions are acceptable. Yours, Dodoïste (talk) 21:22, 3 June 2012 (UTC)

Compromise about rowspans

I leave this information for further reference. I am thankful to Spinningspark for his dedication to find a compromise concerning table that were hard to improve. The result improves greatly accessibility. It's a step-by-step approach: we can't reach top-level accessibility right away, so we make several small improvements over time.

However, we cannot add this example in our guidelines as a good example. It not a perfect example, and it is in contradiction with the previous guideline about rowspans. I'm okay with leaving it in the internal guideline, but I'm going to rephrase a few lines. As it is, I fear some readers might thinks "yaaay I can make rowspans, no problem". Thanks for your understanding. Cheers, Dodoïste (talk) 20:30, 6 June 2012 (UTC)

I only put the example in here because I was asked to keep a permanent record of it for future reuse. I am apalled by the intolerant attitude over this. You are making the whole thing so difficult that I am not really inclined to even try to take accessibility into account in the future. Why you have to have a disclaimer saying this is incorrect structure is beyond me, the whole point was to give it a structure that could be understood by screenreaders. I am totally failing to understand why it is against advice on rowspans - the two rows spanned are both indexed to "K" so what is wrong with that? Why is it necesssary to aay in the disclaimer it might not be any use to other disabilities? I would be interested to hear what disability would have difficulty with it. The idea that it does not have semantic structure is ridiculous, great trouble was taken to ensure that every cell has a meaningful vertical and horizontal index - that was the whole point of it.

Frankly, you may as well delete the whole thing, it isn't worth shit without a code example to explain how to actually achieve it. SpinningSpark 23:19, 6 June 2012 (UTC)

I did not meant to discourage you. I wanted to find a more thoughful way to do this, but I did not manage. I'm human, and I failed here. Sorry about that.

Concerning people with disabilities that would have trouble using this table. Sighted people with cognitive impairements, or users with dislexia and long term memory issues like to use a text-to-speech software to read tables aloud. They would use it in a different way than a very smart blind user such as Graham87. When navigating the table, they are going to ask their software what cell is related to which header, in order to lnow where they are in the table at any given time. And that's only 2 cases, there are people with multiple disabilities out there. As a student in occupational therapy, I've worked with people with a lot of different disabilities.

Now, your efforts are appreciated, as you are going in the right direction. Please don't give up. Yours, Dodoïste 213.55.184.161 (talk) 04:54, 7 June 2012 (UTC)

Why will any of those groups have more difficulty reading my example table than any other table? My table is specifically designed so that the software correctly reads "what cell is related to which header", that was the whole point of it. Why do I have to keep remaking this point?

The idea that we need to structure articles for the benefit of people with dyslexia and memory problems utterly horrifies me. Tables would be the least of the problems here (and I am still failing to understand why they would have a problem with tables). Everything would have to be written to the lowest common denominator. We would end up with something like Simple Wikipedia - making that project superfluous and Wikipedia infinitely less rich. SpinningSpark 10:53, 7 June 2012 (UTC)

Let me explain. It is true that the long description is under the header "Extended comments". But at the same time, it is a cell spanned under several other headers ("Maker", "No.", "Owner", "Type", "Winding", "Comments"). This cell has 7 headers, and only one is correct.

Now Graham87 uses his JAWS with specific options, and in a manner that correspond with his bright mind. He's able to grasp the structure of the table very quickly, and adapt himself. Blind people with cognitive disabilities, or multiple disabilities, or people that are new with using a screen reader... might have a hard time. As you can see, we are not reducing the quality of contents for everyone. We keep the contents and make it accessible. It's like making video subtitles for the deaf, the content does not changes but becomes accessible. There is no point in deleting videos that does not have subtitles, what a strange idea.

Sorry about the mention of dyslexia, that was stupid from me. I wrote this answer in a hurry this morning and I made a mistake. :D I was thinking about people who have trouble to identify the way things are organized and structured, which is rather related to cognitive issues.

Anyway, I hope you understand better now, and that we will be able to improve our understanding of each other. Dodoïste (talk) 21:42, 7 June 2012 (UTC)

Table captions

There seems to be an increasing use of table captions in compliance with MOS:DTT, but which seem to be causing more problems than they fix. For example, in TV season articles it's common to have a "Ratings" section with multiple tables laid out something like this:

== Ratings ==
=== U.S. ratings ===
<ratings table without caption>

=== Canadian ratings ===
<ratings table without caption>

=== Australian ratings ===
<ratings table without caption>

=== U.K. ratings ===
<ratings table without caption>

== References ==

In order to comply with MOS:DTT, articles are being changed to this format:

== Ratings ==
<ratings table with caption "U.S. ratings">
<ratings table with caption "Canadian ratings">
<ratings table with caption "Australian ratings">
<ratings table with caption "U.K. ratings">

== References ==

Removing the L3 headings results in an inability to navigate quickly to the table from the TOC. I have a copy of JAWS on my PC and replacement of L3 headings with table captions seems to be an issue because it takes longer to find the required table using JAWS. In the first example it's possible to jump directly to the table, while in the second it's necessary for JAWS to read each table's header information. At Two and a Half Men (season 9)#Ratings, for example, JAWS says "Table with eleven columns and twenty-six rows" before it says "U.S. Nielsen and DVR ratings" At this point the reader is forced to manually skip to the next table where they'll hear "Table with four columns and ten rows", after which they hear "Canadian ratings". After deciding that's not the table that they want they have to manually skip to the next table again and so on. Restoring the section headings eliminates this but then there is another issue, that of heading/caption redundancy. If there is already a section heading and the first or only content in the section being a table, why is a caption needed? It's only one more thing that the reader is bombarded with. The section heading already tells you what the content of the table is, so the table caption seems redundant in this case. There are certainly a lot of cases where captions should be included (This is one) but there are cases where they're unnecessary, and in some cases detrimental to improving accessibility. I think this needs to be pointed out in the MOS, as a lot of editors believe that they're mandatory. --AussieLegend (✉) 03:15, 23 October 2012 (UTC)

You have a good point AussieLegend, thanks for having spent this much effort to bring valuable information. :-)

Before changing MOS guidelines we have to do further analysis and gather more input. Especially because there are two ways to look at this issue. The first is the one you described, where our tables might create a problem for JAWS users. The second is that JAWS may not behave is it should, and perhaps it should spek the table header first. Or provide an easier way to navigate tables. Maybe other screen readers are better at this. Who knows, there might be more things to take into account here.

I'll ask other to share their opinions on the matter. Thanks again. Dodoïste (talk) 13:54, 23 October 2012 (UTC)

Another way to navigate to a table in JAWS is by using control+JAWS key+T to generate a list of tables on a page. (The JAWS key is either insert or capslock, depending on whether you are using a desktop or laptop keyboard layout, respectively). I'm a little surprised to find out that this feature has been around since JAWS 6.0! Each table is labelled by its caption or by the column headers if a caption is not present, so the captions do help a screen reader user to navigate the tables that way. However the TOC method probably works with more screen readers; there is no keystroke to make a list of tables in NVDA, for example. It would theoretically be best to allow for both methods of navigation, but that would introduce redundancy, as discussed above. Graham87 15:09, 23 October 2012 (UTC)

Thanks Graham for your valuable explanation. I was going to ask your opinion, but you answered before that. :-) Oh, by the way, I've always wondered how smileys are read in a screen reader. Do you prefer :-) or "smile" in full text? Or perhaps I could add an icon with alt text... Which one is best? Dodoïste (talk) 18:28, 23 October 2012 (UTC)

They're read out as "colon dash right paren" by default in JAWS, but I personally have punctuation at a lower level than the default so they didn't read at all until now. I usually just scanned the text word by word if I thought there should have been an emoticon there so I could find it. But now I've added ":)" and ":-)" to the JAWS dictionary manager, so they both read out as "smiley". Graham87 01:37, 24 October 2012 (UTC)

Ever since Graham told me that he finds it quicker to use headings than captions, I've been advising editors not to use captions where they would duplicate a heading immediately above the table as the caption is rather redundant in those cases. However, if there is a substantial amount of introductory text between a heading and the table, then I believe that a good case can be made to use a caption, even if it duplicates the heading. How much text is 'substantial' is a judgement call, but if we take the case of a JAWS user who revisits a page and wants to go directly to a table, we don't want them to jump to the relevant heading then have to plough through lots of text before they can reach the table. It's that inconvenience we can circumvent for JAWS users by adding a caption.

There's also the point that a caption makes a table 'self-contained' for a re-user to take just the table, but I feel that is a minor consideration compared with making life easier for visually impaired visitors. I'd recommend refining MOS:DTT to allow no captions when they would merely duplicate a heading just before the table. Hope that helps, --RexxS (talk) 19:46, 23 October 2012 (UTC)

I would support your suggestion. The criterion of substantial text is a good guideline for editorial judgement. I would be happy to eliminate redundant captions where there are already section headers, I have had a few tiffs with editors about this point in the past. Elizium23 (talk) 21:35, 23 October 2012 (UTC)

Just like Elizium23, I support RexxS proposal. I recall several heated discussions about table captions redundant with headings. Editors are reluctant to create redundancies, thus it is an obstacle to the adoption of this guideline.

However, I would prefer to keep both the headings and the table caption. Because they are both semantically correct and useful. We could visually hide redundant table captions with a style like "top:-100000px". Hiding things "left" breaks RTL compatibility, but hiding things "top" does not break anything as far as I know. I'm normally reluctant to display such ugly tricks to the community of editors - fearing that they may reuse the technique in a bad way. I hope that hiding the code in a template and displaying a warning that it should not be used for other purpose without approval should provide sufficient protection though. What do you say? Dodoïste (talk) 22:46, 23 October 2012 (UTC)

I don't really see any problem with including a table caption when there is any text between the heading and the table, even one or two sentences seems "substantial" enough in most cases. An editor recently went through The Big Bang Theory season articles, adjusting column widths so they'd appear consistent in List of The Big Bang Theory episodes. (Column widths are an issue for articles being nominated for "Featured" status.) He also added captions to the episode tables, which is appropriate at The Big Bang Theory (season 1)#Episodes and even The Big Bang Theory (season 4)#Episodes, even though though the season 4 article includes only two lines at 1280px width. The table caption is redundant at The Big Bang Theory (season 6)#Episodes, but use of the caption is consistent with the five other season articles, so even the use of {{main}} in that article seems "substantial enough" text to justify use of the caption. --AussieLegend (✉) 00:49, 24 October 2012 (UTC)