Wikipedia talk:Manual of Style/Accessibility

WCAG Samurai

Hi, I've just noticed that the WCAG Samurai finally released in June a draft of its WCAG 1.0 errata. This errata is not published by the W3C but by a group of accessibility experts, but I think they are sound and a real improvement updating these guidelines to current web technologies. For example, I've just removed the requirement to use an HTML 'summary' attribute to data tables [1] as explained in the errata. It's true that actually nobody uses it (neither me), and it doesn't offer any real accessibility improvement (the same info can be written in the article's text, so it will be available to every reader).

The drafts of the second W3C accessibility guidelines, WCAG 2.0, have been very criticised, so from my point of view we should stick with WCAG 1.0 + Samurai errata. What do you think? Cheers —surueña 13:02, 15 December 2007 (UTC)

Wheelchair article

Resolved

 – Screen reader, etc., now linked, no further complaints in over 7 months.

30-Jan-2008: One of the problems I have with the article "Wikipedia:Accessibility" is that it hit me like "Here's the wheelchair article but anyway". Perhaps a short paragraph should be added to explain the term "browser" versus "screen reader" and such: it could be linked to the lede section as one sentence linked to a fuller section later in the article. -Wikid77 (talk) 10:50, 30 January 2008 (UTC)

1001 Wikipedian Nights

Resolved

 – Guidelines are not articles, and WP:LEAD doesn't apply; ToC provides 11 (close to 10) such desired bullet points. No further complains in 7 months.

30-Jan-2008: Although no one is buying time by making the article a "shaggy dog story" in the sense of 1001 Arabian Nights, the article seems to be a long, rambling laundry list of issues. The article needs a short, succinct intro section to summarize "Ten Things I Hate about You and Your Writing" to, at least, try to focus on ten guidelines a writer should know before losing interest in Wikipedia. (Actually, the Top 7 would be better, but the Top 10 is probably needed to accommodate the current rambling). -Wikid77 (talk) 10:50, 30 January 2008 (UTC)

Thou hypocrite

Resolved

 – Complainant resolved much of problem him/herself, and guideline is frequently worked on by others (WP as usual); no new specific complaints.

30-Jan-2008: The article "Wikipedia:Accessibility" seems to violate so many aspects of accessibility and readability that it hit me like wiki-hypocrisy. If everything in Wikipedia weren't already iffy, I would have recommended pulling this "advice column" until after trying "Physician, heal thyself" to make the article more readable and usable. Within just a few sentences, the article starts talking about "TOC" with no concern to try showing "table of contents (TOC)" to introduce the acronym. Also, there's really no lede section summarizing the issues being presented. OMG, just think: with unknown acronyms and no lede section, just imagine how unreadable the remainder of the article could be. I won't generate a laundry list of complaints: people simply need to realize the article needs to be rewritten, then ask for reviewers. Guidelines need to be written to the highest standards, above just featured-article content. -Wikid77 (talk) 10:50, 30 January 2008 (UTC)

Skeleton crews

30-Jan-2008: In most areas of Wikipedia, the content is being written and condensed by mere "skeleton crews" of volunteers: even the guidelines are revised by just a relative handful of people. For that reason, the content is often hollow, sparse, and marginal, as compared to writings by full-time staff writers. As a consequence, the Wikipedia policies rarely get the help and reviews that are needed. No one should feel blamed for the lowered content; it is a monumental task even if there were full-time pay. -Wikid77 (talk) 10:50, 30 January 2008 (UTC)

Merge with technical

Resolved

 – No one else interested in thread in which proponent !votes against own proposal, in over 7 months.

30-Jan-2008: Should article "Wikipedia:Make technical articles accessible" be merged with article Wikipedia:Accessibility?

• Heck no. Overly technical articles might be only 2% (if that) of the total article base, hence 98% of writing does not need to worry about revising technical articles. I've tried simplifying dozens of those very complex articles (see: Discrete Fourier transform), and I recommend a spinoff guideline to address the ultra-intellectual issues of technical writing. Just try simplifying several of those "too technical" articles ("{{technical}}"), and it becomes clear that there are numerous high-tech issues to address, beyond where to place an infobox. -Wikid77 (talk) 10:50, 30 January 2008 (UTC)

Re: "I recommend a spinoff guideline to address the ultra-intellectual issues of technical writing"... Um, that's what Wikipedia:Make technical articles accessible is. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:30, 31 August 2008 (UTC)

Text size

As a person with good corrected vision, I find the {{Reflist}} text too small for comfortable reading, this must be worse for those with more serious visual problems. The accessibility guidelines have nothing to say on type size, perhaps something should be added? Rich Farmbrough, 10:07 18 February 2008 (GMT).

Just my thoughts here. The difference between the main text and text in {{Reflist}} looks like about two points. On my computer the text in the references of Road appears to me the same size as text on the front page of the Seattle Times, so I don't see a problem. I think most people expect to see references supplied in font size that is smaller then the main text, it is what we usually see in print and bound books. I should also add that I have played with just about all my computer and browser settings for font size, so what I am seeing may not be the same as what a user on a virgin system is seeing. Jeepday (talk) 15:03, 18 February 2008 (UTC)

Currently, mediawiki:common.css is defining .references-small { font-size: 90%;}

I'd thought there was some agreement somewhere that 92% was the smallest we should use anywhere, but I can't find the discussion I'm looking for currently. (See Template:FootnotesSmall and its talkpage for a bit of discussion about 92%)

However, as long as we're allowing text to be resized by the user manually, such that they can increase fonts with their browser whenever needed (ctrl-+ and ctrl-− in firefox), I don't think we need to change anything drastically. Because user defaults (browser program/settings, OS font settings, monitor size/screen resolution) vary so drastically, we can't be perfect for everyone. -- Quiddity (talk) 18:59, 18 February 2008 (UTC)

Rich just added the issue that I wanted to add. The Wikipedia is the only web site I regularly visit which has routine and ubiquitous use of small font sizes for matter that I want to read. I'm not going even attempt to reverse the decisions to use small fonts, but could there been a global setting in user preferences for minimum font size displayed (i.e. the floor of the font size). This would enable a person with a slight impairment such as myself to set it to 10 points, while people with greater impairment could set it to 12 or 14 points.

To points raised above: The problem really isn't in the browser but in the Wikipedia renderer (or any web page with combining extra large and extra small fonts). The comparison to printed media is not accurate: the printed page is analog, and monitor legibility of smaller fonts to the visually impaired doesn't scale in the same way. patsw (talk) 20:18, 18 February 2008 (UTC)

Note: I was comparing display font on the web pages Road and Seattle Times, Not print to web Jeepday (talk) 20:29, 18 February 2008 (UTC)

It seems to me that the only reason we use small fonts is to look like traditional designed-for-paper scholarly works. Rich Farmbrough, 20:42 18 February 2008 (GMT).

And to reduce the size of massive refs sections, eg William Gibson#References, which seem to bug some people. Personally, I'm often tempted to replace {{Reflist}} with <references/>, but don't simply to avoid low-priority arguments/reversions. -- Quiddity (talk) 21:37, 18 February 2008 (UTC)

Rather than switch conventions (a very low-priority, but very argumentative argument waiting to happen), it may be useful to know that an individual can fix this easily (just for them). One just adds

 .references-small { font-size: 100%; }

to your Special:Mypage/monobook.css.

Perhaps it might be worth gathering some similar options and including them in the preferences as a simple "visually impaired" setting. Personally, I've always used Firefox's minimum font size to globally fix this problem. It makes some sites look ugly, but honestly, they looked uglier before. JackSchmidt (talk) 22:25, 18 February 2008 (UTC)

Small text addition to guideline?

Can we add a line to this page about using small size text? It's a hindrance to people with poor eyesight, and even those with good eyesight (read me) find it a turn-off. Matthewedwards (talk • contribs • email) 06:45, 26 August 2008 (UTC)

Yes please. I've been asking for the same thing everywhere for ages. (Lots of relevant discussions at MediaWiki_talk:Common.css/Archive_4#Font_size_reduction and Template_talk:Reflist#Font_size and Template_talk:Reflist/Archive_2008#Font_size and somewhere:infobox and further up this very page at Wikipedia_talk:Accessibility#Text_size and probably lots elsewhere.) -- Quiddity (talk) 07:27, 26 August 2008 (UTC)

Infobox size doesn't bother me. Everything that is an infobox should be in the main prose of the article as well. References.. meh.. <references/> doesn't make them small, and should be used for articles where there's fewer than 20 references, I think. {{Reflist}} I suppose makes them smaller so the page doesn't take too long to load when there is a lot of references. Matthewedwards (talk • contribs • email) 07:59, 26 August 2008 (UTC)

Font size has no effect on page loading time. Using many citation templates will make the page slower to load; for a dramatic example of this, see United States. Graham87 11:16, 26 August 2008 (UTC)

Oh. OK. And since posting that I looked at those links, and I agree - reflist should either be made 100% or 95%. Matthewedwards (talk • contribs • email) 16:27, 26 August 2008 (UTC)

Is your complaint about the default font size (which is something you can easily change on your own computer), or about using different font sizes? WhatamIdoing (talk) 19:58, 26 August 2008 (UTC)

My complaint is about articles where the font size has been forced to be smaller. It often appears in lists and tables, such as at All-NBA Team. I haven't actually seen it used in prose. When I read the discussions provided by Quiddity, I am even more convinced that we need a line to say "no small fonts". And I shouldn't have to change my default font settings or add a script to my monobook, or anything else. The majority of our readers are not logged in, and they don't get to do that. Matthewedwards (talk • contribs • email) 03:41, 27 August 2008 (UTC)

Our implementation of <blockquote></blockquote> makes everything 85% too. Damned hard to read. (I'm making a note at MediaWiki talk:Common.css#Font sizes) -- Quiddity (talk) 04:26, 27 August 2008 (UTC)

Might you, however, encounter this problem on other websites occasionally? And might you be inclined to solve all your problems at once, in about ten seconds, instead of trying to reform each webpage one by one?

In Safari (browser), you go to Preferences>Advanced>Universal Access and tick the "Never use font sizes smaller than (fill in the box)" button. In Firefox (browser), you go to Preferences>Content>Font & Colors>Advanced and set the "Minimum font size" in the menu. I don't run the Microsoft browser, but I assume that similar features exist there, too. WhatamIdoing (talk) 05:30, 27 August 2008 (UTC)

Only on badly designed websites ;) Rather than just fixing things for myself, I'd rather help everyone else who is having problems, but who don't even know where to complain. You might like to read about Web accessibility, and contemplate all those barely-computer-literate users who access the web through library terminals. Think outside your own box of experience. -- Quiddity (talk) 05:50, 27 August 2008 (UTC)

Actually, I know several people with significantly impaired vision, and I haven't found any that don't know how to fix this for themselves. The issue here is that we can't predict what size font is going to work for all computers. If we declare that my default typeface (Times 16) is the minimum, then that's going to prove to be disruptively large for other people. This is a user-fixable situation, not a one-size-fits-all situation. And certainly if you have a problem with your computer's default setting, then you should fix your computer's default. WhatamIdoing (talk) 07:33, 27 August 2008 (UTC)

Lowercase article titles and DAB hatnotes

Resolved

 – Largely mooted by MediaWiki changes; order should be DAB first lc second for basic logic reasons.

The guidelines specify that disambiguating hatnotes should always go on top. Does this still apply in cases where the article uses the template {{lowercase}}? Or would having something above that template interfere with its function? Just wondering. --ShelfSkewed Talk 17:04, 7 April 2008 (UTC)

Interesting question, but I'm not sure what do you want to ask. AFAIK, initially this template just reported that the article's title must be in lower case, but due to technical limitations (MediaWiki features) it wasn't possible. Later, it added some JavaScript to "fake" the title (rendered it with lowercase, although MediaWiki really sent the page with the title in uppercase) but if JavaScript was disabled the fallback solution was to still render the old hatnote (so I suppose this is what all screen readers and text-only browsers showed, and thus accessible). But now it seems that MediaWiki implements a new attribute (DISPLAYTITLE) to really generate pages with lowercase titles. So now it doesn't matter when the {{lowercase}} is placed (from the POV of accessibility) because it doesn't generate a hatnote anymore, but IMO when it did that in the past it should be placed below the disambiguation links. Have I answered to your question? HTH —surueña 19:25, 7 April 2008 (UTC)

I think so, although I wasn't thinking about any hatnote generated by the {{lowercase}} template. The particular article I was looking at was Go! (airline), which the template causes to be rendered as go! airline in the title display. What I was wondering was, if the disambiguation template is placed above the lowercase template, will the latter template still lower-case the display--that is, will it still function as intended? When I moved the disambig template to the top, everything seemed to work fine in the "Preview" view, but in the "Show changes" view, the article title was rendered capitalized. So I moved the dab hatnote back down before I saved, in case it was messing something up. But you are saying that the {{lowercase}} template should function correctly no matter where it appears on the page?--ShelfSkewed Talk 19:47, 7 April 2008 (UTC)

Never mind: It does the same thing (give different displays in "Show preview" vs. "Show changes" view) even with the lowercase template on top. Poor scientific method on my part; I should have checked both ways when I first noticed the difference. --ShelfSkewed Talk 20:44, 7 April 2008 (UTC)

OK, understood. But note that I didn't said anything about the correct behaviour of {{lowercase}}, but about that this template doesn't have any accessibility issues with respect its placement at the page (I don't know if it has any restriction to work properly). Cheers, —surueña 23:10, 7 April 2008 (UTC)

It is usually more effective to simply go to a sandbox and test whether x will affect y than start talk page threads about it. If there's a problem revealed by the test, it would then be useful to use the talk page to suggest changes (or just go make them). — SMcCandlish [talk] [cont] ‹(-¿-)› 23:43, 31 August 2008 (UTC)

I just tested it, and the order has no effect on the performance of the templates. Logically, the DAB tag should go above the lc one, as the lc one operates on/is about this page, while the DAB is a meta-level above that, saying "this may not be your page". — SMcCandlish [talk] [cont] ‹(-¿-)› 23:51, 31 August 2008 (UTC)

Multiple columns in {{reflist}} deemed bad

Resolved

 – Just a pointer to another discussion.

"Howzat for a provocative headline, eh?" — superluser_tc

There have been some discussion on Template talk:Reflist about whether to remove multicolumn support from {{reflist}}. The simple solution would be to remove support for it in the reflist template, however, some users suggested it might be better to have a policy change? (I'm guessing they where referring to MoS?). So if you have any thoughts about that please consider taking part in the discussion.
— Apis (talk) 21:41, 15 May 2008 (UTC)

What the...?!

Resolved

 – Inconsistency fixed.

Anyone else notice that WP:ACCESS (in all uppercase) leads here, but wp:access (in all lowercase) leads to "make technical articles accessible"? Was this intentional, because it's messing me up and I can't be the only one...!? L'Aquatique[talk] 06:15, 18 May 2008 (UTC)

Fixed. -- Quiddity (talk) 17:52, 18 May 2008 (UTC)

Gadget proposal

Can I have some more opinions about adding a gadget to move the section edit links so that they are easier to use with screen readers? Graham87 14:00, 1 June 2008 (UTC)

I've just voted for the bug that fixed this in the software, don't forget to vote also for this one! BTW, also just noticed that there is a specific category for accessibility MediaWiki bugs, which is a good thing (and very encouraging, indeed). It's important to tag new accessibility related bugs with this tag, and add old bugs to this category (if all of us vote for them, they will be fixed in less time). I've just tagged a couple of old bugs. Cheers, —surueña 11:25, 3 June 2008 (UTC)

I read in some bug report that developers ignore votes. I can't remember where I read it, but I've seen many bugs which caused a lot of distress bug 9213 being an example, not being acted on for months. The accessibility keyword gives the bug a high priority, and I think adding that to all accessibility-related bugs is more importannt. Graham87 12:00, 3 June 2008 (UTC)

OK, understood. I searched and tagged more accessibility-related bugs, but there are surely more. Cheers —surueña 13:40, 3 June 2008 (UTC)

Navboxes need more flexibility

As currently written, WP:ACCESS demands that all navigation boxes be placed after the lead and before the table of contents. While I think this is fine for some navboxes, I can't support this approach for all navboxes in all articles, because of the three problems it causes:

• Implying an inappropriate level of importance. {{Cardiac glycosides}}, like hundreds of similar medicine-related navigation boxes is intended as a convenient alternative to manually adding long, identical lists of medication-related articles to See also in dozens of articles such as Digoxin. Putting it at the end of the lead is essentially putting See also at the end of the lead. It's obvious from the visual layout that this template was intended to be placed at the very end of the article: it runs full-width across the screen. Also, can you imagine anyone starting at Digoxin for the purpose of finding Proscillaridin?
• Screwing up the formatting. Look at what happens to the formatting at Phylogenetics if you move {{Evolution3}} after the text of the lead. The navbox runs down into the text of the next section. On older browsers, this could result in covering up text. (And on not-so-old browsers, either: In my entirely up-to-date browser (and given my font settings), the taxobox very slightly displaces an image so that it covers up the first four words at Plumeria#Etymology and common names.)
• Overloading the lead. A huge number of science and medicine articles have large infoboxes (sometimes called taxoboxes) -- particularly if you look at articles on medications or living organisms. Consider what happens when you have both an infobox and a navbox in the lead. Think about what Digoxin would look like if the navboxes were added to the lead. You'd have rather more screens of 'sidebar' navboxes than you would of text.

I think that we need to clarify in this guideline that not all articles should have all navigation boxes at the top. Navboxes in the lead should probably be restricted to shorter navboxes that are believed to be of immediate interest to the general reader, and even then only added to the lead in the absence of a large infobox (i.e., when it won't make subsequent sections illegible).

Furthermore, if the information in the navbox is essentially See also material, then it should be placed at the end of the article. Portals, for example, should probably be placed in the See also section in most articles. After all, if you're already at Plumeria, you probably want to read about these flowers instead of taking an immediate trip to Portal:Plants.

Does anyone object to clarifying these points? WhatamIdoing (talk) 18:54, 24 August 2008 (UTC)

I don't believe this guideline intends to demand that navboxes be placed in the lead, rather to state that when they are placed in the lead, they should follow the text. SandyGeorgia (Talk) 19:14, 24 August 2008 (UTC)

I'm all for clarification. So I don't mind. Butwhatdoiknow (talk) 20:27, 24 August 2008 (UTC)

I agree with SandyGeorgia, it doesn't try to enforce that all navboxes should be placed in the lead, but because the current practice is to put some (vertical) navboxes at the top of the article it is more accessible to move them below the lead than above it. Of course it doesn't suggest that those (horizontal) navboxes usually put at the bottom of the article should be moved to the top (is that your point?). But adding a clarification in the text can avoid any misunderstanding, so feel free to add it to that guideline. With respect screwing up the formatting and overloading the lead, this guideline doesn't create those problems because there are a lot of navboxes so long that will reach the first section even if it is placed above the lead. Maybe that's an issue with the CSS or browsers, I don't know, but IMO we shouldn't discuss that here. BTW, thanks for your interest in improving the guidelines, WhatamIdoing, and for all your updates, Butwhatdoiknow. Cheers, —surueña 20:54, 24 August 2008 (UTC)

I imagine that WP:ACCESS doesn't intend to demand that all navboxes appear in the lead, but it fails to provide for any alternatives. Compliance with this guideline is mandatory at FAC, so we really need it to authorize all of the possibilities (or to explicitly limit itself to the specific instances that it means to control). WhatamIdoing (talk) 22:11, 24 August 2008 (UTC)

I think this is the part that is missed:

• When the optional elements are used they should be in the following order:

It doesn't demand those items be in the lead; it says when they are in the lead, they should be in that order. That doesn't contradict, in my mind, the navbox guideline at WP:LAYOUT (which has navboxes at the end of the article), but I agree that we need more clarity here. SandyGeorgia (Talk) 22:25, 24 August 2008 (UTC)

Yes, a clarification can improve the wording here. Please, note that when I wrote that guideline what I had in mind was articles with up to 1 infobox, and one vertical navbox (both usually at the top) —and zero, one or several horizontal navboxes at the bottom— which was the common practice. But now it is very common to have more than one vertical navbox in an article, so this guideline should also recommend what to do with vertical navboxes placed outside the lead section (as Graham says below, they should be placed at the end of any section, just before another heading to be able to skip the navbox quickly to that heading). —surueña 09:14, 25 August 2008 (UTC)

White space

This is coming up more often now that I'm watching for it at WP:FAC, so I could use more guidance. When an infobox is very very very long, placing a vertical navigational box below the text in the lead results in an extreme amount of white space. So, editors have been placing the navbox under the infobox. This is a no-no per the guideline and for screenreaders. But I can't move it to the end of the text in the lead because it creates massive white space. And I can't move them to the end of the article because they are vertical templates and don't work well at the bottom of the article, where they belong according to WP:LAYOUT. Does ACCESSIBILITY on screen readers have any opinion on placing a vertical templates somewhere in a section in the middle of the article, below the lead? See the issues in my recent edits, trying to fix AMX-30E. I don't know how to solve that navbox, and the article nominator is questioning on my talk page what to do. This is the version before I moved the navbox down. SandyGeorgia (Talk) 21:04, 24 August 2008 (UTC)

The main problem I have with navboxes is moving past them to the rest of the article. I prefer them at the very end of the article for that reason, but before the TOC or at the end of a section is fine, because I can navigate past them by navigating to the next heading. Graham87 00:57, 25 August 2008 (UTC)

Is it just as easy to skip over the infoboxes? Why should an infobox go first, but a "sidebar" navbox be last in the lead? WhatamIdoing (talk) 07:14, 25 August 2008 (UTC)

Well, the idea is that whereas a navbox is a very long collection of links to related articles, and therefore many people are not interested at first in them, in theory an infobox is a brief summary of the article so you are interested in reading it before the lead. But maybe that assumption is wrong. What do you think, Graham? Do you usually read whole infoboxes, or do you skip them often? Can you skip to the lead section easily? In that case, maybe the infobox should be placed below the lead and the vertical navboxes below other sections. Cheers, —surueña 09:14, 25 August 2008 (UTC)

I just experimented with placing an infobox below the lead text, and I don't think that is something that the community would accept. It's unsightly. SandyGeorgia (Talk) 16:13, 25 August 2008 (UTC)

I agree. Infoboxes are very useful, and they should be at the beginning of the article, if not at the top at least just after the lead section. But I prefer to put them at the very top, as done now. —surueña 21:09, 25 August 2008 (UTC)

SandyGeorgia, after seeing your fixes to AMX-30E I understand your point now. It's true, that special kind of navboxes relying in the {{FixBunching}} template are an accessibility problem: they are designed to be placed just below infoboxes, and if you try to move them below the lead section the whole (graphic) layout will be broken (see [2]). I think that your decision of moving that navbox to the bottom of the article was the correct one, but those navboxes are designed to be placed below the infobox so we must find a solution and inform the authors of those infoboxes about the accessibility problems. Anyone with enough CSS knowledge to avoid breaking the layout when placing the infobox above the lead and those navboxes below the lead section? I will ask in Template talk:FixBunching... —surueña 09:59, 25 August 2008 (UTC)

Thanks ! But if I understand correctly, you're saying it's also possible to place a vertical navbox below the text in any other section in the middle of the article? SandyGeorgia (Talk) 16:13, 25 August 2008 (UTC)

Yes, from my POV that's accessible. However, I think that should be avoided for one reason: wikipedians actually don't read the guidelines / policies, they just repeat the conventions seen in other articles. And therefore, the rules must be very, very simple to be able to remember them. Initially it was very common to put the infobox above the dablink to "save space", but thankfully nowadays people have accustomed to put them at the very top (after several months seeing that articles were changed). That rule is easy to remember. We are also changing the images in the middle of articles, so people get used to see them just below headings or inside a section, but never just above a heading (when a level 2 heading is just before a level 3 heading, for example, I always put the image below the level 3 heading even if the image can also logically belong to the level 2 heading, to avoid seeing images just above any heading. See [3]). And it would also be easy to remember to put vertical navboxes just below the lead section, i.e. in front of the table of contents. If we also allow that vertical navboxes can be placed in the middle of articles, I think it would be harder to remember that images should be just below a heading and vertical navboxes just above. IMO that would lead to confusion (i.e. wikipedians would probably think that there is no rule so they put images and navboxes in any position). Maybe this is just non-sense, but I've been working with these rationale (please guys, let me know your opinion about this!). So IMHO I would say: the vertical navbox must be placed just above the TOC (but we must also decide what to do when there are more than one navbox within an article). What do you think? —surueña 21:09, 25 August 2008 (UTC)

Also (more navbox)

The text currently says: "Navigational boxes should be just after the lead section so a Wikipedian using a screen reader can jump to the table of contents without reading the whole navigational text."

What does this mean? "Please put a long list of articles before the table of contents, so we can find the table of contents more easily"? I thought that the entire point was to put the long list of articles before the TOC so that the reader could conveniently skip the rest of the article and go to a more interesting one, without having to skip to See also or end-of-article templates first.

If someone can explain to me the actual goal here, then I'll happily help wordsmith the rule. WhatamIdoing (talk) 22:19, 24 August 2008 (UTC)

I don't know, but it's easy to get to the table of contents because it's a second-level heading. Graham87 00:59, 25 August 2008 (UTC)

Graham, is a navbox at the end of a section in the middle of an article a problem? Some vertical navboxes don't lend themselves well to being placed at the bottom of an article. SandyGeorgia (Talk) 01:26, 25 August 2008 (UTC)

No, it's not. The idea is that an screen reader or a text browser a web page is serialized, so the goal is to be able to read in a logical order the article. Many articles have a dadlink and an illustrative image and caption at the top, for example. If the article has first the image and then the dablink, in a graphic browser it doesn't care much, but a screen reader would read first the image's caption, which is part of the article's contents, and after that will "jump" outside the article to read the dablink (and after that the lead section again). That's illogical, and can be a big problem to wikipedians with learning disabilities (well, that was I think, I haven't performed any experiment). The good organization is to first hear the dablink, then the image caption, and finally the lead (if after hearing the caption or the lead you realize that's not the article you are looking for, you can just jump to the top of the article again and click on the dablink). In the case of a navbox, the idea is that probably you don't want to hear the complete list of related articles, so you can just jump to the next heading (including the table of contents, which have an h2 header). If there is text between the navbox and the next heading (e.g. the whole lead section), you would miss that part of the article. But it doesn't matter if the navbox is just before the TOC or another heading, but the usual practice is to put them at the top of the article. I hope this can clarify the goals :-) Cheers, —surueña 09:32, 25 August 2008 (UTC)

Special cases

Some short articles have a very long vertical navbox, but they have so few sections that they don't even have a TOC. Therefore, the navbox cannot be place below the lead section (see for example [4], and [5]). So either we have to make here an exception, allowing the navbox above the lead section, or either disallow completely the long navbox (just a link to the main article in the see also section). Opinions? —surueña 10:24, 25 August 2008 (UTC)

I personally dislike vertical navboxes (see the next section) and wouldn't mind if they were banished from existence and all navboxes were standardized to horizontal boxes at the bottom of the article. But I have zero expectation that will ever happen, so ... SandyGeorgia (Talk) 16:18, 25 August 2008 (UTC)

I don't dislike them, IMO they are useful and provide uniformity to Wikipedia. Well, I like articles with just one vertical navbox, more than one is somewhat confusing. And I agree that it's very unlikely that people stop using vertical navboxes, even if a policy or guideline mandates that. In any case, we can just try to enforce a correct use from the point of view of accessibility, vertical navboxes aren't inherently inaccessible when correctly used. In this case, I don't really know if we can suggest that stubs shouldn't have those navboxes. —surueña 20:25, 25 August 2008 (UTC)

How I navigate pages with JAWS and my thoughts on navboxes

I can't find a good place to fit this reply, so I've created a new section for it. My screen reader JAWS uses quick navigation keys that can jump to the next HTML element of a specific type, get out of the current HTML element or go to the next different HTML element. Other modern Windows screen readers, including the free NonVisual Desktop Access, use a similar scheme. In JAWS, to get out of infoboxes, I press the ">" key to move to the end of the table, and to move to the TOC from the lead section, I press "H" to move to the next heading (as the TOC is a level 2 heading). My problem with navboxes is that there's no way to reliably get out of them by jumping past HTML elements. I usually use the "n" key (move to the next non-linked text block), but that usually gets me to the wrong place. Otherwise, it helps if navboxes are either at the end of an article or close to another HTML element (a heading, a table, etc). Here's a full list of JAWS keystrokes including Internet keystrokes. —Preceding unsigned comment added by Graham87 (talk • contribs) 14:38, 25 August 2008 (UTC)

And what about infoboxes? Do you usally skip them, or are a good summary of the article? —surueña 14:51, 25 August 2008 (UTC)

I think we're trying to solve a non-existent problem. Graham, could you take a look at Suicide note and tell me whether you can skip the first template there? WhatamIdoing (talk) 21:44, 25 August 2008 (UTC)

I can get close to the end of it with one keystroke. Moving to the first non-linked text moves me to the last item which happens to be a self-link for "suicide note", and moving to the next div tag moves me to the text "This box:", which is close enough to the end of the navbox. I can't move past the navbox with the table navigation keys because it seems to be a one-column table which JAWS considers to be a layout table, and by default, JAWS does not count those. As for Suruena's question, I use infoboxes to get a piece of information quickly, but otherwise I just skip past them. Graham87 06:09, 26 August 2008 (UTC)

All the navboxes I found today (well, yesterday) are fundamentally tables. Can you give me an example of a page that you can't get past (or at least very close to the end of) the navbox? WhatamIdoing (talk) 06:31, 26 August 2008 (UTC)

No, not the ones I've checked through. It seems that hitting "z" to go to the next division gets me out of the navbox most of the time, and if not, hitting "n" to get to the next non-link text will also work. I didn't think of moving to the next division to get out of navboxes before ... I'll keep it in mind. Graham87 11:16, 26 August 2008 (UTC)

So it shouldn't actually matter where the navboxes are placed then?

Placing a vertical navbox at the end of the lead is a layout problem. It looks a bit strange to have the navbox start at the top of the table of contents instead of at the top of the page (when there are no other images and no other infoboxes present), and a long navbox (longer than the table of contents) can interfere with the text of the next section. If it really didn't cause any more trouble for you than the typical infobox, then I'd rather put the navboxes at the top of a section instead of the end. WhatamIdoing (talk) 19:56, 26 August 2008 (UTC)

No it doesn't really matter where navboxes are placed. The trick for mooving past them I found isn't intuitive, but it works. Graham87 00:49, 27 August 2008 (UTC)

Thanks for your response. Since it doesn't actually matter for accessibility, and it does matter for visual layout, then I'll change the guideline to list them after the infoboxes instead of after the lead's text. WhatamIdoing (talk) 02:58, 30 August 2008 (UTC)

To make sure I follow. Vertical navboxes are now are OK after the infobox in the lead (although still preferred at the bottom of the article)? And if a vertical navbox is placed within another section, does it still need to be at the bottom of the section? Also, on updating this, the text is also at WP:LEAD and WP:LAYOUT, I think. SandyGeorgia (Talk) 03:05, 30 August 2008 (UTC)

Also, WhatamIdoing, I'm going to be traveling, so if this changes, if you don't mind, please make sure Tony1 (talk · contribs) knows so he can add it to the August monthly updates for the WP:SIGNPOST. SandyGeorgia (Talk) 03:07, 30 August 2008 (UTC)

eeek, a third question. WhatamIdoing, you put navboxes *before* images; are you sure about that? SandyGeorgia (Talk) 03:09, 30 August 2008 (UTC)

Sandy, I'd rather have your questions now, no matter how many, than a mess later. My intention was to put navboxes after infoboxes, because when both are present, the infobox is more important by far -- being, as it were, an actual part of the article instead of merely part of the navigation infrastructure -- and should appear at the top of the article (instead of much further down the page or in a later section).

However, since the infobox is actually part of the article, then (per other comments on general principles on this page) we should probably not have first some article (infobox) — then some not-article (navbox) — and then go back for the rest of the article. But I'm (a) open to other arrangements and (b) no longer certain that it makes sense to have infoboxes listed separately from navboxes at all. I invite other opinions. WhatamIdoing (talk) 04:53, 30 August 2008 (UTC)

The problem is many articles have all three: an infobox (with an image), followed by a separate image, followed by yet another navbox. We used to have them in that order. I no longer know what matters; would need to hear from Graham, but I'll be traveling and will probably lose track of this. And I can't think of a sample off the top of my head, but I've seen all three crammed into one lead. SandyGeorgia (Talk) 04:59, 30 August 2008 (UTC)

I don't thinkthis is as big a deal as spelling errors, broken tables, or things like that. I'd slighgtly prefer the image being before the navbox because a well-written image description will give important information for the article and I think the image is more important than a navbox. But this shouldn't be a hard and fast rule ... if it looks better for the image to be below the navbox, then put it there. Graham87 10:27, 30 August 2008 (UTC)

Update, navboxes before text

OK, so the preferred (not required) order is images before navboxes, and navboxes are now before the text, not after. I've updated this page as well as WP:LEAD and WP:LAYOUT; if anything changes, please sync those pages as well. SandyGeorgia (Talk) 13:11, 30 August 2008 (UTC)

Sidebars

Sandy,

Can you give me an example of a horizontal {{navbox}} used in the lead? I've never encountered it, and I have looked at some thousands of articles. (Many of which, I admit, display properly standardized navboxes created by Arcadian.) WhatamIdoing (talk) 22:48, 25 August 2008 (UTC)

The AMX-30E article raised earlier in this discussion (the nominator has now moved that to the bottom, but lots of editors do what he had done.) I can't think of any others right now, but I come across exactly that a lot. When the infofox isn't so long, or when there isn't an infobox, the horizontal nav works in the lead. The problem at AMX-30E was that, because of the long infobox, moving the horizontal navbox to after the text left a huge white space. SandyGeorgia (Talk) 22:53, 25 August 2008 (UTC)

Ah, I see. So it's not so much that it's a horizontal navbox as it's a tiny navbox. WhatamIdoing (talk) 00:41, 26 August 2008 (UTC)

By complete coincidence I saw the bit where it says navboxes in the lead and came to question it here. I've never come across this. Sandy, are there any current FAs where it can be seen? Matthewedwards (talk • contribs • email) 06:44, 26 August 2008 (UTC)

Family of Barack Obama family tree

What do people think of Family of Barack Obama ? Andy Mabbett | Talk to Andy Mabbett 22:43, 26 August 2008 (UTC)

You mean the family tree in Template:Obama family? That's impossible to read here - reading it with table navigation commands doesn't work. I prefer to read through the text to be honest. Graham87 01:08, 27 August 2008 (UTC)

Frankly, it's distracting, and I just don't think it adds all that much to the article. Plus, it's sort of difficult to read and actually glean information from. L'Aquatique[talk] 01:27, 27 August 2008 (UTC)

I've tried to cleanup the article itself (linked headers, self-redirects in the template, etc).

The tree-chart itself is using Template:Chart, which doesn't appear to be very widely used currently. It should possibly be using Template:Familytree (which is widely used) instead? I haven't time to investigate the differences between the 2 templates currently. Perhaps feedback/concerns would be best directed to their talkpages (or at least mention there, that we're discussing them here).

IMHO: Yes, bad accessibility. Would an imagemap would be a better way to handle these? -- Quiddity (talk) 01:29, 27 August 2008 (UTC)

Yeah, it'd probably be better with the image description like "John Doe (1800-2000"). Graham87 01:55, 27 August 2008 (UTC)

Familytree

{{Familytree}} still looks inaccessible to me - where are the table headers, the scope attributes, etc? How does it linearise? It's not tabular data, is it? Andy Mabbett | Talk to Andy Mabbett 19:36, 27 August 2008 (UTC)

I don't disagree with the fact that {{Familytree}} is inaccessible (or, as I prefer - one helluva convoluted template). But, in its defense, even when drawing family trees on a sheet of paper, they quickly become ridiculously complicated. I'm willing to take a shot on working on some code improvements if someone has a particular recommendation/suggestion. JPG-GR (talk) 19:45, 27 August 2008 (UTC)

[outdent] Accessibility isn't (at least not in this case) about complexity; this is the equivalent of drawing the family tree on paper, then placing it face-down and expecting someone to read it. If you can (and are sighted), view an instance of the template, in Firefox, using the "web Developer" toolbar with "miscellaneous - linerarize page" activated. Even after teh removal of huge anmuonts of white space, it looks like:

	Elimelech 	
 
	Naomi 	
 
 	Boaz 	
 
	Ruth 	
 
	Mahlon 	
 
	Orpah 	
 
	Chilion 	
  
	Obed 	
 
	Jesse 	
 
	David 	

See also Wikipedia:Accessibility#Layout tables

Andy Mabbett | Talk to Andy Mabbett 20:16, 27 August 2008 (UTC)

Firstly, thanks for showing me what another thing on Web Developer does (as a web developer, that toolbar is incredibly useful). As for this template, I see what you mean, but I'm not quite sure how to adapt the template. Short of having a prose explanation accompanying it, that is. JPG-GR (talk) 16:54, 28 August 2008 (UTC)

My pleasure; I love the WD toolbar! As for improving the template I think the first thing is to find good examples of accessible family tree mark-up elsewhere on the web. Andy Mabbett | Talk to Andy Mabbett 19:06, 28 August 2008 (UTC)

See also teh FT on Charlotte Brabantina of Nassau. Andy Mabbett | Talk to Andy Mabbett 22:43, 28 August 2008 (UTC)

That family tree is easy to read, but it's not a complex one. As far as accessible family tree solutions, Family Tree Maker is (or was) accessible with JAWS - see this mailing list thread among others for proof. Graham87 02:19, 29 August 2008 (UTC)

Tournament bracket templates

Please see {{16TeamBracket-Compact-Tennis5}} and other members of Category:Tournament bracket templates which contain tables which seem to me to be very inaccessible. Thank you. Andy Mabbett | Talk to Andy Mabbett 19:30, 27 August 2008 (UTC)

Like at 2005 U.S. Open - Men's Singles ... those tables are very hard for me to read, and I can only make some sense out of them because I know a bit about tennis and the fact that a set usually has six games. At the very least they need to have column and row headers. Am I right in my reading that Roger Federer beat David Nalbandian in straight sets 6-2, 6-4, 6-1, in the first quarter-final? I'm not even going to try to read the rest of the table. Graham87 03:09, 28 August 2008 (UTC)

Yes, you are correct. It seems to me that it might be better to flip the chart so the winners in the final round would appear/be read first? Of course, that would be counterintuitive for the average English reader who is used to reading left to right... L'Aquatique[talk] 03:10, 29 August 2008 (UTC)

I'd expect the quarter-finals to be listed first in a chart like that. It's best to have them in chronological order. It's sort of interesting to find out if any of the top contenders were eliminated, or if there were any surprises. Graham87 05:50, 29 August 2008 (UTC)

"best" in what way? It's not accessible to display them as the are at present. Andy Mabbett | Talk to Andy Mabbett 08:17, 29 August 2008 (UTC)

The current ordering is the best way because it's how people would expect to find the results. The way they are displayed, however, is hideous for accessibility. Maybe it'd be better to have one table for the quarter-finals, another table for the semi-finals and so on. Either that or the table rows and columns need captions, and there needs to be a uniform number of rows and columns. How I imagine it is a row containing something like "first quarter-final | Roger Federer v. David Nalbandian | 6-2, 6-1, 6-4|Roger Federer" with column headings of "match title | players | score | winner", where vertical bars separate the elements in my examples. Note that there is no problem with large tables if they're needed: this list of Sydney weather observations from the Bureau of Meteorology is completely accessible. Graham87 03:47, 30 August 2008 (UTC)

Military history campaignboxes

The Military History Wikiproject has been using navigation campaignboxes placed under the infobox of articles, for a long time. They are often used singly, as in Battle of Moscow, and sometimes in multiples, for example, there are three in Operation Barbarossa.

Are these an accessibility problem? Can they be improved by providing an anchor and/or skip link in the box, or by including it within the infobox table? Or is there a problem simply with having navigation near the beginning of an article?

We're currently discussing refurbishing a body of navigation templates for tanks and armoured fighting vehicles at WT:AFV#Navigation templates, and I'd like to incorporate input from here.

Thanks. —Michael Z. 2008-08-28 15:38 z

They're not much of a problem, because as discussed above, they're easily skippable. They would e even easier to skip past if they were part of the infobox table. However the fact that they're collapsed by default makes them fairly easy to skip past with the arrow keys in screen readers that support these hide/show buttons (and most modern ones do). . Graham87 01:49, 29 August 2008 (UTC)

Horizontal lists

the template {{flatlist}} and its partner {{endflatlist}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list, as such, rather than characters which are read out ("one dot two dot three dot...") by the kind of assistive software used by, for example, people who are blind. Example Andy Mabbett | Talk to Andy Mabbett 20:43, 28 August 2008 (UTC)

I support this idea. Since they are lists, they should have list markup. Graham87 02:19, 29 August 2008 (UTC)

Thank you. Unfortunately, the above ("Bach cantatas") edit was reverted, without any discussion with this project. (I've restored it) Andy Mabbett | Talk to Andy Mabbett 08:19, 29 August 2008 (UTC)

It was reverted again, with a false accusation of "spamming". The earlier version can still be viewed. Andy Mabbett | Talk to Andy Mabbett 17:25, 29 August 2008 (UTC)

I'll add the above wording to Wikipedia:Accessibility#Lists Andy Mabbett | Talk to Andy Mabbett 08:22, 29 August 2008 (UTC)

I also support this idea. However, the implementation details could use a few tweaks. E.g. The Bach example had a lot of white space compared to the previous diff (I've fixed that easily enough).

More critically, using a bar | (not a pipe, but actually a css border-right according to MediaWiki:Common.css) to separate list items has been disputed previously in navbox discussions: hence {{navbox}} and similar, use bullets and middots (see also the 1st item in Wikipedia:LIST#See also). Is it possible to change this flatlist code to use middots or bullets or similar (or html <li> discs, so that they're not read aloud?)?

Any idea where else class=horizontal is used currently, that changing it would effect? A google search isn't bringing up anything useful (just the initial discussions/additions in 2007). -- Quiddity (talk) 17:09, 29 August 2008 (UTC)

The dots and bullets to which you refer are characters (easily checked by copying and pasting into notepad); so are pronounced by assistive tools (and are decorations, not content, so should be in CSS, not HTML, anyway!). Using some form of CSS bullet or image-as-bullet on LI elements might work; but you'd have to take care of first-child, and pay due regard to resizing issues. I can't help, on the issue of other uses of class="horizontal"; sorry; but I'd guess "few". Andy Mabbett | Talk to Andy Mabbett 17:20, 29 August 2008 (UTC)

Labeling bullets and numbers on lists "decorations, not content" would be disputed by a great many, and (as has been noted for years off-WP) are themselves a completely different form of accessibility problem (not for disabled users, but all users trying to repurpose content) when done in a way (as ul/ol/li and CSS do them) such that they cannot be copy-pasted. The pasted version is essentially gibberish. It's a thorny conundrum. They can be used as simple decoration (as when a list is created for one item, simply to give it a cute, emphasizing bullet), but most often are used to indicate (and with ol/li, to number) a list, in a specific order, as distinct from run-on content. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:08, 1 September 2008 (UTC)

I did not label "bullets and numbers on lists" as "decorations, not content"; I was referring specifically to dots (e.g. that in {{•}}, used as separators (as in "cat • dog • mouse"), in otherwise unstructured text, when some form of bullet, on a properly marked-up list, would be more semantically correct. Andy Mabbett | Talk to Andy Mabbett 01:09, 1 September 2008 (UTC)

Further thoughts: Replacing templates like {{•}} with proper, CSS list styling will also vastly reduce the number of template calls, helping server performance and improving page-load times. That said, a short term fix might be to replace those templates with something using a non-breaking space (&nbsp;), styled to have a background image like a dot or whatever. Again, care would be needed to check resizing issues. Andy Mabbett | Talk to Andy Mabbett 18:52, 29 August 2008 (UTC)

The use of a vertical bar character (or CSS equivalent) in place of the bullet character is not acceptable as the bar produced is not perfectly vertical and causes problems reading the lists as you go cross-eyed when there are short entries between the bars. The CSS mark-up needs to produce an unobtrusive character similar to the bullet when applied to lists. Keith D (talk) 22:49, 5 September 2008 (UTC)

There is no "vertical bar type character"; it's a border and is indeed "perfectly vertical". Perhaps you setup is broken? Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 22:57, 5 September 2008 (UTC)

What ever it is it needs to be something that is small and unobtrusive which is not what the boarder is. The boarder causes problems with viewing of the items and to me I go cross-eyed viewing it. Keith D (talk) 00:06, 6 September 2008 (UTC)

Form names?

Resolved

 – Moot; problem no longer applies, guideline updated to reflect this.

I've never heard of a "form name" before, does that mean "button", or is there a longer list of words that shouldn't be used in headings, and if so, why? Quote: one of the form names on the page, like "search" or "go". - Dan Dank55 (send/receive) 20:32, 30 August 2008 (UTC)

I'm not adept with HTML, but looking at this page's code, fulltext might be another problem. WhatamIdoing (talk) 01:07, 31 August 2008 (UTC)

What I meant was the title of a field in a form, like the title of an edit box, a button, a check box etc. As I said in my first writings on accessibility in Wikipedia, this is very rare and form names are very bad section titles anyway. In fact, per my testing at User:Graham87/sandbox5, this is no longer a problem, not even in the JAWS version I used in 2006. Therefore I'll remove it. Graham87 08:03, 31 August 2008 (UTC)

Heading structures

While I'm here...Pigonthewing's edits don't look right. "=" headings are not used, and WP:MOS already has guidance on how to nest subheadings; it's probably best not to do that in two places. Unless someone knows different, I'll revert. - Dan Dank55 (send/receive) 20:53, 30 August 2008 (UTC)

If you disagree with part of my edit, please improve it, rather than reverting. AS to WP:MOS; that deals with stylistic preferences; this page deals with accessibility issues. The correct heading structure is an accessibility issue. Andy Mabbett | Talk to Andy Mabbett 21:43, 30 August 2008 (UTC)

Reverted as WP:CREEP. Pigs, if you can point me to a single article that has actually used random heading levels, I'll reconsider. WhatamIdoing (talk) 01:04, 31 August 2008 (UTC)

Another issue is that there was discussion at WT:MOS (although I'm not sure if we've been explicit in any of the guidelines) that a "=====" may be used sometimes in guidelines in place of the semicolon at the start of a line for bolding; the bolding looks the same, but it lets you link to that subsection. - Dan Dank55 (send/receive) 01:40, 31 August 2008 (UTC)

That's an abuse of semantic HTML, and should be resisted; heading mark-up is for section headings; other mark-up exists for identifying anchor-link targets. Andy Mabbett | Talk to Andy Mabbett 09:15, 31 August 2008 (UTC)

I'll point you to one as soon as I can; but I regularly fix them when patrolling at random. Andy Mabbett | Talk to Andy Mabbett 09:15, 31 August 2008 (UTC)

WhatamIdoing, actually I run into bogus heading levels all the time while tooling around and doing cleanup. The template space is chock full of them, and I encounter it in stubs and Start-class articles frequently. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:16, 1 September 2008 (UTC)

Headings in page template

A quick check shows the heading structure on every page to be broken, in the Wikipedia template (and thus outside the control of ordinary editors) - there is an H1 (the page title) immediately followed by an H3 ("From Wikipedia, the free encyclopedia"); and the page ends with a bunch of H5s ("Views", "Personal tools", "Navigation", "Search", "Interaction", "Toolbox") with no parent other than H1 (and the last headings in the article, which are not meant to apply to it). I raise this elsewhere, as soon as I have time. Andy Mabbett | Talk to Andy Mabbett 09:24, 31 August 2008 (UTC)

You might have good ideas, I'm not the person to say, but there's a steady stream of people who show up on the talk pages of for instance WT:EL, WT:Layout and WT:CITE who claim that we've been doing everything wrong all along and imply that all 2.5M pages need to be changed. This never succeeds. - Dan Dank55 (send/receive) 13:36, 31 August 2008 (UTC)

You may be right; but I'm not sure why that's relevant to this discussion. Andy Mabbett | Talk to Andy Mabbett 14:27, 31 August 2008 (UTC)

I may have misunderstood; I was responding to "A quick check shows the heading structure on every page to be broken". - Dan Dank55 (send/receive) 16:06, 31 August 2008 (UTC)

Indeed - and I don't see the relevance of your comment, to that fact. Andy Mabbett | Talk to Andy Mabbett 16:11, 31 August 2008 (UTC)

←How would you like to fix the heading structure on every page, and will the reader notice any difference? - Dan Dank55 (send/receive) 16:18, 31 August 2008 (UTC)

I'd love to, if I had the relevant access. I doubt it would take more than a few minutes to fix the issue discussed in this section; and yes, they would - especially if using assistive technology to navigate a page. Andy Mabbett | Talk to Andy Mabbett 16:39, 31 August 2008 (UTC)

Further info: WCAG says:

3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]
For example, in HTML, use H2 to indicate a subsection of H1. Do not use headers for font effects. ([6])

and:

Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles for example. ([7])

On further reflection, "From Wikipedia, the free encyclopedia" isn't even a heading, and should probably be parked up as a paragraph. Andy Mabbett | Talk to Andy Mabbett 16:50, 31 August 2008 (UTC)

Concur with both Andy Mabbett/Pigsonthewing and with Dank55. It is an abuse of semantic HTML, especially the "from Wikipedia" tagline being done as a heading (I wonder who on earth thought that was a good idea? That's like 1995-style Web markup!) But it's also another of those issues where if you just show up and say "all of WP is messed up and we have to fix it immediately!" everyone's going to ignore you. I strongly recommend a piecemeal approach, fixing one problem at a time. First off, I would look at all of the Wikimedia projects - do all of them consistently abuse h3 for tagline purposes? If so, figure out where the developers and CSS geeks and so forth hang out at meta and try to get a system-wide change made. It probably would be quite trivial to fix - just create a new class with font-sizes and bolding and so forth that is applied to a paragraph or div or whatever the consensus says is most appropriate, then swap out the new code for the old around the taglines' content. This could probably be done in a single afternoon, with almost no system impact, since these things are a matter of include-file templates, not content on every page. Next pick another aspect of the entire overall problem and work on fixing that. Maybe MOS (if any of it addresses headings in a way that conflicts with accessibility) and WP:Layout need adjustment to make it clearer that heading levels are semantic, not just visual, and should be done in a specific order. Next look for specific cases of outright heading level abuse; a very clear target of that would be the preload default page created by the "create" button inside {{Documentation}} when taht page is added to a template for which no /doc file yet exists (it creates the subheadings as h3 instead of h2, which is semantically invalid). And so on. Make it a process of incremental progress instead of a campaign of revolution. :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 18:05, 31 August 2008 (UTC)

←

1. if you just show up and say "all of WP is messed up and we have to fix it immediately!"... - who did that?
2. figure out where the developers and CSS geeks and so forth hang out - already in hand.
3. {{Documentation}} - that was next on my list!
4. Make it a process of incremental progress - I tried that, by adding a note to WP:Accessibility (which is the first place you'd expect such issues to be understood). It was reverted.

Andy Mabbett | Talk to Andy Mabbett 18:14, 31 August 2008 (UTC)

1. I was responding to the same phrasing Dank55 was. Yes, I'm exaggerating it, but if that is bothering you, you may have missed my point in the exaggeration, which is that the perception of the message is likely to be this way when it is phrased like that, regardless of the intent. Many editors are alarmist by nature, especially if they focus on guideline pages, and especially-especially if it's a guideline about something some people feel is a touchy subject. :-)
2. Cool.
3. As you noted over there, I've already filed an editprotected about it. I thought about that quite a long time ago, but did not get around to viewing the source of a rendered Template:-namespace page that used {{Documentation}} to see if (after all the subtemplates and other transclusions render) the final result is actually semantically valid. I just did that, and it isn't, so it has to be fixed.
4. WP:BRD. Just because it was reflexively reverted doesn't mean it won't get back in there after further discussion. What's the link to the specific edit history change? Maybe someone just had a problem with the phrasing, or didn't understand the purpose of the edit. Given the depth of the discussion here and now, a reflexive revert is much less likely. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:57, 31 August 2008 (UTC)

1. That the heading structure on every page is broken (i.e. fails to comply with the published specifications which Wikipedia claims to meet) is irrefutable and measurable; it is a binary condition - pass or fail.

4. It's already back. The reason given for its removal was WP:CREEP, even after I had posted justification for its inclusion.

(other points noted). Andy Mabbett | Talk to Andy Mabbett 20:03, 31 August 2008 (UTC)

1. Oh, I agree. The h4 on the "From Wikipedia..." tagline has to go. Getting it to go is going to be a matter of approach (probably both tactics - how you/we/whoever asks - and strategy - who/where is asked).

4. I table-ized the examples, for increased clarity, easy of comparison (just look left and right, no scrolling) and to obviate any concern about it being too long.

— SMcCandlish [talk] [cont] ‹(-¿-)› 21:03, 31 August 2008 (UTC)

Thanks. As a spectacle wearer I find the vibrant red/ green backgrounds make the text dance. Could we use pastel shades, please? Andy Mabbett | Talk to Andy Mabbett 21:08, 31 August 2008 (UTC)

Sure, though these seemed kind of pastel to me to begin with (and I wear glasses); probably just a monitor contrast difference. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:16, 1 September 2008 (UTC)

Pigs, I see that you've cited a non-Wikipedia source as your authority. The Wikimedia software apparently doesn't comply with this outside group's rules. What I want to know is what practical difference does it make for a disabled person? Imagine a page skips from Level 1 to Level 3 with no intervening Level 2 header. What problem does this create? Do the screen readers quit reading? WhatamIdoing (talk) 21:23, 31 August 2008 (UTC)

My name is not "Pigs". I've a non-Wikipedia source as my authority because it - the W3C - is, er, more authoritative than Wikipedia, on both matters of HTML standards and web accessibility. Your other questions are also answered on line: a Google search for accessibility + html + heading + levels finds [ this video and a page saying "Without third level headings, the expectation is that there will be no fourth, fifth or sixth level headings there either". So those headings will typically not be found by a screenreader user as the first three results, after the WCAG page I have already cited. Andy Mabbett | Talk to Andy Mabbett 21:45, 31 August 2008 (UTC)

True, your name is Pigsonthewing, which is charming but longer than I feel like typing sometimes.

So the practical issue is that if I'm using a screen reader, and I ask for an outline of what's on the page, I'll probably start with level 1 or level 2 headers. If something in level 2 sounds about right, then I'll ask it whether there's any further information in level 3 headers -- and if there isn't, I'll assume that there are no level 4, 5, or 6 headers (because why would anyone skip a level?) and perhaps have to listen to a long section before getting to the specific part that I actually wanted. Thanks for providing the explanatory link. WhatamIdoing (talk) 23:09, 31 August 2008 (UTC)

My name is Andy Mabbett, which is what appears directly above your statement to the contrary. Andy Mabbett | Talk to Andy Mabbett 00:03, 1 September 2008 (UTC)

Welcome, Andy. - Dan Dank55 (send/receive) 02:42, 1 September 2008 (UTC)

Go to Bugzilla to report bugs with the MediaWiki software. The heading level skipping occurs in the default MediaWiki style sheet and can be changed there. Personally I run JAWS with heading announcements off because I find them distracting, and only try to find out the heading structure of a page when I need to learn how to navigate it. I have other bizarre JAWS settings because I've been using it for ten years now, and I'm very particular about how it should speak. I use the level 5 headings (navigation, interaction, etc.) in Wikipedia for quick navigation, and I wouldn't like to see them disappear, but I suppose I could use the lists for the same function. Graham87 02:49, 1 September 2008 (UTC)

Graham is quite the expert in navigating WP with screen readers, guys, so I'm really interested in that last comment. Can you point me to one or two pages where you use the 5-headings where you don't want to give those up, Graham? - Dan Dank55 (send/receive) 02:53, 1 September 2008 (UTC)

I use them for general navigation when I can't remember the access key for something, or there is no access key. For example I use the toolbox heading to quickly get to a user's contributions page from their user or talk page. Navigating by lists would still work, but "Toolbox" is a much more descriptive indicator of where I am than "list of 4 items". Graham87 03:00, 1 September 2008 (UTC)

Thanks, Graham. I'll pursue the MediaWiki approach later, when I have a few minutes. I'm not suggesting that the level 5 headings be done away with; but that they should be at level 2 or 3 (depending on the their parent header's level). Perhaps they could have an additional, intermediate-level, header, hidden by CSS? Andy Mabbett | Talk to Andy Mabbett 08:15, 1 September 2008 (UTC)

Already there: Template:Bug, raised on 12 September 2004 - just short of four years ago! Andy Mabbett | Talk to Andy Mabbett 22:03, 1 September 2008 (UTC)

Where to put this

Okay, so, aside from WhatamIdoing simply not believing what he's being told, that this addresses well-known and well-understood accessibility issues, the real question is where to put this? I'd be somewhat in favor of moving it to a more general guideline (WP:LAYOUT seems like a likely target) and referencing that from here. By having it in the more general guideline, both the accessibility and semantic web issues can be mentioned without either sounding out-of-place — SMcCandlish [talk] [cont] ‹(-¿-)› 00:16, 1 September 2008 (UTC)

I'm happy for it to live somewhere else (your suggestion seems reasonable; you know these pages better than I do), so long as that page mentions accessibility explicitly; and this one links to it. We seem to have similar issue on {{documentation}} :-( Andy Mabbett | Talk to Andy Mabbett 00:32, 1 September 2008 (UTC)

I have never seen a page with random heading levels (although I've seen several that skipped ==Normal== headings in favor of ===Subsections===), and no example has been produced. You may recall that the original version specified that header levels should not be random.

I refuse to believe that every issue of elegant and ideal HTML coding is automatically an issue of access for disabled users. Thus I asked what actual impact this had on disabled users, since that matters much more for the purpose of this guideline than perfect compliance with some outside organization's definition of the ideal website design standards.

I think this information should remain in this guideline. It can also be added elsewhere -- WP:LAYOUT will likely accept it, and Help:Section might -- but a person specifically looking for accessibility information should be able to find it all here. WhatamIdoing (talk) 01:17, 1 September 2008 (UTC)

This isn't a guideline yet...it claims to be, but the only cat it's ever been in AFAIK is the accessibility cat, and that's not a subcat of Category:Wikipedia policies and guidelines. I think, a lot of people think, this should be a guideline, but let's keep checking around and make sure it doesn't conflict with guidelines first. - Dan Dank55 (send/receive) 02:30, 1 September 2008 (UTC)

Relevance (lists)

We state here a requirement that unordered lists (those beginning with a bullet instead of a number) not have blank lines between them. There are good reasons for this that have absolutely nothing to do with access for disabled readers, and it's mentioned in other guidelines.

But is this actually an issue of accessibility? Does a screen reader signal the beginning of a list? For example, does this:

• First item
• Second item

get read differently from this:

• First item

• Second item

If there's no actual difference for disabled users, this should not be mentioned in this guideline. WhatamIdoing (talk) 22:47, 31 August 2008 (UTC)

Agree. - Dan Dank55 (send/receive) 02:25, 1 September 2008 (UTC)

Yes, by default, JAWS and other screen readers signal the beginning and end of each list with "list of x items" and "list end". Therefore the lists in this version of Antonio Vivaldi sound horrible. Graham87 02:33, 1 September 2008 (UTC)

Thanks, Graham. Then we should definitely keep this. However, the current text is not IMO ideal. It says, Do not separate list items by more than one line-break. If list items are separated by more than one line break, the HTML list tags will be ended.

This is presumably just fine if you know exactly what a line-break is and believe that invisible HTML list tags are important. However, "no more than one line-break" may be misinterpreted as "no more than one blank line" by some readers, and the relevance of HTML list tags is non-obvious.

Could we rephrase this to something like what WP:MOS says, which is "Do not leave blank lines between items in a bulleted or numbered list unless there is a reason to do so, since this causes the Wiki software to interpret each list item as an individual list." -- except perhaps adding that it causes screen readers to announce each item as belonging to a separate, one-item list? WhatamIdoing (talk) 06:22, 1 September 2008 (UTC)

Agreed with all of that. - Dan Dank55 (send/receive) 13:30, 1 September 2008 (UTC)

P.S. But let's make it clear we're talking about article-space. On talk pages, it's common for people to leave a blank line between someone else's bullet point and their bullet point to enhance readability. If screen readers do a bad job reading this, then we should complain to the people who make the screen readers. - Dan Dank55 (send/receive) 14:04, 1 September 2008 (UTC)

Sounds good. I didn't realise that separating lists was mentioned in the Manual of Style when I wrote that section, but it needs to be mentioned in the accessibility guidelines as well. Graham87 14:05, 1 September 2008 (UTC)

Note: <tt> is not <code>

Someone or other seems to be confused about the meanings of some [X]HTML entities. To give examples of source code snippets (like wiki markup, template code, etc.), use <code>...</code>. The <tt> element is nothing but a font-styling tag and has no semantic function at all. I just checked the current version of the W3C HTML specs, and for some reason it has not been deprecated according to the Index of Elements, but this is surely either a typographical error or other oversight, as all other purely-presentational markup has been deprecated in favor of CSS since 1998.

A lot of other semantic (or "logical" as someone wrote in the guideline page – where'd that come from?) elements get confused with <code>, as well, including <kbd>, <samp> and <var> (documentation). These all have distinguishable semantic purposes.

Presently, MediaWiki (or at least Wikipedia's installation of it) actually does not accept <kbd> or <samp>, only <code> and <var> (and <tt>, which we should ignore as being no different from deprecated obsolete junk like <font>, <b>, etc.). This should probably be undone by the developers, as there are often good semantic reasons to use these elements, especially in technical articles and in template documentation. Something for WP:VPT. I have [[WP:VPT#Enable & |proposed this already]], actually.

That fact that most browsers (we cannot be certain that it is all of them, since I doubt anyone, including me, has possibly ever used every browser in existence, and I'm a professional web developer) display <code> and <tt> visually as monospaced, non-proportional text, at the same size and otherwise styled identically, is irrelevant. They have different meanings (or rather one has a meaning and the other does not), and it is likely that some screen readers and other software (XML applications, and such) are already distinguishing between them, and have for some time. Inline microformats like hCard also sometimes depend heavily on the semantics of HTML elements not being violated. (I doubt that hCard in particular makes any use of these specific elements, but that's beside the point; who knows how many microformats their are or will be?)

If for some reason monospaced type is needed but it is not code, it is really more appropriate to use {{Mono|text here}} (a template for <span style="font-family: monospace;">text here</span>) instead of the <tt> version, just to better keep the content and the presentation separate.

PS: We should not use quotation marks with <code>, etc. (other than for purposes of actual quotations, of course), since "scare-quoting" them is simply redundant; the markup itself already sets them apart as non-regular segment of the running prose. I.e., write "use <code>reason=<code> to provide a reason for applying this template", not "use '<code>reason=<code>' to provide a reason for applying this template" (and note that "use <code>'reason='<code> to provide a reason for applying this template" would be severely wrong unless the single-quotes were part of the actual literal string required in the source code!).

— SMcCandlish [talk] [cont] ‹(-¿-)› 23:25, 31 August 2008 (UTC)

I've been guilty of misusing TT; and you're right, so I'll try not to do so again. But microformats do not make use of HTML elements, other than generically, with a few specific exceptions (A, ABBR) and none do or are likely to make use of CODE or TT other than as interchangeable elements. Andy Mabbett | Talk to Andy Mabbett 00:28, 1 September 2008 (UTC)

Moving images

I'm no expert, but I think that moving images like a recent "picture of the day": Image:Tablet press animation.gif and especially flashing images like Image:Strobe.gif could cause problems for people with some photo-sensitive conditions like epilepsy - I don't have that, but I find them distracting. My preference would be to use a static version, and link to the moving image, with a caution in the link in place. Andy Mabbett | Talk to Andy Mabbett 00:54, 1 September 2008 (UTC)

I'd have no objection to tagging moving images as moving and letting users set a preference that they only want to see the first frames of animation; that might have value to people sensitive in one way or another, and it would also help people who prefer to avoid animation because of bandwidth. (I don't keep up with image issues; maybe this is possible already?) Tagging would be much preferable to discarding; animations are very important in sci/tech articles. - Dan Dank55 (send/receive) 02:24, 1 September 2008 (UTC)

Tagging would be a good idea ... complex animations make JAWS unresponsive. I have images turned off in my web browser to save bandwidth, but I realise that isn't an option for everyone using shared computers. I always thought that only still images were displayed on the Main Page with a link to the animation, but that might have changed. Graham87 03:06, 1 September 2008 (UTC)

Notes: This was last discussed at length at Wikipedia:Village pump (proposals)/Archive#Avoid movement in pages (May 2007 archived diff). I won't attempt to summarize it all (though I do apologize to Andy for my tone and goodfaith in some of the comments there), but there are numerous pros and cons to both displaying or not-displaying animations directly within articles. And numerous editors/admins supporting each position, hence no consensus for a change seems to have been reached there.

The relevant policy section is at Wikipedia:Image use policy#Displayed image size, which has stated since late 2005 that "Inline animations should be used sparingly; a static image with a link to the animation is preferred unless the animation has a very small file size." (Though I haven't seen any articles that actually use this idea...)

Discussing this at Wikipedia:Village pump (technical) and/or Wikipedia talk:Image use policy might be preferable(?), but it'd be good to have accessibility experts in on the discussion wherever it is. Hope that helps. -- Quiddity (talk) 19:48, 1 September 2008 (UTC)

It helps quite a lot. I didn't know that policy prefers static images with links to animations in most cases; I'll mention that in my reviews when it comes up. - Dan Dank55 (send/receive) 03:54, 2 September 2008 (UTC)

Or, Tell us if you ever see an article that is already using the static-link method! (I've never seen one.) Perhaps the policy should rather be changed to reflect actual practices/usage...

Personally, I strongly support including the majority of animations directly within the article. The animation at Engine#Modern, or the three used in Horse gait, for example, are immensely informative/educational, and I'd be sorry to see them get removed by one level - where many readers will never discover them. -- Quiddity (talk) 03:51, 6 September 2008 (UTC)

Scope

A lot of people browse Wikipedia on cellphones and PDAs these days. Some browse on Kindle, which has gray-scale only, no color. I imagine some people like to listen to articles from Wikipedia while they're driving. People who use small screens and screen readers would agree with the main thrust of this page, which seems to me to be, put things where people are expecting them to be, to aid navigation. Should we mention that the issues on this page have wide applicability? I think some people think of this page as having more limited scope. - Dan Dank55 (send/receive) 02:41, 1 September 2008 (UTC)

Agreed. The more accessible a page is to "the disabled" (™), the more accessible it is to everyone, not least the people you list - and search engines. Andy Mabbett | Talk to Andy Mabbett 08:22, 1 September 2008 (UTC)

And a large number of people over 40 have a larger default font size on their computers. - Dan Dank55 (send/receive) 13:58, 1 September 2008 (UTC)

Template: Geographic Location

How does {{Geographic Location}} render in assistive browsers? Could it be improved? (For an example, see Bergman, Edmonton#Surrounding_Neighborhoods). Andy Mabbett | Talk to Andy Mabbett 19:01, 1 September 2008 (UTC)

See also {{GeoCompass}} (used on Chelmsford#Nearest places); and {{Compass-table}} (used on Marylebone#Location in Context). It is proposed that these two should be merged into the above. To my mind, the latter looks the most accessible, in that it includes compass-directions as text, and linearises properly. Andy Mabbett | Talk to Andy Mabbett 19:12, 1 September 2008 (UTC)

{{Geographic Location}} doesn't render well with JAWS. The images with no captions sound like "link graphic Compass_rose_pale.svg/50px-Compass_rose_pale.svg", the links for viewing, discussing, and editing the template get in the way, and it's hard to tell what direction you're reading about. {{GeoCompass}} reads OK linearly but it is still hard to figure out what direction everything is. {{Compass-table}} is the most accessible, but the table would be easier to use with row and column titles. When I navigate from east to southeast, I also hear the "southwest" part because JAWS thinks that's the title of the row. Speaking of directional templates, the {{Infobox Australian Place}} shows the suburbs or towns surrounding a certain place, but it's hard to tell the directions of the towns with a screen reader. An example is at Nollamara, Western Australia. Graham87 01:18, 2 September 2008 (UTC)

Use of colour to convey information

WCAG 1.0 says:

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. - http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-color-convey

We should therefore discourage the use of colour (or shading-pattern) alone to convey information, as seen in List of Oasis band members#Timeline. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 21:48, 2 September 2008 (UTC)

Succession boxes

Simple succession boxes (like the second one here), seem OK, though they do lack headers, but complex cases, like this hypothetical example on the template documentation page, seem less so. Thoughts? Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 22:54, 2 September 2008 (UTC)

Link fixed. The second template you mention should be separated out into columns for the title and year. As it is now, it still reads OK linearly. Graham87 04:19, 3 September 2008 (UTC)

If you think the hypothetical situation is a bit much, check out Winston Churchhill's page, it is atrocious. However, there is a reason to all the chaos. In some rare circumstances, an individual will have many more succession titles than most and those need to be documented in the best means available. Currently, those means are succession boxes. They convey the titles and dates, note the predecessor and successor, and show what kind of title it is/was. True, they can take over pages sometimes, but those situations are rare and often the lists are appreciated for their thoroughness. In regards to accessibility, since that is what this talk page is all about, I would say that the information in a succession box is far more accessible sometimes than searching through the article to find it. Sure it is not always the best method, but often (and unfortunately), all the information in a succession box cannot be found in the article itself, either because the information is deemed too irrelevant for the body of the article (but could be important in a larger continuity) or because its entry was overlooked. If you have suggestions for change of the format, by all means suggest it at WT:SBS. We are constantly looking to make our succession boxes cleaner and more accessible. Thank you for your feedback and I hope I provided at least somewhat of a satisfactory reply.
–Darius von Whaleyland, Great Khan of the Barbarian Horde 08:13, 6 September 2008 (UTC)

←Thank you for a detailed response. Please bear in mind that the accessibility discussed here is specifically for people with a disability or other condition which can mean that their use of Wikipedia is not conducted in the same way, or using the same tools, as most of us use. That can include people who cannot see, and who have the pages read out loud to them by their computer. For such users, tables (which is how succession boxes are rendered), when used for layout rather than for tabular data, can be very problematic, because the software reads across rows; and because there is no header row or column to label the others. If you have Firefox, this effect can be simulated by using the "web Developer" extension, then selecting "Miscellaneous" then "Linearize Page". The table on Winston Churchill, while not perfect, and very long, is better than many, because it consists of simple rows. When, like in the hypothetical example discussed above, the first cell in a row covers multiple cells in the remaining columns, its accessibility is reduced. In that case, it can be read, in part, in the order:

• Preceded by Elizabeth
• Lady Supreme of Oceana 1975 – 1983
• Vacant
• Title next held by Jilian
• Empress of Arabia 1975 – 1993
• Title merged with Great Khanna of Asia
• Grand Duchess of Europa 1975 – 1999
• Succeeded by Felicia
• Vacant Title last held by Karl von Igorstein
• Chief Sultana of Africa 1993 – 1999

and so on.

Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:18, 6 September 2008 (UTC)

Let me just throw a suggestion out

I haven't thought this through, and I'm sleepy, so this may suck. Except for a little overlapping at WP:MOS, don't we usually operate under the principle that it's best if guidelines are on the page you expect them to be? When people look at all, they look for information on embedded lists at WP:Embedded lists, guidance on layout at WP:Layout, etc. Since we want to recommend here that people not put blank lines between bullet items in article space, wouldn't it make more sense to have this advice in WP:Embedded list, and to point there from here? We could give more details on the "accessibility" perspective here than at WP:EMBED if we think that's helpful. - Dan Dank55 (send/receive) 02:44, 3 September 2008 (UTC)

Well, Wikipedia:Embedded list breaks the rule about separating list items by blank lines in the section 'However, it can be appropriate to use a list style when the items in list are "children" of the paragraphs that precede them. ' I've been removing line breaks from such lists when I've found them, but I'm not sure that making fake bulleted lists is the best way to indent paragraphs. In short, Wikipedia:Embedded list needs some cleanup as well. Graham87 04:34, 3 September 2008 (UTC)

At the moment, the "no blank lines between items" is going into several guidelines. In general, duplication is bad (because then it has to be kept synchronized), but I think this particular issue now makes an appearance at MOS, EL, LIST, ACCESS, and maybe CITE. WhatamIdoing (talk) 05:07, 3 September 2008 (UTC)

I want to echo WhatamI's comment that duplication is bad. If there is a well developed discussion of a topic in the "wrong" article then the "right" article should link to that discussion. (Alternatively, you can do something like this: http://en.wikipedia.org/wiki/Wikipedia:Lead_section_TT_text .) Butwhatdoiknow (talk) 15:10, 3 September 2008 (UTC)