Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial
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:
| Title | Album details | Peak chart positions | Sales | Certifications | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| US | AUS | AUT | FIN | NLD | NZ | NOR | SWE | SWI | UK | ||||
| Bleach | 89 | 34 | 26 | 24 | — | 30 | — | — | — | 33 | 1.7 million (US) | Platinum (US) | |
| Nevermind |
|
1 | 2 | 2 | 1 | 5 | 2 | 2 | 1 | 2 | 7 | 10 million(US) 26 million (worldwide) |
Diamond (US) 2× Platinum (UK) |
would become:
| Title | Album details | Peak chart positions | Sales | Certifications | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| US | AUS | AUT | FIN | NLD | NZ | NOR | SWE | SWI | UK | ||||
| Bleach | 89 | 34 | 26 | 24 | — | 30 | — | — | — | 33 | 1.7 million (US) | Platinum (US) | |
| Nevermind |
|
1 | 2 | 2 | 1 | 5 | 2 | 2 | 1 | 2 | 7 |
|
|
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)
- I do agree about the widths. Widths do make the table look prettier. But they should be made of
emrather than pixels. A good practice that I forgot to apply here. Thanks for reporting. :-) - I agree about
style="text-align:center"as well. - 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.
- I do agree about the widths. Widths do make the table look prettier. But they should be made of
- 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)
- 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 withclass="wikitable"? Cellpadding would definitely be the simplest solution. - If cellpadding are used it also solves the issue with centered text as text becomes centered by default:
align=centerbecomes useless. Regards, Dodoïste (talk) 17:29, 12 September 2010 (UTC)
- 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
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:
| Title | Album details | Peak chart positions | Sales | Certifications | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| US | AUS | AUT | FIN | NLD | NZ | NOR | SWE | SWI | UK | ||||
| Bleach | 89 | 34 | 26 | 24 | — | 30 | — | — | — | 33 | 1.7 million (US) | Platinum (US) | |
| Nevermind |
|
1 | 2 | 2 | 1 | 5 | 2 | 2 | 1 | 2 | 7 |
|
|
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)
Images and color
Collapsible tables can also work without the faux header:
| Country | Purpose | J | F | M | A | M | J | J | A | S | O | N | D | J | F | M | A | M | J | J | A | S | O | N | D |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Australia | 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)
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)
- 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)
- 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)
Scope etc.
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)
- 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)
"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)